Payments Training Hub
Test case PAYMENT OPERATIONS STARTED LIVE 01 Test case - structured instruction that tells the tester ACTIVE 02 Happy path test case - simplest. QUEUED 03 Reject path test case - checks what happens when a payment fails QUEUED 04 Return path test case - checks what happens when the beneficiary QUEUED 05 Recall path test case - checks the cancellation flow. QUEUED A test case is a structured instruction that tells the tester exactly what to do and what result to expect, and it has a fixed format. Step 1 of 5 Test case STARTED Test case structured instruction that tells the tester ACTIVE Happy path test case simplest. QUEUED Reject path test case checks what happens when a payment fails QUEUED Return path test case checks what happens when the beneficiary QUEUED Recall path test case checks the cancellation flow. QUEUED A test case is a structured instruction that tells the tester exactly what to do and what result to expect, and it has a fixed format.
Happy path test case PAYMENT OPERATIONS IN PROGRESS LIVE 01 Test case - structured instruction that tells the tester DONE 02 Happy path test case - simplest. ACTIVE 03 Reject path test case - checks what happens when a payment fails QUEUED 04 Return path test case - checks what happens when the beneficiary QUEUED 05 Recall path test case - checks the cancellation flow. QUEUED The happy path test case is the simplest. Step 2 of 5 Happy path test case IN PROGRESS Test case structured instruction that tells the tester DONE Happy path test case simplest. ACTIVE Reject path test case checks what happens when a payment fails QUEUED Return path test case checks what happens when the beneficiary QUEUED Recall path test case checks the cancellation flow. QUEUED The happy path test case is the simplest.
Reject path test case PAYMENT OPERATIONS IN PROGRESS LIVE 01 Test case - structured instruction that tells the tester DONE 02 Happy path test case - simplest. DONE 03 Reject path test case - checks what happens when a payment fails ACTIVE 04 Return path test case - checks what happens when the beneficiary QUEUED 05 Recall path test case - checks the cancellation flow. QUEUED The reject path test case checks what happens when a payment fails validation. Step 3 of 5 Reject path test case IN PROGRESS Test case structured instruction that tells the tester DONE Happy path test case simplest. DONE Reject path test case checks what happens when a payment fails ACTIVE Return path test case checks what happens when the beneficiary QUEUED Recall path test case checks the cancellation flow. QUEUED The reject path test case checks what happens when a payment fails validation.
Return path test case PAYMENT OPERATIONS IN PROGRESS LIVE 01 Test case - structured instruction that tells the tester DONE 02 Happy path test case - simplest. DONE 03 Reject path test case - checks what happens when a payment fails DONE 04 Return path test case - checks what happens when the beneficiary ACTIVE 05 Recall path test case - checks the cancellation flow. QUEUED The return path test case checks what happens when the beneficiary bank cannot apply the payment. Step 4 of 5 Return path test case IN PROGRESS Test case structured instruction that tells the tester DONE Happy path test case simplest. DONE Reject path test case checks what happens when a payment fails DONE Return path test case checks what happens when the beneficiary ACTIVE Recall path test case checks the cancellation flow. QUEUED The return path test case checks what happens when the beneficiary bank cannot apply the payment.
Recall path test case PAYMENT OPERATIONS COMPLETE LIVE 01 Test case - structured instruction that tells the tester DONE 02 Happy path test case - simplest. DONE 03 Reject path test case - checks what happens when a payment fails DONE 04 Return path test case - checks what happens when the beneficiary DONE 05 Recall path test case - checks the cancellation flow. ACTIVE The recall path test case checks the cancellation flow. Step 5 of 5 Recall path test case COMPLETE Test case structured instruction that tells the tester DONE Happy path test case simplest. DONE Reject path test case checks what happens when a payment fails DONE Return path test case checks what happens when the beneficiary DONE Recall path test case checks the cancellation flow. ACTIVE The recall path test case checks the cancellation flow.

Key points of this lesson, in order.

0:00 / 3:24 Step 1 of 5

UAT Scenarios and End-to-End Test Cases

Capstone Project, Lesson 5 of 7, Narration 3:24, D14 Business analysis and professional practice

ReconciliationPurpose codeValue date

What you will learn

Your objective. By the end of this lesson, you will be able to explain UAT scenarios and end-to-end test cases. A test case is a structured instruction that tells the tester exactly what to do and what result to expect, and it has a fixed format.

Why it matters. This matters because this is the work a payments BA, PO or SME actually produces: requirements, mappings, stories, test cases and traceability. It is the job, not the theory.

Chapter objective: Learner completes a capstone project that designs an end-to-end payment solution for a stated business problem, integrating messages, rails, controls, and operations into one coherent proposal. Learner demonstrates this skill using realistic banking examples, explaining each step clearly and using correct terminology throughout.

Key learning points

  • Test case
  • Happy path test case
  • Reject path test case
  • Return path test case
  • Recall path test case

Key terms

Reconciliation: The process of comparing records from two sources, such as a bank statement and an internal ledger, to confirm they agree.

Purpose code: A code that states the commercial reason for a payment, such as supplier payment, salary or goods. Purpose codes are taken from an ISO external code list and support regulatory reporting, screening...

Value date: The date on which funds become available to the beneficiary and on which interest starts to accrue. It is the date used for settlement and for nostro posting.

