You are told very strongly that you are not to do this, way before you get to a point where you are even close to touching live. So it is not common sense at all.

Maybe not industry wide but you could just be banned from say Chase/Paymentech (long time away from payment stuff not sure names now) or whatever processor. But guess what, some vendors only support one processor, or a preferred one has WAY better fee structures so you don't want to be kicked off.

And sometimes when you are a franchise you have to use the franchise approved POS/payment vendor (when you buy say a gas station payment system it doesn't support every payment processor just the subset of those approved for it by the payment system company AND approved by the franchising company/brand for example Exxon).

Also some people own a lot of businesses under an LLC/Corp so getting blacklisted from a payment processor and having 40 sites unable to accept cards could be painful.

So not a good idea to risk it.

Finally the Federal government PROVIDES industry wide financial blacklists. Processors aren't getting in any trouble for collusion for unbanking people/businesses. The left wants to unbank all weapons dealers and right wants to unbank all porn distributors and everyone wants to unbank supporters of warcrimes, drugdealers, etc.

> I’m also surprised to hear of this industry wide blacklist. That type of collusion feels like it could easily be abused.

MATCH/Terminated Merchant File are well documented to those who pay attention. Visa, MasterCard, and AmEx are happy to rip the payment rails away from businesses who carry undue risk or are perceived to be dangerous. There's an entire list of Prohibited Businesses that Stripe maintains, which more or less echoes what their dependent card networks also have problems with: https://stripe.com/legal/restricted-businesses#prohibited-bu...

The truth of the matter is that this system is not fair, and if you want to use it, you're playing by the payment processor's rules.

Absolutely makes sense to have something like that, for genuine scammers, mass offenders, etc. But being but on that list for a few measly test payments to make sure your software is working properly? That to me sounds LUDICROUS.

You'll be fine. BUT be sure to keep your live card out of a testing environment, because that's a PCI violation.

When I worked on PCI certified software it was a 'you will be fired' thing. If you are just implementing something for a single customer and they have a processor account for a single site, I wouldn't do it but I guess you could. But if they have say 40 sites using this payment processor, and you could bring down all 40 sites so that they can't make any sales?

Edit: Do you really think banks' compliance departments are going to care about your argument? 'I was only doing this thing your documentation says not to do a few times'? 'I only knowing made the first transactions across your gateway in intentional violation of your requirements but I was going to stop violating them later'? Do you want to put your job/work on the line for that?

In banking not only can this be common, sometimes it can be legally mandated. For example I can definitely see this rule being in place to prevent money laundering.

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.

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

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.

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.

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.