I'm working on Small Transfers (https://smalltransfers.com/), a payment platform that makes it very convenient for SaaS / API makers to provide a pay-as-you-go model to their customers.
You can charge as little as 0.000001 USD per request. The platform uses our own system for tracking usage, which is settled through Stripe. No crypto, tokens, or wallets.
If combined with subscriptions, the pricing can work similarly to mobile plans, where monthly plans become cheaper above a certain usage threshold.
Looking for more developers to try it and share feedback.
Flattr was a micro-donation subscription service where users set a monthly budget that was allocated to creators.
Small Transfers is for usage-based billing of online services and APIs. There is no monthly budget, wallet, or pre-funding. Customers are charged only for actual usage.
Please consult how "blik" works in Poland. It requires a bank cooperation, but it ultimately became a standard here for payments as an alternative to debit/credit card payment.
BLIK is a bank-backed payment method used at checkout.
Small Transfers is an API for a merchant to charge a customer tiny amounts (as little as $0.000001), which are batched into a single card charge via Stripe.
Customers do create an account and provide a payment method, but they don't pre-fund or hold a balance, and they don't initiate a payment. Small Transfers is an API that allows merchants to charge very small amounts programmatically. At the end of each month (or earlier, if a threshold is reached), we charge the customer what they owe. This makes the tiny charges viable and avoids death-by-$0.30.
It's not a PayPal remake, since there are no wallets, no P2P transactions, and no stored funds. In addition, Small Transfers allows very small charges (as mentioned above), and provides customer OAuth and spending caps.
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.
From what I can find, Gripto was a cryptocurrency platform for viewing holdings, market info, and relevant news. It seems that the service was retired in late 2018.
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.
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.
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.
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.
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.
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
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.
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.
You can charge as little as 0.000001 USD per request. The platform uses our own system for tracking usage, which is settled through Stripe. No crypto, tokens, or wallets.
If combined with subscriptions, the pricing can work similarly to mobile plans, where monthly plans become cheaper above a certain usage threshold.
Looking for more developers to try it and share feedback.
Resources: integration guide (https://smalltransfers.com/merchant/docs/integration-guide), a quick walkthrough (https://youtu.be/WQW5fiUFNRk), a Next.js template (source code: https://github.com/smalltransfers/nextjs-starter, live demo: https://nextjs-starter.smalltransfers.com/), an AI template (source code: https://github.com/smalltransfers/ai-starter, live demo: https://ai-starter.smalltransfers.com/).