- 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.
huem0n 2 days ago [-]
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.
perilunar 20 hours ago [-]
10¢ per hour seems low to me — I’d happily pay ~$1 per hour. $10 per week is less than I currently pay for subscriptions, and I don’t want to spend more than 10 hrs per week watching video anyway.
strnisa 2 days ago [-]
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.
cedws 22 hours ago [-]
I don’t know if it defeats the purpose but you could require an upfront, refundable deposit.
strnisa 19 hours ago [-]
Requiring money upfront would classify the platform as an e-money institution, which is highly problematic from the legal perspective.
jazzyjackson 14 hours ago [-]
How does tarsnap handle it? I think there's lots of services that bill up front... Isn't it only e-money if you can convert it back to cash?
strnisa 13 hours ago [-]
If you store funds for a specific service that you provide, it's fine. If it's for many services or services provided by others, it's legally problematic.
smoyer 2 hours ago [-]
Interesting ... A web2 equivalent to the x402 specification. Thanks for the explanation of how fees are handled below.
What's the payment threshold? I assume you're paying 2.9% and $0.30 (or around there) for the transaction. You charge that to the customer but what if their bill is $0.01, are you really going to make them pay $0.32 for $0.01 of usage? How do you expect SaaS providers to communicate that on their pricing page? If they charge $0.01 per request and the end-user makes 100 requests their bill is actually $1.33 which means the actual per-request charge is $0.0133.
Several years ago Stripe offered more favorable pricing for small transactions but it's my understanding that that pricing is no longer available to new Stripe businesses.
strnisa 16 hours ago [-]
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.
soared 60 minutes ago [-]
Good use case for stablecoin/crypto through stripe
freakynit 2 days ago [-]
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.
strnisa 2 days ago [-]
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.
otterley 1 days ago [-]
What happens when customers don't pay their balance?
What happens when the charge attempt fails after initial preauth?
strnisa 1 days ago [-]
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.
otterley 1 days ago [-]
I'm a little confused. Is Small Transfers not the merchant for the CC transaction? (Your website suggests Small Transfers is the merchant of record and then transfers funds to the seller.) If not, what's your role in the settlement process?
strnisa 1 days ago [-]
Yes, Small Transfers is the merchant of record for the card charge. We transfer only funds actually received to the merchant's Stripe account; we don't advance funds. As per the Terms (§1 "Transfer" and §5.6 "Non-Payment"), chargebacks/reversals are net-deducted from future transfers, so the seller bears non-payment risk.
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!
drewp 1 days ago [-]
https://en.wikipedia.org/wiki/Flattr figured out some parts of this. Notably, you picked your own total monthly donation, and then clicked a button on participating sites to allocate a fraction of your total to them. AFAICT it worked as advertised, but raised new issues with donation behavior. E.g. I obviously like curl every month, so should I click its button monthly? Twice monthly? If I am a developer of some other useful OSS software, should I click curl's button and the curl devs click my button? Does the money just slosh around between merchant-customers? Is that good?
ed 1 days ago [-]
See also: Kachingle (2007), Amazon Flexible Payment Service (2007), Dwolla (2008), Tipjoy (2008), Facebook Credits (2009), Google Checkout (2006), Flattr (2010), Changetip (2014)
strnisa 1 days ago [-]
I believe the idea has been attempted many times before, primarily 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. One of the main legal complications 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 simply pay for what they owe, usually at the end of each month.
- There is a lower psychological barrier, since there is no subscription or prepay commitment. Customers who dislike recurring payments are more willing to try something new that avoids this.
- Merchants need to introduce customers to just one extra service, Small Transfers.
Some customers of Unattach (a service I built) are happily paying for the service via Small Transfers, and early feedback shows that they really appreciate this pricing model. It's worth noting that Unattach also supports the classic subscription model.
As more merchants adopt Small Transfers, customers will still only need one account, making micro-billing even more convenient.
kolistivra 2 days ago [-]
Cool! Does it use crypto?
strnisa 2 days ago [-]
Thanks! Small Transfers uses its own system for tracking usage, which is settled through Stripe. No crypto, tokens, or wallets.
codedokode 1 days ago [-]
Convenient - the government always can know who watched what.
blacksmith_tb 1 days ago [-]
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?
64718283661 20 hours ago [-]
The fake ones can be filtered out easily because the interaction and behavior is different
PhilippGille 1 days ago [-]
I think micropayments are important for a healthy web economy.
In 2018 I built a pay-per-call API paywall using the Lightning Network (a Bitcoin Layer 2 protocol/network that enables instant, low-fee payments): https://github.com/philippgille/ln-paywall
But most people are either unwilling to touch crypto at all, or holding on to it tightly as investment and not willing to use as payment.
So I wish you luck to make this work in the fiat world!
strnisa 1 days ago [-]
Nice work and thank you for the encouraging words!
up2isomorphism 13 hours ago [-]
If I need this I don’t deserve to survive in the SaaS business.
petertodd 1 days ago [-]
Why would you use this over Bitcoin Lightning payments?
Spivak 24 hours ago [-]
Because it works with a credit card? Also unless you do what this service is doing by accumulating payments until a reasonable threshold is reached before actually charging the fees then even on Lightning will eat you alive. So if you have the system to handle billing this way you might as well use existing payment networks.
yieldcrv 7 hours ago [-]
unsecured lending in the crypto world is nonexistent or implodes immediately, and even more nonexistent in the bitcoin side of things
credit cards solve that market need and are wildly popular for decades
2 days ago [-]
Rendered at 02:53:42 GMT+0000 (Coordinated Universal Time) with Vercel.
- 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.
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.
https://x402.org
Several years ago Stripe offered more favorable pricing for small transactions but it's my understanding that that pricing is no longer available to new Stripe businesses.
Secondly, the legal aspect. Will this be considered as a wallet?
Anyways, loved to see it implemented by someone.
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 the charge attempt fails after initial preauth?
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.
Details: https://smalltransfers.com/terms
With Small Transfers:
Some customers of Unattach (a service I built) are happily paying for the service via Small Transfers, and early feedback shows that they really appreciate this pricing model. It's worth noting that Unattach also supports the classic subscription model.As more merchants adopt Small Transfers, customers will still only need one account, making micro-billing even more convenient.
In 2018 I built a pay-per-call API paywall using the Lightning Network (a Bitcoin Layer 2 protocol/network that enables instant, low-fee payments): https://github.com/philippgille/ln-paywall
But most people are either unwilling to touch crypto at all, or holding on to it tightly as investment and not willing to use as payment. So I wish you luck to make this work in the fiat world!
credit cards solve that market need and are wildly popular for decades