Payments Academy

LAB-06: Write a UAT Plan for a Payment Hub Go-Live

Testing

A payment hub go-live is a moment when a testing gap becomes a customer problem within minutes, so the user acceptance test must be thorough, realistic and well organised. In this lab you write the UAT plan for a payment hub go-live, covering system integration testing, user acceptance testing, reconciliation and production validation. You will design happy path, negative, boundary, integration and regression scenarios, plan the defect triage process, and define the entry and exit criteria that decide whether the hub is ready. You will also prepare the reconciliation checks that prove every payment reached the right ledger. By the end of the lab you will have a test plan that the business can sign off with confidence and the test team can execute without improvisation.

0 of 5 steps done. Tick each step as you finish it, your progress is saved in this browser.

  1. Define the scope of the UAT: which payment types, channels, currencies and rails are in scope, and which are out. Agree the test environment, the test data, and the entry criteria, such as all system integration tests passed and all severity one defects fixed. Agree the exit criteria, such as 95 percent of test cases passed, no open severity one or two defects, and the reconciliation report balanced for three consecutive days. Get the business, operations and technology leads to sign the plan before testing starts.

  2. Design the happy path scenarios first, such as a 15,000 euro payment from a corporate to a supplier that settles and reports correctly. Then design the negative scenarios, such as an invalid IBAN, insufficient funds and a sanction screening hit. Add the boundary scenarios, such as a payment exactly at the daily limit and one euro above it. Write each scenario with its precondition, its steps, its input data and its expected result, so that any tester can run it without asking for help.

  3. Design the integration scenarios that cross system boundaries: the payment hub to the core banking system, the hub to the screening system, the hub to the clearing system, and the hub to the ledger. Include a timeout case where screening does not respond, and a retry case where clearing rejects the first attempt. Design a regression pack of 20 scenarios to rerun after every fix, so that a change in one area does not break another. Review the pack with the developers to confirm every scenario is testable.

  4. Write the reconciliation test pack, stating the expected ledger entry for every payment type, including the amount, the currency, the value date and the charges. Include the cases that must not appear in the ledger, such as rejected payments and duplicate submissions that were blocked. Run the pack against the test data and record the match rate, the break count and the time taken to resolve each break. Agree the tolerance for fee differences with finance, and record any break that exceeds it as a defect.

  5. Define the defect severity levels: severity one blocks the go-live, severity two has a workaround, severity three is cosmetic. Set the triage meeting at the same time every day, with the business analyst, the test lead and the development lead agreeing severity, owner and fix date for each new defect. Write the production validation checklist for go-live day: five small live payments, a check that each one settles, a reconciliation check, and a rollback trigger if any check fails. Get business sign off before the go-live is declared.

Templates.

Worked example. Ashford Bank, a fictional bank in Dublin, is preparing the user acceptance test for a new payment hub go-live. The test team writes 42 scenarios, including a happy path payment of 15,000 euros from a Dublin corporate to a supplier in Paris, a negative case where the beneficiary IBAN fails the checksum, a boundary case at the 100,000 euro limit, and an integration case where the screening system returns a possible match. During UAT the team finds a defect: a payment submitted twice within two seconds creates two payments because the duplicate check uses the customer reference, which the channel reuses. The defect is logged as severity one, the development team adds an idempotency key check, and the scenario is retested and passes. The reconciliation test pack checks that every payment in the test run appears in the ledger with the correct amount and value date, and that the two rejected payments do not appear at all. On go-live day the team runs a production validation checklist with five live payments of 100 euros each, confirms that all five settle and reconcile, and declares the hub live.

Deliverables.