Key points of this lesson, in order.
Test strategy for payments: SIT, UAT, negative testing and the test pack
What you will learn
Your objective. By the end of this lesson, you will be able to explain test strategy for payments: SIT, UAT, negative testing and the test pack and apply it to a real banking scenario.
Why it matters. For a business analyst, the test strategy is a document with test levels, test scenarios, test data, entry and exit criteria, and the regression pack.
Chapter objective: Gherkin, traceability, SIT and UAT design, negative testing, defect management, root cause analysis
Key learning points
- Test strategy for payments
- Complete test pack contents
- Negative test
- Test data documentation
- Regression testing in payments
- Test strategy acceptance criteria
Key terms
Reconciliation: The process of comparing records from two sources, such as a bank statement and an internal ledger, to confirm they agree.
Payment hub: A central system in a bank that receives payment instructions from all channels, validates them, applies screening and routing rules, and sends them to the correct clearing system or correspondent.
Idempotency: The property that repeating the same request has the same effect as sending it once. In payments, an idempotency key lets a client safely retry a request after a timeout without creating a duplicate...
Payment flow diagram showing Test strategy for payments: SIT, UAT, negative testing and the test pack.
Insights and practice scenarios
Worked insights and practice scenarios for this lesson. Each one is a reusable PaymentForge case, so the same case may appear in more than one lesson.
Practise this lesson
Exercise
Handle the exception described in this lesson the way the lesson prescribes.
Use the exception type, the reason code and the recovery path in this lesson.
- What to do. State what happened, what the correct action is, what must not be done, and what the post-incident review should capture.
Correct result. The correct action is the one the lesson prescribes for this exception type, with the right reason code and the right message. The payment must not be resent without checking whether it already settled, because that creates a duplicate.
Why. An exception handled wrongly is worse than the exception itself. A duplicate payment is a loss, and an unlearned exception will happen again.
Check your understanding
Practice question
Which of the following best describes test strategy for payments: SIT, UAT, negative testing and the test pack?
Takeaway and next step
What to remember
For a business analyst, the test strategy is a document with test levels, test scenarios, test data, entry and exit criteria, and the regression pack.
Follow a payment through every stage, from instruction to beneficiary credit, and note where it can stop.
Open the Payment Lifecycle Simulator →
Builds on "Data mapping and message mapping: field by field, MT to MX".
Transcript and full text
Show transcript
A test strategy for payments starts with the test levels, and each level has a different purpose. Unit testing proves a single component works, such as the IBAN validation function. System integration testing, SIT, proves the components work together, such as the channel, the payment hub, and the screening engine. User acceptance testing, UAT, proves the product meets the business need, such as a corporate treasurer sending a bulk payment file and receiving the correct status for each payment. Each level needs its own test cases, its own test data, and its own entry and exit criteria. Test scenarios in payments must cover the full lifecycle, not just the happy path. A complete test pack includes a payment that succeeds, a payment that is rejected for an invalid IBAN, a payment that is blocked by screening, a payment that is returned, a payment that is recalled, a payment that is duplicated, a payment that exceeds the limit, a payment that arrives after the cut-off, and a payment with a missing mandatory field. Each scenario needs an input, an expected output, and a pass criterion. A test pack that covers only the happy path will pass in testing and fail in production. Negative testing is the most valuable testing in payments, because the defects that cause the most harm are the ones where the system does the wrong thing, not where it does nothing. A negative test sends a payment with an invalid IBAN and expects a rejection with reason code AC01. It sends a payment to a sanctioned beneficiary and expects a block. It sends the same payment twice with the same idempotency key and expects one payment, not two. It sends a payment with an amount of zero and expects a rejection. Each negative test proves the system defends itself, and each one that is missing is a defect waiting to happen. Test data in payments is a discipline. The test environment needs test IBANs that pass and fail the MOD 97 check, test BICs that are valid and invalid, test customer names that trigger sanctions hits and names that do not, test card numbers that are approved and declined, and test amounts that are within and outside the limits. The test data must be documented, with each item labelled by what it triggers, and the test data must be refreshed regularly, because a test that uses stale data will pass when it should fail. UAT in payments is done by the business, not by the testers. The corporate treasurer tests the bulk payment file, the operations analyst tests the exception handling, and the compliance officer tests the screening and the reporting. UAT has entry criteria, which state that SIT has passed and the defects are below the threshold, and exit criteria, which state that all critical test cases have passed and no critical defects remain open. UAT is not a formality: if the business finds a defect in UAT, the release is delayed, and the delay is cheaper than a defect in production. Regression testing in payments is a continuing obligation. Every release must re-run the regression pack, which is the set of test cases that prove the existing functionality still works. The regression pack must include the happy path, the exceptions, the message formats, and the reconciliation, because a change to one area can break another. The regression pack must be automated where possible, because a manual regression pack takes days and will be skipped under pressure. The acceptance criteria for a release must include the regression results. For a business analyst, the test strategy is a document with test levels, test scenarios, test data, entry and exit criteria, and the regression pack. The acceptance criteria must include a test where the test pack is executed end to end and the results are reviewed by the business, with no critical defects open. Last reviewed 7 November 2026. Further reading: the International Software Testing Qualifications Board syllabus; the EPC SEPA test packs; the SWIFT testing guides; Gojko Adzic, Specification by Example.
A test strategy for payments starts with the test levels, and each level has a different purpose. Unit testing proves a single component works, such as the IBAN validation function. System integration testing, SIT, proves the components work together, such as the channel, the payment hub, and the screening engine. User acceptance testing, UAT, proves the product meets the business need, such as a corporate treasurer sending a bulk payment file and receiving the correct status for each payment. Each level needs its own test cases, its own test data, and its own entry and exit criteria.
Test scenarios in payments must cover the full lifecycle, not just the happy path. A complete test pack includes a payment that succeeds, a payment that is rejected for an invalid IBAN, a payment that is blocked by screening, a payment that is returned, a payment that is recalled, a payment that is duplicated, a payment that exceeds the limit, a payment that arrives after the cut-off, and a payment with a missing mandatory field. Each scenario needs an input, an expected output, and a pass criterion. A test pack that covers only the happy path will pass in testing and fail in production.
Negative testing is the most valuable testing in payments, because the defects that cause the most harm are the ones where the system does the wrong thing, not where it does nothing. A negative test sends a payment with an invalid IBAN and expects a rejection with reason code AC01. It sends a payment to a sanctioned beneficiary and expects a block. It sends the same payment twice with the same idempotency key and expects one payment, not two. It sends a payment with an amount of zero and expects a rejection. Each negative test proves the system defends itself, and each one that is missing is a defect waiting to happen.
Test data in payments is a discipline. The test environment needs test IBANs that pass and fail the MOD 97 check, test BICs that are valid and invalid, test customer names that trigger sanctions hits and names that do not, test card numbers that are approved and declined, and test amounts that are within and outside the limits. The test data must be documented, with each item labelled by what it triggers, and the test data must be refreshed regularly, because a test that uses stale data will pass when it should fail.
UAT in payments is done by the business, not by the testers. The corporate treasurer tests the bulk payment file, the operations analyst tests the exception handling, and the compliance officer tests the screening and the reporting. UAT has entry criteria, which state that SIT has passed and the defects are below the threshold, and exit criteria, which state that all critical test cases have passed and no critical defects remain open. UAT is not a formality: if the business finds a defect in UAT, the release is delayed, and the delay is cheaper than a defect in production.
Regression testing in payments is a continuing obligation. Every release must re-run the regression pack, which is the set of test cases that prove the existing functionality still works. The regression pack must include the happy path, the exceptions, the message formats, and the reconciliation, because a change to one area can break another. The regression pack must be automated where possible, because a manual regression pack takes days and will be skipped under pressure. The acceptance criteria for a release must include the regression results.
For a business analyst, the test strategy is a document with test levels, test scenarios, test data, entry and exit criteria, and the regression pack. The acceptance criteria must include a test where the test pack is executed end to end and the results are reviewed by the business, with no critical defects open. Last reviewed 7 November 2026. Further reading: the International Software Testing Qualifications Board syllabus; the EPC SEPA test packs; the SWIFT testing guides; Gojko Adzic, Specification by Example.
Full lesson text (all scenes)
Completing a lesson updates your progress dashboard on the homepage.
Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.