So i’ve had a couple of questions recently from colleagues and peers in our community about testing payment functionality specifically post deployment to live…
In my context, we make a few real booking/payments with our own or team credit cards, then request a refund through the internal processes.
Are there any more efficient ways to do this kind of testing without having to use personal cards?
My suggestion is to use a business credit card. The company handles all the payments and there is less paperwork for the testers.
On mobile google pay and apple pay have a test-card system, so no money actually even moves, but that assumes you are using those pay-platforms. It’s as close as dammit to the real thing. (This dialogs look almost identical to the real appstore ones, but just differ slightly.)
You can also hard-code a specific card from each provider into the system to follow a “dont-bill” routing through your app to dummy things out. You might limit this hard-coded set of cards to not be present in production, but generally it’s never going to be an issue even if someone does guess the dummy card details since you need defences for abuse anyway.
But, in leu, very little beats walking through the flow and then going over to the friendly folk on your support desk and asking for a reversal. It’s a good chance to talk anyway (once-off, since this has a cost to the business).
Yes, you can set up a discount coupon (if your system can) and you won’t have to go through the refunding process at the end if you give yourself 100% off for life! 
It also gives you the chance to test the coupon codes at the same time. 
Yeah, does sounds a little cow boy. I’d be worried about it causing tax/fraud investigations. I’d be surprised if you ever needed to use real money for something like this.
Are you just integrating with a 3rd party vendor like world pay? They have a list of test cards Test Card Numbers
@crunchy Test card numbers only work in staging/post deployment. You’ll get an error from any billing vendor if you use it on a live site.
Fair enough, shows what I now about this domain. Sorry I should have read the page before Google spamming you! I see PayPal have a similar system, I guess only other option would be to switch over to the test API for production testing and back dynamically. Might introduce more problems that in prevents though.
I’d talk to your finance department, see if a company credit card can be set up. Like others have suggested. At least then it’s they know exactly how much funds is going round and round and why. And it’s not at your own expense or risk.
I switch the staging server to production mode and have a plan set up for $1, so I can run a few tests without racking up costs. You shouldn’t really need to do this often once a payment system is configured, most of the testing should be performed with test card numbers.
Depending on what kind of payment systems you have … We used a company card and just asked for a refund. If you can pay with VISA, you can just cancel the order afterwards and just not pay. Which helped a lot 
I think the crux of much of this is that you need to be 100% sure your payments can be taken at any time. I’m reminded for a horrible pointless book called The Black Swan by Massem Nicholas Taleb, the book is arguably junk, but the point made is not. Testing it is not complicated, but if a customer cannot pay you, they won’t.
If your payment provider won’t give you a test card, you want to reach out to all the folk above who have managed to get ones in place.
It’s good to test with all majors card types and cards from the main countries you trade with. For instance, we don’t accept payments from the UAE as their tax laws have changed so you actually need an accountant in the UAE to process the payment. Most billing vendors have a list of dummy cards and cards that should give you certain error/acceptance messages for testing.
Ultimately, live testing with real cards is a must for the most important part of your app.
We used fake sample credit cards for the lower environments, and since these did not work in production there we used the company’s credit card, it was a Mastercard. I wish we had other cards for testing in production as well, like Visa, Visa Electron, American Express, etc. But sometimes it’s hard to convince the company bigshots of doing that.
I straight up hate working in environments which make you use your own “stuff” to do necessary work, be that credit cards, phones, email addresses, laptops etc. Unless you signed up to work on that basis, perhaps as a contractor with your own equipment, it feels like a real imposition. I resented even having to install 2FA on my phone for work and resisted it for some time before giving in to how much easier it made my day.
Fundamentally I feel no employer has the right to financially disadvantage me, to take up space on my devices (or whatever) without my absolute consent, and that realistically they should be paying me for any disadvantage they are causing me - interest on payments taken for example. And I mention all this because I know I’m not alone in feeling this way (others I work with have expressed similar sentiments about previous impositions) and I think it’s a situation which should be handled with some urgency and care.
Rant over!
The last time I worked in an environment where we tested payments, we had a test card to use. I was told this was supplied by the payment vendor. It absolutely worked on live although it did trigger a “fake” authentication somehow, which meant no money was taken and the transaction was somehow flagged in a way we could pick up - sorry for the absence of details, I was very junior at the time! This was ~6 years ago and things may well have changed since then, but it seems strange any payment org wouldn’t make their service testable? Either way, my first action would be to speak with the vendor and find out if they do have a test programme/system of some kind.
If not, next action would be to get the company to issue a card for test transactions. This hasn’t happened already which suggests some hesitation in doing so… presumably you are already providing a lot of hardware, software, office costs etc. I can’t see that a credit card is really much more of a financial burden and it is a necessary tool for doing the job the company needs you(/r testers) to do.
A warning about using personalised credit cards: if a tester uses a standard business credit card in extreme numbers, then he or she might end up on a blacklist. This could lead to a complete block on all personal banking accounts of this tester.
My advise is to contact the credit card company how to facilitate high number of credit cards transactions for testing purposes without any financial consequences for the people or companies involved.
This is also my preferred method in testing payment methods. It is as real as it gets to be honest! The real transaction is also only just another software operation, it should be seamless, if the setting and everything is as close to production as possible, or even performing on a live platform!
Then it is upto the Business to take the risks, if they cannot get it resolve. Test Engineers should not be the one to take this risk at a personal level to perform business requirements. It is unethical and unfair to the employee for such asking! Refuse!
Completely agree with you and all true!