
Stripe charged me $714 for duplicate transactions within seconds - newsbinator
I just had a client pay $8,200, and they must have hit the submit button over and over. 6 times actually, but luckily their bank blocked all but 3 of the payments.<p>I had to refund 2 of those, and Stripe has charged me $714 in refund fees.<p>Their live chat and phone support all insist that it&#x27;s expected that Stripe would process $8,200, submitted over and over within seconds to the same credit card, and wouldn&#x27;t block it.<p>I guess it&#x27;s true that I signed up for this when I signed up for Stripe. And it&#x27;s obvious that the payment flow was misconfigured and the least I could do is disable the submit button upon click.<p>Although wow... I would have trusted Stripe to have some degree of obvious safety net against duplicate transactions until today.<p>I figured I&#x27;d put this out there in case anybody else finds themselves in the same situation.
======
Someone1234
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](https://stripe.com/blog/idempotency)

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

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

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

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

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

------
edwinwee
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](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.

~~~
leto_ii
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?

~~~
edwinwee
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](https://stripe.com/docs/radar/risk-evaluation#high-risk)

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

~~~
leto_ii
Thanks for the reply :)

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

~~~
DougWebb
Just came to recommend idempotency keys as well.

[https://stripe.com/docs/api/idempotent_requests](https://stripe.com/docs/api/idempotent_requests)

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

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

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

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

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

~~~
nickfromseattle
Wire transfer. Fee is capped at $35.

~~~
olliej
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)

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

