How to effectively test a new payment gateway integration?
Every online commerce system uses a payment integration/payment gateway; some even use multiple.
Be it a new discounted tax value proposition, ease of use or simply on user’s demand, these integrations are a necessary evil and in order to integrate and test them well is sometimes a nightmare.
These are usually P0 test cases since direct revenue is involved and a QA engineer needs to be well suited up in order to test such systems.
There are a lot of Payment gateway/integration players; Chargebee, Stripe, 2checkout/Avangate, Fast Spring, PayPal, Braintree, PayU, Amazon Payments, WePay, Authorize.net to name a few.
With my experience so far, I am trying to curate some common areas & hence a checklist of the bare minimum use cases/test cases which one could use blindfolded and can be confident of the test coverage of payment integration under test.
[✔] New purchase[✔] Multiple new purchases one after the other of different values[✔] Cancellation of the purchase[✔] Refund[✔] Fresh purchase made by old/existing users on the new platform/integration[✔] Migration of the old users(application specific) to a new platform when a fresh purchase is made, be it organic or inorganic(say a contract based), e.g. continual of existing plans to new payment system[✔] Existing subscription renewals using new APIs(when old payment integration is replaced) i.e. this involves the migration of old subscriptions to new.[✔] Existing subscription renewals on the old payment method[✔] Taxes: Different country different taxes and these should be kept well in mind both by the product as well as the test team.[✔] Geographic relevance and accessibility of the new payment provider[✔] Timeouts and cycle time of payment made vs account/feature/product activated[✔] The old returning user who now wants to purchase a new product(ideally this is new purchase only)[✔] Renewal frequency: Monthly, yearly, custom[✔] Percentage discounts in terms of big gigantic deals[ ] Referral systems/schemes aka affiliates[✔] Extensions in case of SaaS[ ] Future contracts and backdated contract sales.[ ] Card update from the application in case of SaaS-based services and its interface + Old card should be discontinued from the system when recurrence occurs[✔] Every such scenario has related **EMAILS** and they need to be tested as well[✔] Invoices[ ] Compliance related testing like some countries asks for OTP while payment and some do not.[ ] Payment integration provider basics: Dashboard, linking of invoices, customer information[ ] Security of the payment URLs[✔] Character Length of the payment URLs[✔] Support of payment in mobile mode(this highly depends on the payment gateway)[✔] Grandfathering
Next step is to automate some happy paths to the very least which will help you avoid any regressions introduced into the system at a later stage.
