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.
> customer defaulting after using a merchant's service
I think the defaulting rate would just get baked into the asking price. But I'm assuming there isn't a way to repeatedly systematically default to get unlimited free content.
Each customer already has a limit on the amount they can owe before we require payment. Each customer account also requires a unique payment method, which must pass Stripe Radar and 3-D Secure checks. We plan to add more checks in the future.
I don’t know if it defeats the purpose but you could require an upfront, refundable deposit.
Requiring money upfront would classify the platform as an e-money institution, which is highly problematic from the legal perspective.
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?
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.
What if you inverted the trust equation by giving the money to the service provider immediately, rather than holding any of the up front payment?
We don't hold upfront funds. When a customer pays, we initiate Stripe transfers to the merchant as soon as the funds are available.
Paying the merchant before the customer's card payment settles would mean advancing funds, which would start to resemble lending/guarantee rather than payments, raising regulatory issues. It would also concentrate risk at the platform: defaults from one merchant’s customers could jeopardize the platform for all merchants.
I was thinking more in an upfront payment model, where the customer pre-funds their account with the merchant. If you immediately sent those funds to the merchant, then would you avoid functioning as an e-money institution?
Of course, this would then mean that the customer is trusting merchant not to run off with their money.
That's an interesting idea. This may avoid the e-money issues, but:
Ah neat, thanks for the clarification.
> Requiring money upfront would classify the platform as an e-money institution, which is highly problematic from the legal perspective.
What if you just reserve it on the card?
Online card holds typically expire in ~7 days (often sooner, depending on the issuer), which is too short for our use case.
I thought 30 days are an option at least when you can explain the reason/necessity to stripe?
Could be an option to funnel default-risky (as distinct from chargeback-risky!) customers to a customer-selectable hold amount rolling the per-transaction flat fee into basically a per-bill flat fee thus indirectly giving volume/commitment discounts to those that select 30-day intervals with large holds?
I guess ideally offer an option to force a billing (transaction finalization) to release the hold if a customer changes their mind (or just happened to use a debit card)...
Though even with 7 day holds it'd allow you to offer service to poor people (which mostly overlaps "people with bad credit") without the APIs having to maintain revenue margins large enough to just eat that default risk, and without having to hold onto any funds yourself.
Authorization hold periods are set by the card networks/issuers and by merchant category, not Stripe.
Even if longer holds were possible, using authorization holds as a prepayment proxy can raise regulatory/consumer-protection issues similar to holding customer funds.