- 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.
I really like the growing maximum owed limit idea and it would be really interesting to also make it possible to set an auto payment threshold lower than it.
The idea being something like "charge at X € owed but let it go up to N*X € if a payment fails before suspending service" where the N scales with something like the number of paid invoices or even total past spend.,
The primary objective of the max-owed limit is to cap per-customer risk.
If you are suggesting that the max-owed limit is actually N×X, then that would multiply worst-case exposure by N, which is undesirable.
If you are suggesting that we charge the customer when they owe X while their max-owed limit is N×X, this would be worse for the customer, since they would pay `N × (X × variable_rate_fee + fixed_rate_fee)` instead of `N×X×variable_rate_fee + fixed_rate_fee` in payment processing fees.
If your payment processor takes a per-transaction fee (not all do) then yes, this is a slightly worse deal for the customer. However, I think this would still be a good choice to give them, even if many would probably not chose it in order to save a few cents.
If I burn 1 € per day and my max owed based on whatever risk assessment is 20 €, I can set my payment treshold to 15 €, meaning if a payment fails, I have 5 days to fix it and settle the debt before you suspend my access. If the trigger amount is the same as the max owed, I have zero time (well, presumably there is already some wiggle room for the time it takes to process the transaction).
I see what you mean — yes, this could be useful to some customers. We already implement a small grace amount above the max-owed limit that allows for continued service; your idea would essentially allow the customer to increase the default grace amount.
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.
In EU, this depends mainly on the question of exchange/interchangeability: If you sell them as vouchers and do not allow redeeming/payout in the original cash, its not a problem.
The key legal issue is interchangeability. Single-merchant vouchers are generally acceptable. If a voucher can be used across multiple merchants, it's often treated as e-money in the EU. Not being able to use funds across multiple merchants would significantly reduce the value for customers, as they would no longer be able to share payment processing fees across merchants.
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..
Surely you want any company that offers a prepaid credit card to be regulated, so that you can be extremely sure they won't just take your money and run.
And what really is the difference between a prepaid credit card and prepaid credits you can use at a large selection of tech companies. (Legally there is no distinction)
The problem is the constant charge part that comes along with the percentage part of commissions that payment processors companies takes.
Spending 100$ in 1 dollar each transactions mean I end up spending extra 30$, on top of the percentage charges.
A system based on tokens only takes the percentage part(as expected), but the constant part is added just once.
It opens up per-request charging model, across service providers.
This benefits both: the consumers for obvious reasons, and sellers since now customers don't have to "commit" to subscription or a large charge for a servive they may or may not use or continue.
> 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.
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 was thinking more in an upfront payment model, where the customer pre-funds their account with the merchant. If you immediately sent those funds to the merchant, then would you avoid functioning as an e-money institution?
Of course, this would then mean that the customer is trusting merchant not to run off with their money.
That's an interesting idea. This may avoid the e-money issues, but:
- The customer has to pay upfront, which lowers conversion rates.
- No shared balance across multiple merchants, resulting in higher total payment processing fees.
- As you already noted, trust shifts to each merchant to honor unused balances.
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.
Authorization hold periods are set by the card networks/issuers and by merchant category, not Stripe.
Even if longer holds were possible, using authorization holds as a prepayment proxy can raise regulatory/consumer-protection issues similar to holding customer funds.
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.
You're correct that this adds a barrier to entry, but for many users, that hurdle is still lower than asking them to start a subscription or buy a prepaid bundle.
We plan to provide the classic "Google Sign-In" style pop-up window instead of a redirect. Research indicates that it can increase conversion by approximately 5-10%.
Additionally, we are considering a white-label onboarding flow. If the merchant provides proof of customer identity, we can also skip the sign-in step. Both of these should help improve conversion rates.
A fully embedded solution is possible, but it would require the merchant to collect the customer's card details on Small Transfers' behalf (using Small Transfers' Stripe publishable key), which complicates things from both implementation and legal perspectives.
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 misunderstood this comment originally. In principle, Small Transfers (ST) could let a content site bill AI agents per request. Each site (acting as an ST merchant) would expose a simple "content" endpoint. The AI agent (as an ST customer) would perform a headless OAuth flow, after which the content site could charge for access. We currently don't support headless OAuth, but if anyone is interested in exploring this use case, please get in touch.
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 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.
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.
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.
Micropayments introduced too much friction for you, a human. You have to think about how much the thing is worth, and consider whether the merchant is trustworthy, and enter your details to perform the transaction. Maybe you’re unsatisfied and want a refund.
Say it costs 1.7 cents and delivers 3.2 cents of “value”, you need to be able to do all that work in less than 1.5 cents worth of your time. You can’t do that as a human. But an agent maybe could, to pay for content or MCP calls. I see a big role for micropayments in this genetic future.
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
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.
I really like the growing maximum owed limit idea and it would be really interesting to also make it possible to set an auto payment threshold lower than it.
The idea being something like "charge at X € owed but let it go up to N*X € if a payment fails before suspending service" where the N scales with something like the number of paid invoices or even total past spend.,
The primary objective of the max-owed limit is to cap per-customer risk.
If you are suggesting that the max-owed limit is actually N×X, then that would multiply worst-case exposure by N, which is undesirable.
If you are suggesting that we charge the customer when they owe X while their max-owed limit is N×X, this would be worse for the customer, since they would pay `N × (X × variable_rate_fee + fixed_rate_fee)` instead of `N×X×variable_rate_fee + fixed_rate_fee` in payment processing fees.
If your payment processor takes a per-transaction fee (not all do) then yes, this is a slightly worse deal for the customer. However, I think this would still be a good choice to give them, even if many would probably not chose it in order to save a few cents.
If I burn 1 € per day and my max owed based on whatever risk assessment is 20 €, I can set my payment treshold to 15 €, meaning if a payment fails, I have 5 days to fix it and settle the debt before you suspend my access. If the trigger amount is the same as the max owed, I have zero time (well, presumably there is already some wiggle room for the time it takes to process the transaction).
I see what you mean — yes, this could be useful to some customers. We already implement a small grace amount above the max-owed limit that allows for continued service; your idea would essentially allow the customer to increase the default grace amount.
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.
In EU, this depends mainly on the question of exchange/interchangeability: If you sell them as vouchers and do not allow redeeming/payout in the original cash, its not a problem.
The key legal issue is interchangeability. Single-merchant vouchers are generally acceptable. If a voucher can be used across multiple merchants, it's often treated as e-money in the EU. Not being able to use funds across multiple merchants would significantly reduce the value for customers, as they would no longer be able to share payment processing fees across merchants.
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..
Surely you want any company that offers a prepaid credit card to be regulated, so that you can be extremely sure they won't just take your money and run.
And what really is the difference between a prepaid credit card and prepaid credits you can use at a large selection of tech companies. (Legally there is no distinction)
The problem is the constant charge part that comes along with the percentage part of commissions that payment processors companies takes.
Spending 100$ in 1 dollar each transactions mean I end up spending extra 30$, on top of the percentage charges.
A system based on tokens only takes the percentage part(as expected), but the constant part is added just once.
It opens up per-request charging model, across service providers.
This benefits both: the consumers for obvious reasons, and sellers since now customers don't have to "commit" to subscription or a large charge for a servive they may or may not use or continue.
I don't really see the connection between my comment and your reply. Constant charges aren't necessary for regulatory reasons?
Misread your question. Apologies.
> 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:
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.
I was thinking more in an upfront payment model, where the customer pre-funds their account with the merchant. If you immediately sent those funds to the merchant, then would you avoid functioning as an e-money institution?
Of course, this would then mean that the customer is trusting merchant not to run off with their money.
That's an interesting idea. This may avoid the e-money issues, but:
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.
Authorization hold periods are set by the card networks/issuers and by merchant category, not Stripe.
Even if longer holds were possible, using authorization holds as a prepayment proxy can raise regulatory/consumer-protection issues similar to holding customer funds.
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!
That's a very cool idea!
To me the main barrier of adoption would be asking my users to create an account with a 3rd party provider in order to be able to pay me.
That's a lot of added friction and I'd be afraid of the impact this would have on conversion rates.
Wouldn't it be possible to embed your solution on my website so the user just adds their Credit Card once then gets properly billed from there?
You're correct that this adds a barrier to entry, but for many users, that hurdle is still lower than asking them to start a subscription or buy a prepaid bundle.
We plan to provide the classic "Google Sign-In" style pop-up window instead of a redirect. Research indicates that it can increase conversion by approximately 5-10%.
Additionally, we are considering a white-label onboarding flow. If the merchant provides proof of customer identity, we can also skip the sign-in step. Both of these should help improve conversion rates.
A fully embedded solution is possible, but it would require the merchant to collect the customer's card details on Small Transfers' behalf (using Small Transfers' Stripe publishable key), which complicates things from both implementation and legal perspectives.
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
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.
This could be a great way to charge ai for access to content.
I misunderstood this comment originally. In principle, Small Transfers (ST) could let a content site bill AI agents per request. Each site (acting as an ST merchant) would expose a simple "content" endpoint. The AI agent (as an ST customer) would perform a headless OAuth flow, after which the content site could charge for access. We currently don't support headless OAuth, but if anyone is interested in exploring this use case, please get in touch.
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 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
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.
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.
Micropayments introduced too much friction for you, a human. You have to think about how much the thing is worth, and consider whether the merchant is trustworthy, and enter your details to perform the transaction. Maybe you’re unsatisfied and want a refund.
Say it costs 1.7 cents and delivers 3.2 cents of “value”, you need to be able to do all that work in less than 1.5 cents worth of your time. You can’t do that as a human. But an agent maybe could, to pay for content or MCP calls. I see a big role for micropayments in this genetic future.
nice idea. Web3 was supposed to solve this (by skipping visa/mastercard/paypal's crazy fees) still waiting..
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!
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
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
If I need this I don’t deserve to survive in the SaaS business.