←back to thread

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

(smalltransfers.com)
194 points strnisa | 8 comments | 10 Sep 25 12:56 UTC | HN request time: 1.252s | source | bottom

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).
*How it works?*

  - 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.
There's a Next.js Starter project (https://github.com/smalltransfers/nextjs-starter) and a live demo (https://nextjs-starter.smalltransfers.com/).

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.
I'm also looking for more merchants to try out the platform, and can help you with the integration.

Thank you for your time! Happy to answer questions here.

Show context
Roguelazer ◴[11 Sep 25 23:03 UTC] No.45216996[source]▶
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.

replies(3): >>45218416 #>>45219763 #>>45221312 #
freakynit ◴[12 Sep 25 03:32 UTC] No.45218416[source]▶
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.

replies(1): >>45219818 #
1. strnisa ◴[12 Sep 25 07:58 UTC] No.45219818[source]▶
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.
replies(2): >>45229115 #>>45250127 #
2. freakynit ◴[13 Sep 25 03:39 UTC] No.45229115[source]▶
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..
replies(1): >>45236577 #
3. NoahZuniga ◴[14 Sep 25 01:00 UTC] No.45236577[source]▶
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)

replies(1): >>45238675 #
4. freakynit ◴[14 Sep 25 09:39 UTC] No.45238675{3}[source]▶
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.

replies(1): >>45239147 #
5. NoahZuniga ◴[14 Sep 25 11:53 UTC] No.45239147{4}[source]▶
I don't really see the connection between my comment and your reply. Constant charges aren't necessary for regulatory reasons?
replies(1): >>45246241 #
6. freakynit ◴[15 Sep 25 04:54 UTC] No.45246241{5}[source]▶
Misread your question. Apologies.
7. ta12653421 ◴[15 Sep 25 14:25 UTC] No.45250127[source]▶
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.
replies(1): >>45250252 #
8. strnisa ◴[15 Sep 25 14:39 UTC] No.45250252[source]▶
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.