Stripe has decided to nuke my entire business

We hadn't charged a single live customer yet, but we had done plenty of tests using the Stripe testing environment. So we go live with a huge launch event, and we have customers signing up in droves. When they get to the last step -- payment -- they get an error.

Logging in to the dashboard I didn't see any indication that there was anything wrong with our account. No alerts or notices. We had already gone through the approval process you go through when signing up, and been told we were approved.

The thing that surprised me the most was that there was just no indication anywhere that our account would not be able to charge cards. Wouldn't it make sense for there to be an indicator somewhere that just says "Not ready yet"?

Apparently, they had never even begun reviewing/vetting us since the time we signed up for the account months earlier. We reached out to customer support and it took them about two weeks to get us activated. And, similar to OP, they never gave us a shred of information about what was going on. I still don't know to this day what the issue was.

Next time I build something with Stripe I'm going to test it in production before launching, with my own real credit card!

I'm genuinely curious why you wouldn't have done that anyway? I pretty much always do, precisely so I can experience a full end to end user experience.

Sure, you can do it, but you'll have to forever have a note in your accounts package saying 'this revenue isn't actual revenue'.

It really upsets those who want the accounts to match up to the cent at the end of the year...

"Do not use real card details. Testing in live mode using real payment method details is prohibited by the Stripe Services Agreement. Use your test API keys and the card numbers below."

https://stripe.com/docs/testing

That's in addition to explaining to our investors that we ended our launch day at -$1,000 due to all the chargeback fees because some dumb developer doesn't know what a testing environment is. And in addition to the fact that Stripe recommends against you testing in that way.

I did get a full end-to-end experience, in my production environment, with literally one variable changed: using the testing Stripe API key instead of the production one.

I don't know, it didn't seem like a crazy way of testing at the time. When you consider that the testing environment worked perfectly, and there was no indication, whatsoever, anywhere that we would not be able to charge cards, it kind of felt like how you're supposed to do it.

But clearly I was wrong :) The way you find out if your account has any issues is by charging a real card, and if it works, reversing it, and if it doesn't work, waiting a couple weeks with no information on what's going on. Lesson learned!

I'm curious why you would still consider them a trustworthy business partner after what happened?

What a disaster.

No appeal process, nothing. Caused significant short term cash flow issues. So be very careful using your own card.

Why would you reverse it? If you can’t afford to consume one unit of whatever you are selling are you really in a good place to be in that business?

I guess there can be rare exceptions where the business sell only a handfull of high ticket items. But then again probably Fincantieri does not let you put your bespoke mega yacht on a card through a web transaction.

They just walk in and buy one. They in their personal capacity end up richer by a burrito and some invaluable experience. The company ends up richer by the price of a burrito. If this kind of “revenue inflation” matters to anyone then either the CEO has a bad burrito addiction or the company wasn’t transacting enough anyway or both.

I don't know if that's still the case, but these days I'm wary about using AMEX on any sort of money transfer service.

I think that's the biggest thing I see on this thread. That Stripe gets the chance of a next time. This validates what Stripe is doing to developers.

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.

More and more, we just keep acting dumber as "tech" is more and more engrained

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)

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

Test in production. Do real dollar value tests. If you can test with different cards with different security levels, try a Visa 3D Secure and a 2FA Amex charge. Personally I do them and then get reimbursed (or do them directly on a company credit card) rather than start out a production payment history with refunds, not sure if that matters but I figure if it does it's got to be a bad signal so I may as well avoid 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.)

Why would you not? Stripe still keeps the transaction cost, so clearly they anticipate this happening.

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

After some eye-rolling he agreed to buy a burner phone, add a prepay SIM, and whaddayano the bloody charger did not work. Two months later it works, for most people, who have recent cars that are not Teslas. Sigh. "welcome to our product, you're a beta tester. Maybe an alpha tester. We hope it works!".

This isn't recommended. Also, presumably by end-to-end you meant post auth business flow too. Such as reconciliation, settlement, generating tax receipts, invoices etc.,

In general, all the data in production should be real, as much as possible.

If the amount is big (e.g., say jewellery story) then figure out a way to recoup/refund the money out of band in a way that leaves no trace in production system. E.g., reimburse it, put it under QA budget or some such.

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.

My recommendation is to look into your local providers and see if any can integrate with payment APIs like Authorize.net. These providers really want your business and care enough to at least not let you go bankrupt. The bar is low!