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