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