- I don't see an idempotency key in the request to authorize a charge; that might be something nice for people looking to build reliable systems on this.
- How long are accessTokens valid? Forever? Do they become invalid if the subject metadata (firstName, lastName, email) changes?
I think this is a super-cool idea, but I think the idea of extending net30 terms to every customer of some B2C product seems pretty iffy; since you're deferring charging until the end of the month, you won't get most of the fraud signals from Stripe until then and anything popular that used this system seems like it'd be pretty inundated with fraud. I would at least consider doing the charges more frequently (i.e., charge at the end of the month or every $50, whichever comes first) to put a better bound on how long you can go before finding out that someone gave you a stolen card.
We run Stripe Radar and 3-D Secure when adding a card (before first use), which filters out a lot of obvious fraud (and 3DS often shifts liability to card networks in many regions).
The balances are not settled just at the end of the month. Each customer has a "maximum owed limit", which starts low (currently 10 USD) and grows with successful payments (up to 30 USD currently). The customer is charged as soon as they hit that limit (with some grace to allow for continued use).
Idempotency keys are on the near-term roadmap. Access tokens do not currently expire; however, they can be revoked by the customer at any time.
> anything popular that used this system seems like it'd be pretty inundated with fraud
I coined "micropayments means microfraud"; I would expect this to have similar situations to the AWS mystery bill problem, but on a tiny scale. If you can charge customers without their confirmation it's easy to run up bills. And of course the amounts are so tiny you can't afford dispute resolution.
Yes, merchant abuse is a risk. What we do and plan to do:
- Each merchant requires an OAuth grant, and customers can revoke it at any time.
- A customer ledger shows what, when, and how much each merchant charged. This can be shown in the customer's dashboard and monthly statement emails.
- Customers have account-level spending caps to limit exposure. We will add per-merchant caps.
- If patterns look off or we get complaints, we can pause new charges and review.
A better model I had in mind works like this: customers purchase tokens in any amount they choose. Companies then charge for their services using these tokens through the platform's APIs. At the end of each month, settlements are made based on the total token value. The smallest token unit could be as small as one-millionth of a dollar.
It’s similar to a digital wallet, but without currency conversion: customers cannot exchange tokens back into money.
That approach generally doesn't work from a legal perspective: prepaid tokens are often treated as e-money (especially if it's not for company's own products or services), and in many jurisdictions, holding value for users requires an e-money/money transmitter license.
I kind of expected this, though not want this way :( ... it seems governments will go to any extent to prevent creation of alternative source of value other than the one they can fully control... for good mostly, bad at other times..
I've been wanting something like this for a long time. There's a lot of ways this could go wrong, but I hope it works.
I'd especially love a video platform using this model. I can't afford patreon for every YouTube channel, but I'd love to pay 10¢ per hour of video watched.
$0.10 per hour is already WAY more than a creator usually gets from your viewing. I'd happily pay that amount for good youtube-like content. Creators would love it because it's far more money than they get now. Consumers would like it because for a lot of people it's cheaper than a subscription, and they could forgo ads
Yes, Small Transfers can be used for pay-per-view or pay-per-minute billing models.
The platform's biggest risk that I see is a customer defaulting after using a merchant's service. The platform currently mitigates that with Stripe Radar, 3-D Secure, and spending caps, but I'm keen to hear anything specific you're thinking about.
> customer defaulting after using a merchant's service
I think the defaulting rate would just get baked into the asking price. But I'm assuming there isn't a way to repeatedly systematically default to get unlimited free content.
Each customer already has a limit on the amount they can owe before we require payment. Each customer account also requires a unique payment method, which must pass Stripe Radar and 3-D Secure checks. We plan to add more checks in the future.
If you store funds for a specific service that you provide, it's fine. If it's for many services or services provided by others, it's legally problematic.
We don't hold upfront funds. When a customer pays, we initiate Stripe transfers to the merchant as soon as the funds are available.
Paying the merchant before the customer's card payment settles would mean advancing funds, which would start to resemble lending/guarantee rather than payments, raising regulatory issues. It would also concentrate risk at the platform: defaults from one merchant’s customers could jeopardize the platform for all merchants.
I thought 30 days are an option at least when you can explain the reason/necessity to stripe?
Could be an option to funnel default-risky (as distinct from chargeback-risky!) customers to a customer-selectable hold amount rolling the per-transaction flat fee into basically a per-bill flat fee thus indirectly giving volume/commitment discounts to those that select 30-day intervals with large holds?
I guess ideally offer an option to force a billing (transaction finalization) to release the hold if a customer changes their mind (or just happened to use a debit card)...
Though even with 7 day holds it'd allow you to offer service to poor people (which mostly overlaps "people with bad credit") without the APIs having to maintain revenue margins large enough to just eat that default risk, and without having to hold onto any funds yourself.
10¢ per hour seems low to me — I’d happily pay ~$1 per hour. $10 per week is less than I currently pay for subscriptions, and I don’t want to spend more than 10 hrs per week watching video anyway.
Where YouTube is my movie player and podcast player and general video player, all of which is done at 2x speed I can't imagine paying $4-6/day for YouTube.
Just my commute listening to a podcast that I downloaded before leaving would cost me $1.50 each way? Nah I'll keep my subscription thanks.
What's the payment threshold? I assume you're paying 2.9% and $0.30 (or around there) for the transaction. You charge that to the customer but what if their bill is $0.01, are you really going to make them pay $0.32 for $0.01 of usage? How do you expect SaaS providers to communicate that on their pricing page? If they charge $0.01 per request and the end-user makes 100 requests their bill is actually $1.33 which means the actual per-request charge is $0.0133.
Several years ago Stripe offered more favorable pricing for small transactions but it's my understanding that that pricing is no longer available to new Stripe businesses.
If a customer's balance is under $1 at the end of the month, we delay charging them for up to 60 days and send email reminders. If it's still under $1 after 60 days, we charge at least $0.50 and credit the difference (after fees) to their account for future use.
I had 100% same idea since a few months now. Didn't pursue it because of lack of companies and customers willing to use such a platform as intermediatory.
Secondly, the legal aspect. Will this be considered as a wallet?
You're right to consider this, as it's an important aspect from a legal perspective.
Since Small Transfers doesn't store customers' funds or allow them to withdraw a balance, the platform is not considered an e-money institution or a "wallet".
When the customers pay their balance, we immediately forward the funds to the merchants.
Ultimately, the merchant bears the risk of non-payment, but the platform does its best, using industry-standard practices, to pre-check the customer and their payment methods for fraud and ensure a successful payment.
If a merchant successfully authorizes a charge, the amount is reserved for that merchant for a limited period. Trying to capture that amount (or less) during this period will succeed.
I'm a little confused. Is Small Transfers not the merchant for the CC transaction? (Your website suggests Small Transfers is the merchant of record and then transfers funds to the seller.) If not, what's your role in the settlement process?
Yes, Small Transfers is the merchant of record for the card charge. We transfer only funds actually received to the merchant's Stripe account; we don't advance funds. As per the Terms (§1 "Transfer" and §5.6 "Non-Payment"), chargebacks/reversals are net-deducted from future transfers, so the seller bears non-payment risk.
Definitely! The API lets you authorize the maximum your AI request might cost (+ margin), then capture the actual cost (+ margin). For some example code, see our Next.js Starter project: https://github.com/smalltransfers/nextjs-starter
I mean this in the most constructive way possible: why do you think this idea hasn’t worked before, when it’s been fairly obvious and easy to build for a long time? And what’s your fix for that issue? You present the merchant side of things, but not the customer side which is more important to me, as a potential Small transfers adopter. What’s customer conversion like? Are micropayments actually better than typical payment amounts? Based on my experience I’d expect the conversion rate of a $0.01 and $1 fee to be pretty similar. The friction of inputting a credit card and trusting a service is way higher than the actual payment amount. I’d also have to introduce 2 more services to my customers: Small transfers powered by stripe, and customers would have to fund an account that realistically speaking can’t be used anywhere other than my site. Just offering some questions to think about!
https://en.wikipedia.org/wiki/Flattr figured out some parts of this. Notably, you picked your own total monthly donation, and then clicked a button on participating sites to allocate a fraction of your total to them. AFAICT it worked as advertised, but raised new issues with donation behavior. E.g. I obviously like curl every month, so should I click its button monthly? Twice monthly? If I am a developer of some other useful OSS software, should I click curl's button and the curl devs click my button? Does the money just slosh around between merchant-customers? Is that good?
I believe the idea has been attempted many times before, primarily by large companies that have tried to create their own currency. It seems deceptively simple, but it's quite tricky to get right, both from a legal and technical perspective. One of the main legal complications is the one mentioned in another comment: avoiding the status of an e-money institution.
With Small Transfers:
- There is no wallet or funding for the account. Customers simply pay for what they owe, usually at the end of each month.
- There is a lower psychological barrier, since there is no subscription or prepay commitment. Customers who dislike recurring payments are more willing to try something new that avoids this.
- Merchants need to introduce customers to just one extra service, Small Transfers.
Some customers of Unattach (a service I built) are happily paying for the service via Small Transfers, and early feedback shows that they really appreciate this pricing model. It's worth noting that Unattach also supports the classic subscription model.
As more merchants adopt Small Transfers, customers will still only need one account, making micro-billing even more convenient.
I think micropayments are important for a healthy web economy.
In 2018 I built a pay-per-call API paywall using the Lightning Network (a Bitcoin Layer 2 protocol/network that enables instant, low-fee payments): https://github.com/philippgille/ln-paywall
But most people are either unwilling to touch crypto at all, or holding on to it tightly as investment and not willing to use as payment.
So I wish you luck to make this work in the fiat world!
Because it works with a credit card? Also unless you do what this service is doing by accumulating payments until a reasonable threshold is reached before actually charging the fees then even on Lightning will eat you alive. So if you have the system to handle billing this way you might as well use existing payment networks.
I think credit cards succeed because they give customers rewards, passing on the cost to the vendor and ultimately all other customers. Also because they were the only alternative to cash for the longest time
And as someone building an app I do want subscriptions for all the reasons everyone knows about. That's probably why no one really does this despite being talked about for years.
Subscriptions are great for predictability, and most apps should keep them.
Small Transfers can be added to help with:
- users who dislike subscriptions
- infrequent users
- reducing/removing free-trial costs for non-converting users
A common pattern is hybrid pricing: pay-as-you-go (PAYG) for light/occasional use, a subscription for regular use. Similar to mobile plans, where monthly plans become cheaper above a certain usage threshold. I use this pattern for one of my services: https://unattach.com/pricing
I believe that Small Transfers also enables services that aren't viable with subscriptions or prepaid credits, e.g., a movie-suggestion service.
Some API questions/observations
- I don't see an idempotency key in the request to authorize a charge; that might be something nice for people looking to build reliable systems on this. - How long are accessTokens valid? Forever? Do they become invalid if the subject metadata (firstName, lastName, email) changes?
I think this is a super-cool idea, but I think the idea of extending net30 terms to every customer of some B2C product seems pretty iffy; since you're deferring charging until the end of the month, you won't get most of the fraud signals from Stripe until then and anything popular that used this system seems like it'd be pretty inundated with fraud. I would at least consider doing the charges more frequently (i.e., charge at the end of the month or every $50, whichever comes first) to put a better bound on how long you can go before finding out that someone gave you a stolen card.
We run Stripe Radar and 3-D Secure when adding a card (before first use), which filters out a lot of obvious fraud (and 3DS often shifts liability to card networks in many regions).
The balances are not settled just at the end of the month. Each customer has a "maximum owed limit", which starts low (currently 10 USD) and grows with successful payments (up to 30 USD currently). The customer is charged as soon as they hit that limit (with some grace to allow for continued use).
Idempotency keys are on the near-term roadmap. Access tokens do not currently expire; however, they can be revoked by the customer at any time.
> anything popular that used this system seems like it'd be pretty inundated with fraud
I coined "micropayments means microfraud"; I would expect this to have similar situations to the AWS mystery bill problem, but on a tiny scale. If you can charge customers without their confirmation it's easy to run up bills. And of course the amounts are so tiny you can't afford dispute resolution.
Yes, merchant abuse is a risk. What we do and plan to do:
A better model I had in mind works like this: customers purchase tokens in any amount they choose. Companies then charge for their services using these tokens through the platform's APIs. At the end of each month, settlements are made based on the total token value. The smallest token unit could be as small as one-millionth of a dollar.
It’s similar to a digital wallet, but without currency conversion: customers cannot exchange tokens back into money.
That approach generally doesn't work from a legal perspective: prepaid tokens are often treated as e-money (especially if it's not for company's own products or services), and in many jurisdictions, holding value for users requires an e-money/money transmitter license.
I kind of expected this, though not want this way :( ... it seems governments will go to any extent to prevent creation of alternative source of value other than the one they can fully control... for good mostly, bad at other times..
I've been wanting something like this for a long time. There's a lot of ways this could go wrong, but I hope it works.
I'd especially love a video platform using this model. I can't afford patreon for every YouTube channel, but I'd love to pay 10¢ per hour of video watched.
$0.10 per hour is already WAY more than a creator usually gets from your viewing. I'd happily pay that amount for good youtube-like content. Creators would love it because it's far more money than they get now. Consumers would like it because for a lot of people it's cheaper than a subscription, and they could forgo ads
Yes, Small Transfers can be used for pay-per-view or pay-per-minute billing models.
The platform's biggest risk that I see is a customer defaulting after using a merchant's service. The platform currently mitigates that with Stripe Radar, 3-D Secure, and spending caps, but I'm keen to hear anything specific you're thinking about.
> customer defaulting after using a merchant's service
I think the defaulting rate would just get baked into the asking price. But I'm assuming there isn't a way to repeatedly systematically default to get unlimited free content.
Each customer already has a limit on the amount they can owe before we require payment. Each customer account also requires a unique payment method, which must pass Stripe Radar and 3-D Secure checks. We plan to add more checks in the future.
I don’t know if it defeats the purpose but you could require an upfront, refundable deposit.
Requiring money upfront would classify the platform as an e-money institution, which is highly problematic from the legal perspective.
How does tarsnap handle it? I think there's lots of services that bill up front... Isn't it only e-money if you can convert it back to cash?
If you store funds for a specific service that you provide, it's fine. If it's for many services or services provided by others, it's legally problematic.
What if you inverted the trust equation by giving the money to the service provider immediately, rather than holding any of the up front payment?
We don't hold upfront funds. When a customer pays, we initiate Stripe transfers to the merchant as soon as the funds are available.
Paying the merchant before the customer's card payment settles would mean advancing funds, which would start to resemble lending/guarantee rather than payments, raising regulatory issues. It would also concentrate risk at the platform: defaults from one merchant’s customers could jeopardize the platform for all merchants.
Ah neat, thanks for the clarification.
> Requiring money upfront would classify the platform as an e-money institution, which is highly problematic from the legal perspective.
What if you just reserve it on the card?
Online card holds typically expire in ~7 days (often sooner, depending on the issuer), which is too short for our use case.
I thought 30 days are an option at least when you can explain the reason/necessity to stripe?
Could be an option to funnel default-risky (as distinct from chargeback-risky!) customers to a customer-selectable hold amount rolling the per-transaction flat fee into basically a per-bill flat fee thus indirectly giving volume/commitment discounts to those that select 30-day intervals with large holds?
I guess ideally offer an option to force a billing (transaction finalization) to release the hold if a customer changes their mind (or just happened to use a debit card)...
Though even with 7 day holds it'd allow you to offer service to poor people (which mostly overlaps "people with bad credit") without the APIs having to maintain revenue margins large enough to just eat that default risk, and without having to hold onto any funds yourself.
10¢ per hour seems low to me — I’d happily pay ~$1 per hour. $10 per week is less than I currently pay for subscriptions, and I don’t want to spend more than 10 hrs per week watching video anyway.
Where YouTube is my movie player and podcast player and general video player, all of which is done at 2x speed I can't imagine paying $4-6/day for YouTube.
Just my commute listening to a podcast that I downloaded before leaving would cost me $1.50 each way? Nah I'll keep my subscription thanks.
Depends on the person's budget!
Interesting ... A web2 equivalent to the x402 specification. Thanks for the explanation of how fees are handled below.
https://x402.org
x402: on-chain, HTTP 402, wallet-to-server, synchronous per-request payments.
Small Transfers: card rails (Stripe), account-based, off-session, batched billing with spend caps; no tokens/wallets.
What's the payment threshold? I assume you're paying 2.9% and $0.30 (or around there) for the transaction. You charge that to the customer but what if their bill is $0.01, are you really going to make them pay $0.32 for $0.01 of usage? How do you expect SaaS providers to communicate that on their pricing page? If they charge $0.01 per request and the end-user makes 100 requests their bill is actually $1.33 which means the actual per-request charge is $0.0133.
Several years ago Stripe offered more favorable pricing for small transactions but it's my understanding that that pricing is no longer available to new Stripe businesses.
If a customer's balance is under $1 at the end of the month, we delay charging them for up to 60 days and send email reminders. If it's still under $1 after 60 days, we charge at least $0.50 and credit the difference (after fees) to their account for future use.
Good use case for stablecoin/crypto through stripe
I had 100% same idea since a few months now. Didn't pursue it because of lack of companies and customers willing to use such a platform as intermediatory.
Secondly, the legal aspect. Will this be considered as a wallet?
Anyways, loved to see it implemented by someone.
You're right to consider this, as it's an important aspect from a legal perspective.
Since Small Transfers doesn't store customers' funds or allow them to withdraw a balance, the platform is not considered an e-money institution or a "wallet".
When the customers pay their balance, we immediately forward the funds to the merchants.
What happens when customers don't pay their balance?
What happens when the charge attempt fails after initial preauth?
Ultimately, the merchant bears the risk of non-payment, but the platform does its best, using industry-standard practices, to pre-check the customer and their payment methods for fraud and ensure a successful payment.
If a merchant successfully authorizes a charge, the amount is reserved for that merchant for a limited period. Trying to capture that amount (or less) during this period will succeed.
I'm a little confused. Is Small Transfers not the merchant for the CC transaction? (Your website suggests Small Transfers is the merchant of record and then transfers funds to the seller.) If not, what's your role in the settlement process?
Yes, Small Transfers is the merchant of record for the card charge. We transfer only funds actually received to the merchant's Stripe account; we don't advance funds. As per the Terms (§1 "Transfer" and §5.6 "Non-Payment"), chargebacks/reversals are net-deducted from future transfers, so the seller bears non-payment risk.
Details: https://smalltransfers.com/terms
This could be a great way to charge ai for access to content.
Definitely! The API lets you authorize the maximum your AI request might cost (+ margin), then capture the actual cost (+ margin). For some example code, see our Next.js Starter project: https://github.com/smalltransfers/nextjs-starter
I mean this in the most constructive way possible: why do you think this idea hasn’t worked before, when it’s been fairly obvious and easy to build for a long time? And what’s your fix for that issue? You present the merchant side of things, but not the customer side which is more important to me, as a potential Small transfers adopter. What’s customer conversion like? Are micropayments actually better than typical payment amounts? Based on my experience I’d expect the conversion rate of a $0.01 and $1 fee to be pretty similar. The friction of inputting a credit card and trusting a service is way higher than the actual payment amount. I’d also have to introduce 2 more services to my customers: Small transfers powered by stripe, and customers would have to fund an account that realistically speaking can’t be used anywhere other than my site. Just offering some questions to think about!
https://en.wikipedia.org/wiki/Flattr figured out some parts of this. Notably, you picked your own total monthly donation, and then clicked a button on participating sites to allocate a fraction of your total to them. AFAICT it worked as advertised, but raised new issues with donation behavior. E.g. I obviously like curl every month, so should I click its button monthly? Twice monthly? If I am a developer of some other useful OSS software, should I click curl's button and the curl devs click my button? Does the money just slosh around between merchant-customers? Is that good?
See also: Kachingle (2007), Amazon Flexible Payment Service (2007), Dwolla (2008), Tipjoy (2008), Facebook Credits (2009), Google Checkout (2006), Flattr (2010), Changetip (2014)
I believe the idea has been attempted many times before, primarily by large companies that have tried to create their own currency. It seems deceptively simple, but it's quite tricky to get right, both from a legal and technical perspective. One of the main legal complications is the one mentioned in another comment: avoiding the status of an e-money institution.
With Small Transfers:
Some customers of Unattach (a service I built) are happily paying for the service via Small Transfers, and early feedback shows that they really appreciate this pricing model. It's worth noting that Unattach also supports the classic subscription model.As more merchants adopt Small Transfers, customers will still only need one account, making micro-billing even more convenient.
I think micropayments are important for a healthy web economy.
In 2018 I built a pay-per-call API paywall using the Lightning Network (a Bitcoin Layer 2 protocol/network that enables instant, low-fee payments): https://github.com/philippgille/ln-paywall
But most people are either unwilling to touch crypto at all, or holding on to it tightly as investment and not willing to use as payment. So I wish you luck to make this work in the fiat world!
Nice work and thank you for the encouraging words!
Why would you use this over Bitcoin Lightning payments?
Because it works with a credit card? Also unless you do what this service is doing by accumulating payments until a reasonable threshold is reached before actually charging the fees then even on Lightning will eat you alive. So if you have the system to handle billing this way you might as well use existing payment networks.
unsecured lending in the crypto world is nonexistent or implodes immediately, and even more nonexistent in the bitcoin side of things
credit cards solve that market need and are wildly popular for decades
I think credit cards succeed because they give customers rewards, passing on the cost to the vendor and ultimately all other customers. Also because they were the only alternative to cash for the longest time
that's an additional attraction
many crypto services give passive fungible rewards to users for volume too, and they are wildly popular in that ecosystem
most large and growing platforms onchain do that, and people farm them hoping they begin doing that as they reward earliest users, later
Cool! Does it use crypto?
Thanks! Small Transfers uses its own system for tracking usage, which is settled through Stripe. No crypto, tokens, or wallets.
Convenient - the government always can know who watched what.
Hmm, but it's a bargain to stuff false data in there too, just pay tiny fractions of a cent to send them your My Little Pony watching habits mixed in?
The fake ones can be filtered out easily because the interaction and behavior is different
And as someone building an app I do want subscriptions for all the reasons everyone knows about. That's probably why no one really does this despite being talked about for years.
Subscriptions are great for predictability, and most apps should keep them.
Small Transfers can be added to help with:
A common pattern is hybrid pricing: pay-as-you-go (PAYG) for light/occasional use, a subscription for regular use. Similar to mobile plans, where monthly plans become cheaper above a certain usage threshold. I use this pattern for one of my services: https://unattach.com/pricingI believe that Small Transfers also enables services that aren't viable with subscriptions or prepaid credits, e.g., a movie-suggestion service.
If I need this I don’t deserve to survive in the SaaS business.