Clearing and settlement timeline showing UAT Scenarios and End-to-End Test Cases.

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.

  1. 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 UAT scenarios and end-to-end test cases?

Takeaway and next step

What to remember

The tester also checks the negative path, where the beneficiary bank rejects the recall because the funds have already been released, and the status changes to Recall Rejected with the reason displayed.

Map the message fields from this lesson in the mapping workbench.

Open the Mapping Workbench →

Builds on "User Stories and Acceptance Criteria for the Migration".

Transcript and full text

Show transcript

A test case is a structured instruction that tells the tester exactly what to do and what result to expect, and it has a fixed format. A test case identifier, a title, a precondition, a set of steps, the expected result for each step, and the actual result recorded during execution. A test case for the migration might be titled Convert MT103 with valid data to pacs.008, with the precondition that the test environment holds a valid MT103 message, and steps that walk the tester through submission, conversion and verification. The tester marks each step as pass or fail, and a test case only passes when every step passes. The happy path test case is the simplest. A valid payment flows through without any exception. The tester submits an MT103 for 125,000 US dollars from a corporate account in Mumbai to a supplier in Frankfurt, with a valid IBAN, a purpose code of P0101, and a value date of 15 November 2024. The expected result is that the pacs.008 is generated within five seconds, that the debtor and creditor details match the MT103 exactly, that the instructed amount is 125,000 dollars, and that the payment status changes to Released. The tester also checks the reconciliation report to confirm the payment appears with the status Converted. The reject path test case checks what happens when a payment fails validation. The tester submits an MT103 with an invalid beneficiary IBAN, where one character has been deliberately changed so the modulus 97 check fails. The expected result is that the message is not converted, that it appears in the repair queue within one minute with the error code INVALID_IBAN, that no pacs.008 is generated, and that no debit is posted to the customer account. The tester then corrects the IBAN in the repair screen and resubmits, and the expected result is that the conversion completes and the payment is released. The return path test case checks what happens when the beneficiary bank cannot apply the payment. The tester releases a pacs.008 for 75,000 euros to a beneficiary in Paris, and then simulates a pacs.004 return message from the beneficiary bank with the reason code AC01, meaning the account number is incorrect. The expected result is that the original payment status changes to Returned, that the 75,000 euros is credited back to the debtor account, that a notification is sent to the customer, and that the reconciliation report shows the original payment and the return linked by the same end-to-end identification. The recall path test case checks the cancellation flow. The tester releases a pacs.008 for 50,000 US dollars, and then the customer asks the bank to recall the payment because the supplier details were wrong. The tester raises a camt.056 recall request, and the expected result is that the recall is sent to the beneficiary bank, that the payment status changes to Recall Requested, and that when the beneficiary bank accepts the recall, a pacs.004 return is received and the 50,000 dollars is credited back. The tester also checks the negative path, where the beneficiary bank rejects the recall because the funds have already been released, and the status changes to Recall Rejected with the reason displayed.

A test case is a structured instruction that tells the tester exactly what to do and what result to expect, and it has a fixed format. A test case identifier, a title, a precondition, a set of steps, the expected result for each step, and the actual result recorded during execution. A test case for the migration might be titled Convert MT103 with valid data to pacs.008, with the precondition that the test environment holds a valid MT103 message, and steps that walk the tester through submission, conversion and verification. The tester marks each step as pass or fail, and a test case only passes when every step passes.

The happy path test case is the simplest. A valid payment flows through without any exception. The tester submits an MT103 for 125,000 US dollars from a corporate account in Mumbai to a supplier in Frankfurt, with a valid IBAN, a purpose code of P0101, and a value date of 15 November 2024. The expected result is that the pacs.008 is generated within five seconds, that the debtor and creditor details match the MT103 exactly, that the instructed amount is 125,000 dollars, and that the payment status changes to Released. The tester also checks the reconciliation report to confirm the payment appears with the status Converted.

The reject path test case checks what happens when a payment fails validation. The tester submits an MT103 with an invalid beneficiary IBAN, where one character has been deliberately changed so the modulus 97 check fails. The expected result is that the message is not converted, that it appears in the repair queue within one minute with the error code INVALID_IBAN, that no pacs.008 is generated, and that no debit is posted to the customer account. The tester then corrects the IBAN in the repair screen and resubmits, and the expected result is that the conversion completes and the payment is released.

The return path test case checks what happens when the beneficiary bank cannot apply the payment. The tester releases a pacs.008 for 75,000 euros to a beneficiary in Paris, and then simulates a pacs.004 return message from the beneficiary bank with the reason code AC01, meaning the account number is incorrect. The expected result is that the original payment status changes to Returned, that the 75,000 euros is credited back to the debtor account, that a notification is sent to the customer, and that the reconciliation report shows the original payment and the return linked by the same end-to-end identification.

The recall path test case checks the cancellation flow. The tester releases a pacs.008 for 50,000 US dollars, and then the customer asks the bank to recall the payment because the supplier details were wrong. The tester raises a camt.056 recall request, and the expected result is that the recall is sent to the beneficiary bank, that the payment status changes to Recall Requested, and that when the beneficiary bank accepts the recall, a pacs.004 return is received and the 50,000 dollars is credited back. The tester also checks the negative path, where the beneficiary bank rejects the recall because the funds have already been released, and the status changes to Recall Rejected with the reason displayed.

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.