Show HN: Small Transfers – charge from 0.000001 USD per request for your SaaS

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.

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.

> 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.

$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.

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.

I understand not wanting another subscription. You can subscribe and then immediately turn off auto-renewal — your access stays active for the full year you paid for.

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.

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.

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.

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.

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 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.

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.

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.

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.

Nice work and thank you for the encouraging words!

Thanks! Small Transfers uses its own system for tracking usage, which is settled through Stripe. No crypto, tokens, or wallets.

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