Comment by apeace | Hacker News Reader

Comment by apeace | Hacker News Reader

Parent Full thread

The funny part is, I thought that if I did a bunch of real transactions and then reversed them all, that our account might get flagged!

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!

> charging a real card, and if it works, reversing it

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.

We are an internet service provider and we charge a monthly fee for our service. So the real thing I would've been doing was reversing the first month's charge and then cancelling the recurring subscription. Which is exactly what I'd recommend you do if you are launching a new subscription service on Stripe!

Just make a hidden $1 subscription and cancel it without reversing it, then deactivate the item.

I still got caught when I did that once. $1 worked just fine. The first real customer $249 charge failed. :-(

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.

Why not just claim the expense on your card as business expense, and pay yourself back?

Another good reason to do a Live charge even for subscriptions (add a coupon code to make it like $1 if you really need to) but is to test the credit card expiring after the fact. I've done a lot of billing code an none of the sandboxes really let you test a card that works for N months, and then expires.

> Why would you reverse it?

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

And this is exactly what I told a friend of my to do when he installed a public car charger. Before he told anyone it was live, charge his car using his normal customer account. Turned out he couldn't create one because his phone was already in as a supplier.

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!".

There are countless of virtual phone apps which allows calling and SMS for a few bucks a month. That’s what I’m doing to create “test” accounts on our stripe prod environment for something I’m building.

Yes. When interfacing with a complex system, especially one you don't control, always do at least one live test.

> reversing it

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.

Reply on news.ycombinator.com