Comment by Roguelazer
5 months ago
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.
We run Stripe Radar and 3-D Secure when adding a card (before first use), which filters out a lot of obvious fraud (and 3DS often shifts liability to card networks in many regions).
The balances are not settled just at the end of the month. Each customer has a "maximum owed limit", which starts low (currently 10 USD) and grows with successful payments (up to 30 USD currently). The customer is charged as soon as they hit that limit (with some grace to allow for continued use).
Idempotency keys are on the near-term roadmap. Access tokens do not currently expire; however, they can be revoked by the customer at any time.
I really like the growing maximum owed limit idea and it would be really interesting to also make it possible to set an auto payment threshold lower than it.
The idea being something like "charge at X € owed but let it go up to N*X € if a payment fails before suspending service" where the N scales with something like the number of paid invoices or even total past spend.,
The primary objective of the max-owed limit is to cap per-customer risk.
If you are suggesting that the max-owed limit is actually N×X, then that would multiply worst-case exposure by N, which is undesirable.
If you are suggesting that we charge the customer when they owe X while their max-owed limit is N×X, this would be worse for the customer, since they would pay `N × (X × variable_rate_fee + fixed_rate_fee)` instead of `N×X×variable_rate_fee + fixed_rate_fee` in payment processing fees.
2 replies →
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.
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.
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.
1 reply →
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..
4 replies →
> anything popular that used this system seems like it'd be pretty inundated with fraud
I coined "micropayments means microfraud"; I would expect this to have similar situations to the AWS mystery bill problem, but on a tiny scale. If you can charge customers without their confirmation it's easy to run up bills. And of course the amounts are so tiny you can't afford dispute resolution.
Yes, merchant abuse is a risk. What we do and plan to do: