I've been wanting something like this for a long time. There's a lot of ways this could go wrong, but I hope it works.
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.
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.
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.
I mean this in the most constructive way possible: why do you think this idea hasn’t worked before, when it’s been fairly obvious and easy to build for a long time? And what’s your fix for that issue? You present the merchant side of things, but not the customer side which is more important to me, as a potential Small transfers adopter. What’s customer conversion like? Are micropayments actually better than typical payment amounts? Based on my experience I’d expect the conversion rate of a $0.01 and $1 fee to be pretty similar. The friction of inputting a credit card and trusting a service is way higher than the actual payment amount. I’d also have to introduce 2 more services to my customers: Small transfers powered by stripe, and customers would have to fund an account that realistically speaking can’t be used anywhere other than my site. Just offering some questions to think about!
I think the idea has been attempted many times before, mostly 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. The main legal complication 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 pay for what they owe at the end of each month.
- There is a lower psychological barrier, since there is no subscription or prepay commitment. Customers who don't like recurring payments are much more willing to try something new that avoids this.
- Merchants only need to introduce customers to one other service, Small Transfers.
Some Unattach (a service I built) customers are happily paying for the service via Small Transfers, and our qualitative feedback shows that they really appreciate this pricing model. It's worth noting that Unattach also supports the classic subscription model.
I had 100% same idea since a few months now. Didn't pursue it because of lack of companies and customers willing to use such a platform as intermediatory.
Secondly, the legal aspect. Will this be considered as a wallet?
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.
Ultimately, the merchant bears the risk of non-payment, but the platform does its best, using industry-standard practices, to pre-check the customer and their payment methods for fraud and ensure a successful payment.
If a merchant successfully authorizes a charge, the amount is reserved for that merchant for a limited period. Trying to capture that amount (or less) during this period will succeed.
I've been wanting something like this for a long time. There's a lot of ways this could go wrong, but I hope it works.
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.
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.
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?*
*How it works?* 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:
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.
I mean this in the most constructive way possible: why do you think this idea hasn’t worked before, when it’s been fairly obvious and easy to build for a long time? And what’s your fix for that issue? You present the merchant side of things, but not the customer side which is more important to me, as a potential Small transfers adopter. What’s customer conversion like? Are micropayments actually better than typical payment amounts? Based on my experience I’d expect the conversion rate of a $0.01 and $1 fee to be pretty similar. The friction of inputting a credit card and trusting a service is way higher than the actual payment amount. I’d also have to introduce 2 more services to my customers: Small transfers powered by stripe, and customers would have to fund an account that realistically speaking can’t be used anywhere other than my site. Just offering some questions to think about!
I think the idea has been attempted many times before, mostly 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. The main legal complication is the one mentioned in another comment: avoiding the status of an e-money institution.
With Small Transfers:
Some Unattach (a service I built) customers are happily paying for the service via Small Transfers, and our qualitative feedback shows that they really appreciate this pricing model. It's worth noting that Unattach also supports the classic subscription model.I had 100% same idea since a few months now. Didn't pursue it because of lack of companies and customers willing to use such a platform as intermediatory.
Secondly, the legal aspect. Will this be considered as a wallet?
Anyways, loved to see it implemented by someone.
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.
What happens when customers don't pay their balance?
What happens when the charge attempt fails after initial preauth?
Ultimately, the merchant bears the risk of non-payment, but the platform does its best, using industry-standard practices, to pre-check the customer and their payment methods for fraud and ensure a successful payment.
If a merchant successfully authorizes a charge, the amount is reserved for that merchant for a limited period. Trying to capture that amount (or less) during this period will succeed.
Cool! Does it use crypto?
Thanks! Small Transfers uses its own system for tracking usage, which is settled through Stripe. No crypto, tokens, or wallets.
Convenient - the government always can know who watched what.
Hmm, but it's a bargain to stuff false data in there too, just pay tiny fractions of a cent to send them your My Little Pony watching habits mixed in?