It's bullshit. Anyone with experience testing things in this area is 100% gonna try a real card at least after any major changes (and certainly before a launch of a new product). You aren't actually sure it's right (and so, with something so entirely connected to revenue, can't go the fuck to sleep) until a real charge has gone through.

They probably mainly just don't want people running shitloads of automated-test charges and issuing refunds for all of them. It may technically be against the TOS but there's no way they actually care if you run the occasional real-credentials test, especially if you don't refund it.

> especially if you don't refund it.

That's the trick. Let Stripe put the money into your bank account and let them think its a real sale (not a production test), then refund the money out of the bank account back to the person who's card was used instead of refunding or reversing the charge. Stripe don't need to know about that.

(You also owe yourself "due diligence" in knowing that you _can_ refund or reverse charges, so you'll also do that test in production as well, but don't make it one of the first transactions you ever do in prod. I try to stretch that test out until after a 60 day window past the first few dozen real sales have gone through, under the assumption that by then Stripe (or whoever) will have seen a bunch of payments go through and not be challenged when the CC statements arrive, and that'll have sent some "probably not a new fraudulent merchant" signals into their systems.)

This is what my team always did for QA when I worked in a space using payment processors.

No need to roll back the transactions directly and risk flagging anything.

Plus, it's often useful having a real, live, paid and in good standing account and/or purchase in the system for further testing steps! (More true in the subscription space than the one-time purchase space... but even there... it's probably worth testing your refund flow end to end periodically eventually, once you have a healthy set of traffic under your belt to avoid standing out.)

Refunds used to be free, but for a few years now Stripe keeps the transaction fees.

Although I guess doing lots of refunds would mess with anti-fraud and other systems.

I just do special pricing/discounts to do a $5 transaction (too small could look like credit card fraud).

Frankly that's a ridiculous clause. If you make a change (like switching from testing to live in the stripe dashboard) it needs to be tested, as OP's comment nicely demonstrates.

This cause exists not for product testing and QA but rather to prevent payment details for being abused in the name of “testing”.

Everyone runs 1-3 “real transactions” as a “real customer” when getting ready for a launch with QA.

This cause exists for Stripe to point to for excuses people make when attempting to wash transaction or test stolen CC info in a prod environment (which doesn’t work with a test api key)

Others replied already, but I'll chime in too.

There's "testing"

* manual during development

* automated testing

And there's "testing"

* smoke checking processes in production

In most cases, the "test in production" is more of a "validation" that end to end experience works. And there probably shouldn't really be much of a way to distinguish between a "test" in production and a "validation" of the purchase process.

The testing doc says it's against the agreement, but from a 1 minute look at the agreement, I can't find where the agreement bans testing in live mode. Do you see it?

Run a real card for a real amount and write a check to the person whose card you used. Do this multiple times with different types of cards.