Making a live-mode test payment to yourself = a payment processor ToS violation?

> this is really pretty vital to what ALL of us do as part of our product development/launching/testing process

The whole point of test-mode is that you can run your transaction as if it was running on the live-mode network. The solution is to test in test mode. Live mode just runs real cards, it should be have identically to test mode.

The reason why this is a per-se violation is because you're playing on the real network with real cards, and that means the real anti-fraud systems are active, and the card networks are taking real interchange fees for doing their jobs. If you're already processing a ton of money per day, you probably can fly under the radar with 1-2 non-refunded test transactions that you reimburse yourself for later. But why risk it? If you're breaking the ToS you're risking account termination.

> The Stripe Services Agreement prohibits testing in live mode using real payment method details.

If Stripe or whomever else is your gateway to accepting all payments, why would you poke the bear? Section 6.2 of the Stripe Services Agreement:

> Stripe may immediately suspend providing any or all Services to you, and your access to the Stripe Technology, if:

> (e) you breach this Agreement or any other agreement between the parties;

It's just not worth the risk.

But why do they care? You're paying the transaction fees. They're getting their money. If anything isn't it good for the payment processor to get more transactions?

It's a real transaction. Nobody was deceived, the money really changed hands, and the payment processor got their fee.

If I own a physical shop I'm allowed to buy stuff from it if I want, why isn't that also the case for an online store?

I'm not saying it isn't against the ToS, but I agree with OP it isn't obvious why it should be and it seems like almost everybody would test at least one real transaction at some point.

I think the issue is that one possible scam is to sign up for a stripe account, run a bunch of charges from cards you control, then when the funds from Stripe hit your bank account, you run a bunch of chargebacks. So this policy that allows them to ban accounts that have even a whiff of this going on.

It's self dealing in the context of taxes.

I'm not saying "yeah let's rebel and keep doing it!" or anything like that; now that I'm aware of this I'll be ultra-careful going forward.

My point is -- it seems absurd that people WOULD get their account banned for a couple of trivial test payments. And since this practice seems so widespread in the software developer / entrepreneur community, I think these doomsday soothsayers telling us that your account WILL get banned if you do this are clearly overstating how serious this is and how aggressively it's policed and cracked down on by PPs like Stripe.

> But why risk it?

Because production is not staging or test and never will be. At the very least, you’re risking that your production configuration is incorrect and you won’t find out until customers test in production for you. More commonly, as we experienced with Authorize.net, the test environment is subtly different from production and the only documentation for the differences are 6 year old posts in migrated support forum threads.

Just have someone run a charge on their personal card and reimburse them.

> But why risk it?

Because testing environments often still mock some parts of the system and there may be subtle differences between mocked systems and live systems.

When I worked at a company that send out SMS to cell phones, we first tested our system without any connection to the network with our simulated SMS service provider. When we tried to go live, we tested a few live SMS on actual phones we controlled. It turned out, that there were some subtle differences between our mock SMS service and the real service, so we had to stop deployment and first fix the issues.

That was after months of testing in the test environment without any sign of the bug before we tried to go live.

"it should behave identically"

Come on man. Please don't tell me you engineer things based on "should".

"should" means nothing. The only way test something is to test it, not test something else that "should behave identically".

Maybe payments are a special case where you have to do it wrong for some overriding reason, but the general premis to test for real was 100% correct.

> The whole point of test-mode is that you can run your transaction as if it was running on the live-mode network. The solution is to test in test mode. Live mode just runs real cards, it should be have identically to test mode.

This is unreasonable. Test environment is never the same as prod. It's irresponsible to anyone you're actually accepting money from not to try the E2E flow in production.

Even if card processing is identical, who is say everything else in your flow is? It's either going to be you or a stranger on the internet being the first to try it for real.

I have had production differences show up that were not present or even reproducible in test mode on a major e-commerce platform payment system.

> But why risk it?

I once worked on a system that, when it updated a database row, wrote the software version into a last-modified-by column.

