I built Small Transfers, a payments platform for SaaS / API makers who want to bill customers per request instead of pushing them into subscriptions or pre-buy packages.
*Why?*
- Many customers hate subscriptions and/or want to use a service occasionally.
- Traditional payment processors add a fixed fee to every charge, making charges below 1 USD impractical.
- Stripe UBB tracks usage, but you still need to write your own auth, add spending limits, and each merchant charges cards separately (extra fees for customers).
- Each merchant has a Small Transfers account linked to their Stripe account via Stripe Connect, which is used to transfer payouts to merchants.
- Each customer has a Small Transfers account where we verify them using Google Sign-In, 3-D Secure, and Stripe Radar to minimise the chances of a customer not paying their balance.
- Customers allow your service to identify and charge them via platform's own OAuth. This also removes the need for your service to implement its own auth. (Simple services don't even need their own database.)
- Merchants call a simple REST API to authorize and capture a charge with a minimum amount of 0.000001 USD. Note that you can authorize more than you capture, allowing you to authorize the max amount your request might use, and then capture your actual cost plus margin (great for many use cases, e.g., AI).
- The platform takes care of charging customers and sending payouts to merchants.
- Merchants pay a flat 3% fee. Customers pay payment processing fees when they pay for their balance.
I've been dog-fooding the platform with my own service (https://unattach.com/) and would love your feedback, specifically:
- The general approach and whether there is anything I should do differently.
- Any concerns and how I could mitigate them.
- Any other feedback.
Thank you for your time! Happy to answer questions here.
- 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.
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.
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.,
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 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).
It’s similar to a digital wallet, but without currency conversion: customers cannot exchange tokens back into money.
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)
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 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.
- 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'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.
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.
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.
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.
Of course, this would then mean that the customer is trusting merchant not to run off with their money.
- 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.What if you just reserve it on the card?
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.
Even if longer holds were possible, using authorization holds as a prepayment proxy can raise regulatory/consumer-protection issues similar to holding customer funds.
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.
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?
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.
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.
Small Transfers: card rails (Stripe), account-based, off-session, batched billing with spend caps; no tokens/wallets.
Secondly, the legal aspect. Will this be considered as a wallet?
Anyways, loved to see it implemented by someone.
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 the charge attempt fails after initial preauth?
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.
Details: https://smalltransfers.com/terms
Small Transfers can be added to help with:
- users who dislike subscriptions
- infrequent users
- reducing/removing free-trial costs for non-converting users
I believe that Small Transfers also enables services that aren't viable with subscriptions or prepaid credits, e.g., a movie-suggestion service.
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.
As more merchants adopt Small Transfers, customers will still only need one account, making micro-billing even more convenient.
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.
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!
credit cards solve that market need and are wildly popular for decades
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