What are the best Payment Systems testing strategies for legacy systems?

Understand the legacy payment system's architecture, business rules, supplier balances/open items, payments-in-transit, un-reconciled payments, and bank account balances. Identify the data to be migrated and set up the cutover plans and opening balances. Ensure data integrity is maintained during the payment processing lifecycle. Use dummy data in dev/test systems and production data in secure env, ensure GDPR guidelines are followed. Perform reconciliation between legacy and new system. Performance testing-Identify bottlenecks, scalability issues, and performance issues. Perform end-2-end testing to validate the entire payment processing workflow in the new system, from initiating transactions to settlement and reconciliation.

Think of testing your old-school payment system like caring for a vintage car. First, get to know its quirks and what makes it tick. Regularly check under the hood with targeted tests, especially where it matters most, like security and transaction speed. Listen to users; they're like passengers noticing every bump on the road. Use modern tools for these old gears, ensuring they mesh well. When updating, do it piece by piece to avoid a system breakdown. Test drive it with end-to-end checks to see everything’s running smoothly. And always have a backup plan, like roadside assistance, ready for any hiccups. It’s all about keeping your classic ride cruising smoothly in a high-speed world.

Verify compliance with industry regulations, standards, and best practices governing payment systems, such as PCI DSS Payment Card Industry Data Security Standard, GDPR General Data Protection Regulation, and PSD2 Revised Payment Services Directive.

Validate failover and disaster recovery mechanisms to ensure business continuity and data integrity in the event of system failures or disruptions.

Much testing should be done to validate the security of the systems. For this, we leveraged the tools and techniques used by our PCI Auditors, as that is their business. Intrusion testing and other security validations need to be done periodically to accommodate the PCI Service Provider and Merchant standards. We used the same tools so when the annual audit came (as a PCI Service Provider Level 1), the evidence we had monitored over the year was usable by them also.

Over my 30 years of card processing software development, and 8 years of operating a SaaS Portal that processes many Billions of dollars a year, we worked very hard to test the live production environment. While this was more complicated that attempting to replicate it, we knew that the results were valid. The actual testing of the UI and APIs could be started in simulation, but needed to be done in the live system. We employed specific merchant identities, specific transaction types, and test card numbers that would be guaranteed to not be sent to the banks for authorization. This allowed us to test in the live environment, just as we encouraged our customers to do.