3 Best Practices to Conduct In-Market Payment Testing
How do you ensure that payments process in every local market that they need to?
It’s a simple question, but the answer can get awfully complex. There is a seemingly endless number of payment methods that consumers use, and that list gets longer all the time as consumers leverage new alternative payment methods (APMs). This payment fragmentation is here to stay.
APMs range from mobile wallets and contactless payments, to unique local methods. For example, Boleto is an evolving payment method in Brazil, and Korea Cyber Payment (KCP) is quickly becoming one of the most popular payment options in South Korea. If you have consumers in those countries, you must ensure transactions process smoothly on those payment methods.
As a senior manager on the Testing Services team here at Applause, I work with many of our customers on payment testing to ensure they get the testing coverage they need. It’s about building a plan to test transactions in-market with real users across all the relevant payment methods and identifying the root cause of issues.
To be confident in your end-to-end payment experience, Applause’s in-market testers help customers answer these key questions.
In October, I participated in a webinar with Jeremy Waxman, the Head of Global Payments Strategy at Digital River, a leading e-commerce provider that helps brands grow globally through its back-office services, including payments, fraud, mitigation, taxes and compliance. We discussed several emerging APMs and the factors you must consider to test for them.
Here are three best practices for payment testing, including localized payment methods around the world.
1. Account for in-market specifics (VAT, regulations, security)
The testing plan needs to account for specific in-market areas that are difficult to test from an office. Here at Applause, clients come to us when they notice some payments won’t process in certain countries, or when there are unexpected issues with taxes or security.
Payment testing includes building a plan to test transactions in-market with real users across all the relevant payment methods and identifying the root cause of issues.
“That's where Applause comes into play,” Waxman said. “When they go through a payment test — and this is really important for folks to know — testers don't just go through the process and say, ‘Yep, I'm done,’ and we get a result. There are screenshots, there are videos, there can be interaction with my team to help understand and get further information of the pain points, whether it’s with taxes or something else.
“It's not just ‘throw it over the fence.’ There is actually evidence, details, interactions. This is inherently key, because not everything everybody ever launches is going to work 100% correctly.”
2. Don’t just test the ‘happy path’
Testing the happy path, or the expected flow of users throughout a digital experience, is a good first step for a testing plan. But any testing plan should also leave room for testers to go down an alternative path and engage as a real user would. That means testing for unexpected scenarios.
As an example, Applause was testing the desktop web flow for a payment method in India that launched various windows. The desktop flow was part of the happy path, because that’s where the organization anticipated users would leverage the payment method. Our teams tested the desktop happy path, and everything went well there. But in India, when we went outside the happy path, we discovered that the mobile web experience on Android devices created buttons that were completely cut off and unclickable.
Any testing plan should also leave room for testers to go down an alternative path and engage as a real user would.
“To talk about the happy path and the edge case, there are situations where payment providers may not have all of the scenarios built out, and you don't know what's expected when it comes back,” Waxman said. “And these are where testers can help understand where your gaps may be, either in pre-production or production. Something like, ‘How is the payment method refund flow happening? Or chargeback flow? Or cancellation flow?’ These are all things that you can't do necessarily in a sandbox environment with canned data.”
3. Test with real cards in the real world
A common question we get from new clients is: Why do I need to test with more than one Visa card in a country? They’ll say, "If Visa is accepted, Visa should work." In theory, it should work, but reality can be very different.
As an example, we did testing in Brazil for one of our clients that was having an unexplained issue with cart abandonment. Our testers began looking at different types of cards, and found the issue was with debit cards specifically, not with credit cards.
As we dug deeper, we realized what was happening. On debit cards, the BINs were getting routed, and the ability to recognize debit cards had been turned off in the API. Once the client had this information, they quickly resolved the issue, and their cart abandonment rate went down. They got that result because of testing real cards in the real world.
“If you have one card, that doesn't tell the story,” Waxman said. “There are a lot of factors that come into play when an issuer — the end bank that has issued that card — makes a decision on whether to approve or decline that transaction. So if you're going to look at very few cards, you may not be able to get the whole story.”
Watch the full presentation with Jeremy Waxman, Digital River’s Head of Global Payments Strategy, learn more about Applause’s payment testing solution.
