Apparently, after reading more into it, if you make a payment to yourself, or to a business where your name is associated with it, this is a violation of the Stripe (and other payment processor) ToS, and you can get your account banned AND even potentially put on a MATCH list that effectively blacklists you from using ANY payment processor in the future. Well over the last several months I've made about a dozen such payments just to test things out and make sure everything was working correctly. Now I'm worried that I'm boned.
If you search the subject online you can find several posts on Reddit where people (mainly the same few people) detail the ominous "hammer-of-doom" consequences that can and likely will result from making a few live-mode test payments like this.
How big of a deal is this really? 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? Can anyone in the software developer / SaaS community point to one real-world example of someone they know who had their payment provider account banned for doing this, let alone outright blacklisted and put on a MATCH list, because of a handful of small test payments? I couldn't find any clear examples online, making me think, the severity of this infraction may be overblown.
I'm curious to see where the SaaS / software entrepreneur community is on this issue, since this is really pretty vital to what ALL of us do as part of our product development/launching/testing process. It's got me THOROUGHLY stressed out. Thanks.
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.
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.
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.
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.
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.
Deleted Comment
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.