Hacker News Reader

Comment by forgetfreeman | Hacker News Reader

I've coded a few payment gateways over the years and spent several weekends neck deep in a few more. I don't remember all of the fine technical details of why payment handlers freak out over this kind of activity. What I do recall is spikes in small charges are a hallmark of a card dump being tested. Anyway this isn't the correct way to test a payment gateway. As stated elsewhere there's a mode flag and test card # that's used to confirm your code is working. Put another way, don't test in prod.

View on HN

> Put another way, don't test in prod.

There's a difference between "testing in prod", and "testing prod". The former is bad but the latter does seem to me like common sense.

If there's a distinction there I sure as hell don't see it. Either you satisfy the conditions (testing, prod) or you don't. Don't test in prod. If that seems questionable for any reason that's a clear indication your dev and/or testing environments are lacking and you know it.

You’ve legitimately never tested something you built in production, after having already tested it in staging and local? You’ve just, had complete faith in staging production environment parity your entire career on every project and it has never failed you?

I’m sorry man but I don’t believe you at all.

Yeah same, I've built a few integrations with payment gateways. I make extensive use of the test environment, for sure. But when it's gone live I've always done a single test purchase with a real card, just to be sure, and checked that the transaction appeared in the appropriate dashboards and reports from the payment processor.

You don't believe that people write payment software? You don't believe that people deploy payment software? This is a firm requirement. You risk losing your PCI certification, your payment processor certification, or if a customer your payment processor account.

“Penny testing” is common in the real world, and isn’t limited to verifying bank accounts. It’s more broadly used to describe testing with very small amounts in production. That’s my experience anyway, working with various payments processors and BaaSes.

All I know is when I was writing systems used by franchises/gas stations there was zero tolerance. Maybe BassSes are so bad at moving things to production they had to loosen that up.

That seems reasonable. I’m talking about testing APIs for performing a variety of different kinds of transactions, not just CC.

Oh I did all kinds of dumb shit over the course of a 20 year career, make no mistake, and testing in prod is the least of my sins. That doesn't make it any less stupid, and in the case of testing payment gateways pointless. If you're in test mode you're going to rub up against the same endpoint you would in live. Either the card info you package and send validates or it doesn't. Using a test card doesn't alter your level of control over the situation in any way, it all goes down on your payment processor's servers. All testing card processing with a live card in prod is going to buy you is bullshit transaction data in your live datastore, and maybe a little less anxiety if it's your first time. OP is having a panic attack over card processor TOS though, so they're jammed either way.

To me, "testing in prod" means you had some code you needed to test, and you tested it in prod instead of a more suitable environment.

"Testing prod" means checking to see if prod works.

I mean, to take "don't test prod" to it's logical extreme—how do you know if your website is up at all? What if the domain expired?

It’s not your testing environment, it’s the payment processor’s, and you don’t really know what it may or may not be lacking.

Reply on news.ycombinator.com