They offer Idempotent Requests[0][1] to prevent exactly this. While I think it is a shame you're in this position, I am surprised anyone would perform card transactions without a debounce of any kind (even disabling the UI element until the previous request completes/fails).

As to if Stripe should "allow" this; while I think $8,200 is too much for repeat transactions, I don't think repeat identical transactions is that odd in general. Even within a couple of seconds (e.g. 99 cent in-app-purchases). The only thing that surprises me is that there is no upper limit/sanity check.

You could ask them to waive some of the fee, but some of it might be their costs.

[0] https://stripe.com/blog/idempotency

[1] https://stripe.com/docs/api/idempotent_requests

At a brief glance it seems they ensure idempotency w.r.t. possible errors/network failures etc. not necessarily to multiple purchases done by the customer by mistake.

In that case I think some high velocity fraud filters should kick in (which they probably did). Indeed the purchase amount is very large, so you wouldn't really expect it to be a repeated high velocity buy. On the other hand Stripe can't really cover all possible edge cases all of the time.

You render a UUID into the browser form and send it along with the submission however you want (post input, http header, etc). Then the server both requires the UUID to be there and passes it along to stripe.

Stripe will not allow an idempotent key to be reused w/i 24 hours.

You can use anything for the idempotent key and Stripe will actually track that along with the charge object so you can use something more meaningful if it's useful for your business.

edit: and if you generate a key that's more meaningful I'd be careful about leaking important/private data.

Yeah, but that should only prevent duplicates due to technical errors, but not duplicates because the person actually made a number of distinct purchases my mistake.

Take a look also at edwinwee's answer below.

What you just said is 100% incorrect and I strongly recommend you read back over what I wrote and think about it a bit more.

Agree with the other comments on idempotency. If you need help with that, please let me know.

(Also: Stripe‘s Payment Intents API is asynchronous, which means no double charges. I’d recommend looking into it! https://stripe.com/docs/payments/payment-intents)

I’d love to take a closer look at exactly what happened if you email me at edwin@stripe.com.

Big thank you to Edwin for emailing & helping me solve the issue.

Just out of curiosity, does the idempotency guarantee cover deliberate shopper actions, or just retries due to network errors?

Shouldn't high velocity + high amount purchases be treated as potential (friendly) fraud and blocked by some fraud system somewhere?

Idempotency doesn't. It's meant to prevent duplicate actions.

For what you're talking about, that fraud system is already built into Stripe! Stripe's fraud shield detects high velocity (along with hundreds of other signals)[1]. You can also tune Stripe Radar[2] to block purchases with amounts that would be abnormally high for your business.

[1] https://stripe.com/docs/radar/risk-evaluation#high-risk

[2] https://stripe.com/docs/radar/rules

Thanks for the reply :)

Two words: idempotency keys. I personally feel Stripe does people a huge disservice not turning this on by default. We did something similar in the earlier days before idempotency keys. Worse than that, it was on a debit card...

Just came to recommend idempotency keys as well.

https://stripe.com/docs/api/idempotent_requests

The whole idea of charging for refunded transaction is scummy.

I have an old enough Stripe account from before they implemented this so I still enjoy free refunds but if I had to start today I’d definitely look around for another provider that doesn’t pull this kind of BS.

Ouch. Did this happen on a Stripe-hosted checkout form, or did you use something like Stripe Elements to handle it yourself?

Not OP but it sounds like they were using Elements ("the payment flow was misconfigured and the least I could do is disable the submit button upon click"). I would hope that Stripe's own checkout form is well-rounded enough to handle things like this.

Why are you using stripe to process transactions that large? It makes no sense to pay 3% on that.

This is for a Hong Kong company processing a US client's credit card. What would be a better option?

Wire transfer. Fee is capped at $35.

I’ve done plenty of SWIFT international wire transfers. Total cost in practice is much higher than the “cap” of $35, especially when both parties costs are taken into account.

The biggest hit is usually the foreign currency conversion spread which is enormously unfavorable compared to the forex spot rate.

Then there are lots of problems if your bank doesn’t have a direct correspondant bank relationship with the Hong Kong bank and instead relies on other banks to handle that for them - this can lead to delays of up to a week and quite often leads to a link in the chain rejecting things for some reason (perhaps fraud checks or “know your customer” issues or perhaps one bank stripped all leading zeroes from the account number).

International wires are a pain in the ass, especially for relatively low sums like a few thousand dollars.

Personally, I use TransferWise for most international transactions now - it’s fast and the spread is much better.

Wire transfers can take days (I’ve once had it take more than a month), generally aren’t reversible, and it’s difficult to verify everything is correct beyond read through what you’ve entered multiple times.

There’s also no receipt you can point to to show the intended recipient was who received it.

That’s a huge disincentive for the client/customer to pay that way, and for the receiver the large delay in receiving money can be limiting as well.

Obviously it’s absurd that we’re still in this position in 2020 (that there isn’t a close approximation of instantaneous international transactions at a reasonable - eg fixed - price is beyond stupid)

That's a rather pessimistic view of bank transfer. Companies doing B2B transactions above 10k regularly use and often prefer bank transfer. It's more security for both the buyer and the seller, no fees, and cheaper exchange rate if changing currencies.

The reversibility of card charges is a huge con, not a pro. Don't want it for large transactions, especially if involving physical goods (non recoverable costs). Besides, chargeback is a privilege reserved to consumers, it's not available to business accounts.

Sure, if the customer is okay with that.

I've had clients that would prefer to pay 3% to be able to use their credit card to pay an invoice, rather than go through a wire transfer process.

You can just add the fee onto the charge, and let the customer decide if the convenience of paying with a card is worth it.

There are still jurisdictions where you can't tack on this fee.

Good suggestion. Is there a convenient (for the end user) approach to handling wire transfer on a web page?

(i.e. the polished Stripe checkout version of wire transfer)

Nope, they have to initiate from their bank. Many of which don’t have online WT services (the fraud potential is clearly huge)

That was my best information as well- the process of initiating a wire transfer from their bank is likely too much friction in many cases.

Not to mention the lack of protection the buyer would feel, as compared to a Credit Card.

If it's a Hong Kong customer, obviously doing international business, they're most likely banking with HSBC and have good online banking with instant bank transfer.

Do banks still exist that don’t allow for online international transfers? Are you sure?

Small credit unions, and I don’t recall seeing any on NZ banking sites when I grew up - they essentially have domestic WTs because you can send money to anyone’s bank account online (in NZ having someone’s bank account number means you can send them money, not the US absurdity of withdrawing money)