Show HN: Small Transfers – charge from 0.000001 USD per request for your SaaS (smalltransfers.com)
Hi HN,
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.
29 comments
[ 3.7 ms ] story [ 69.8 ms ] threadSecondly, the legal aspect. Will this be considered as a wallet?
Anyways, loved to see it implemented by someone.
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.
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.
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
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.
- 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.
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.
https://x402.org
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.
Your pricing is a bit weird though. For a $9 subscription a year, I might as well upgrade my gmail storage to 100gb.
The pay-as-you-go is $0.01 per email, but I don't know how many emails with attachment I have in there. Gmail only tells me of "many". Could be tens of thousands... I have no idea...
I have 250 emails with attachment since June, so a bit less than 100 per month, and I 've had that inbox since 2004 ish. So conservatively, I have 1200 emails a year, so about 25k emails to clean up. So that would be a one time fee of $24. But perhaps much less because attachments were rarer back then.
But I could also pay a one year subscription. Only use it once to clean up the whole thing, and then cancel and come back the next time I need it, like in 5 years. But yeah, I don't really want to do that, cause I don't want to forget that it's a subscription...
What I would like is a usage-based price, that's based off the inbox size in gb and that's quite cheaper than upgrading my gmail.
So maybe cleaning 15gb for $15 would be great. Or maybe $2 for each gb that's freed (I wouldn't know how much exactly that would cost, but I know it'd less that $30).
On PAYG, you can target the largest emails first and stop whenever you've freed enough space. For example, processing 300 of the largest emails at $0.01 each is about $3; if they average around 10 MB, that's 3 GB freed.