Version 1.23-PRODUCTION worked fine.

Version 1.23.1-SIT worked fine too, in the integration test environment.

Version 1.23.1-PRODUCTION exceeded the column length limit, so it couldn't update any rows. It was completely broken.

If your site has loads of traffic you can just YOLO things from SIT into production and rely on alerting and complaints to catch such issues. But if it's absolutely critical, like a big high profile product launch? I wouldn't want to rely on luck.

If you need to test in production, have a family relative or friend buy the product/subscription and then make them whole offline. Also, do not reverse or refund the transaction.

Been doing it like this since at least 2000. Never been a problem.

In trading, it's illegal to do a test trade in production on most regulated exchanges. Making a trade with no intrinsic economic motivation is considered market manipulation and will be punished by the regulator.

It's also illegal not to do such a test trade. Operating a trading system that hasn't been validated under production conditions is reckless behaviour that will be punished by a different arm of the same regulator.

Payments processing seems to be in a similar situation. It's bad practice to test in production, but it's even worse practice not to test in production.

> Is this not practically speaking just the common-sense norm before launching your live product? Did everyone else know this and I'm just a moron?

I can’t help you because I’m not familiar with this area. But I just wanted to say that what you’re describing seems very much like common sense to me, and it would seem crazy to me that someone would be placed on an industry wide blacklist for it.

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

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.

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.

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

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.

Used to do it all the time at a subscription company. Amex complained once since it was their corporate card but that was it. Something about generating fake revenue but it was a few hundred dollars and we were doing $10m in rev at the time.

I think it depends on your processor, stripe uses their own merchant account(PSP) so they are probably stricter. If you had your own merchant account, you can get away with lots of stuff be the processor complains.

In SaaS/Software specifically? No. But we did get banned from a gateway in 2013 for doing this and had to switch to an entirely new gateway. We had similar reasoning - we wanted the processing to work seamlessly with our new clients, so we tested it to make sure it worked properly.

It didn't prevent us from signing up with the new gateway though, so I wouldn't be worried about going on any lists if you do get kicked off Stripe.

If you’re really worried about, just get your mom to buy something.

What you’re describing is probably being detected and flagged as fraud or money laundering by software. If they didn’t have protection in place this would be abused. You can use test credit cards.

They have obligations to shareholders to not allow fraud because that is their entire business on the line. I would assume their end of the integration is more like electricity and always on/working and if there are issues I’d be looking at my code first.

As long as the amounts are small, and from a variety of cards, no normal (real) card processor is going to notice/care. Cannot speak for Stripe.

A solution is a sum of its parts, yours, the infrastructure, all of it.

Live testing is the only testing that matters to your customers and bottom line.

We all need to figure out how to do it under the TOS, 100% legit.

In this case: ask Stripe.

i think the idea is if you code your app using TEST_MODE you can make all the test charges you want with 4111 1111 1111 1111 card. Then when you are ready go live switching to LIVE_MODE with no code changes is guaranteed to work the same but with real cards.

Having extensive experience running billions of dollars through Stripe, this is not accurate. Production is always different, except for the simplest cases.

I work in this space and can tell you it’s fairly common to test on real cards. Stripe knows this and they don’t care as long as it’s very infrequent tests.

But there is no reason to test a dozen times with a real card. Stripe is the gold standard of a test environment that exactly matches the real world. On top of a test environment they also have test clocks so you can run tests over time.

There is only one test in my opinion that warrants using a real card. The very first time you go live. When you’re first swapping the test keys to a live environment. There isn’t a good way to be 100% sure your system is working correctly without a real card test. The front end has a “test” badge, but there is no 100% way to verify the webhook and webhook secret are configurable properly without some sort of a test.

You only have to do this the first time. I often see devs want to use real cards to test updating a webhook secret, but you can usually replay a previous webhook to ensure your changes are working as expected.

For your specific situation I wouldn’t do any more real tests, but I wouldn’t panic about your previous tests. The odds of them taking action against you are extremely low.