undefined

points

[-]

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.

by franga2000146 days ago|

parent|

[-]

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

by strnisa146 days ago|

parent|

[-]

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.

by franga2000146 days ago|

parent|

[-]

If your payment processor takes a per-transaction fee (not all do) then yes, this is a slightly worse deal for the customer. However, I think this would still be a good choice to give them, even if many would probably not chose it in order to save a few cents.

If I burn 1 € per day and my max owed based on whatever risk assessment is 20 €, I can set my payment treshold to 15 €, meaning if a payment fails, I have 5 days to fix it and settle the debt before you suspend my access. If the trigger amount is the same as the max owed, I have zero time (well, presumably there is already some wiggle room for the time it takes to process the transaction).

by strnisa146 days ago|

parent|

[-]

I see what you mean — yes, this could be useful to some customers. We already implement a small grace amount above the max-owed limit that allows for continued service; your idea would essentially allow the customer to increase the default grace amount.

by freakynit148 days ago|

prev|

[-]

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.

by strnisa148 days ago|

parent|

[-]

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.

by ta12653421144 days ago|

parent|

[-]

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.

by strnisa144 days ago|

parent|

[-]

The key legal issue is interchangeability. Single-merchant vouchers are generally acceptable. If a voucher can be used across multiple merchants, it's often treated as e-money in the EU. Not being able to use funds across multiple merchants would significantly reduce the value for customers, as they would no longer be able to share payment processing fees across merchants.

by freakynit147 days ago|

parent|

prev|

[-]

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

by NoahZuniga146 days ago|

parent|

[-]

Surely you want any company that offers a prepaid credit card to be regulated, so that you can be extremely sure they won't just take your money and run.

And what really is the difference between a prepaid credit card and prepaid credits you can use at a large selection of tech companies. (Legally there is no distinction)

by freakynit146 days ago|

parent|

[-]

The problem is the constant charge part that comes along with the percentage part of commissions that payment processors companies takes.

Spending 100$ in 1 dollar each transactions mean I end up spending extra 30$, on top of the percentage charges.

A system based on tokens only takes the percentage part(as expected), but the constant part is added just once.

It opens up per-request charging model, across service providers.

This benefits both: the consumers for obvious reasons, and sellers since now customers don't have to "commit" to subscription or a large charge for a servive they may or may not use or continue.

by NoahZuniga146 days ago|

parent|

[-]

I don't really see the connection between my comment and your reply. Constant charges aren't necessary for regulatory reasons?

by freakynit145 days ago|

parent|

[-]

Misread your question. Apologies.

by pjc50148 days ago|

prev|

[-]

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

by strnisa147 days ago|

parent|

[-]

Yes, merchant abuse is a risk. What we do and plan to do:

  - Each merchant requires an OAuth grant, and customers can revoke it at any time.
  - A customer ledger shows what, when, and how much each merchant charged. This can be shown in the customer's dashboard and monthly statement emails.
  - Customers have account-level spending caps to limit exposure. We will add per-merchant caps.
  - If patterns look off or we get complaints, we can pause new charges and review.