Payments Academy
Onboarding starts with a discovery PAYMENT OPERATIONS STARTED LIVE 01 Onboarding - workshop, where the bank and the partner ACTIVE 02 Certification - integration works QUEUED 03 Test environments - certification proves nothing. QUEUED 04 Management - Change management keeps every partner QUEUED 05 Emergency - changes are allowed QUEUED 06 Team - first few hours QUEUED Onboarding starts with a discovery workshop, where the bank and the partner agree on the business need, the volumes, and the technical approach. Step 1 of 6 Onboarding starts with a discovery STARTED Onboarding workshop, where the bank and the partner ACTIVE Certification integration works QUEUED Test environments certification proves nothing. QUEUED Management Change management keeps every partner QUEUED Emergency changes are allowed QUEUED Team first few hours QUEUED Onboarding starts with a discovery workshop, where the bank and the partner agree on the business need, the volumes, and the technical approach.
Certification: formal proof PAYMENT OPERATIONS IN PROGRESS LIVE 01 Onboarding - workshop, where the bank and the partner DONE 02 Certification - integration works ACTIVE 03 Test environments - certification proves nothing. QUEUED 04 Management - Change management keeps every partner QUEUED 05 Emergency - changes are allowed QUEUED 06 Team - first few hours QUEUED Certification is the formal proof that the integration works, and it is usually required by schemes and by large partners. Step 2 of 6 Certification: formal proof IN PROGRESS Onboarding workshop, where the bank and the partner DONE Certification integration works ACTIVE Test environments certification proves nothing. QUEUED Management Change management keeps every partner QUEUED Emergency changes are allowed QUEUED Team first few hours QUEUED Certification is the formal proof that the integration works, and it is usually required by schemes and by large partners.
Test environments must mirror production closely PAYMENT OPERATIONS IN PROGRESS LIVE 01 Onboarding - workshop, where the bank and the partner DONE 02 Certification - integration works DONE 03 Test environments - certification proves nothing. ACTIVE 04 Management - Change management keeps every partner QUEUED 05 Emergency - changes are allowed QUEUED 06 Team - first few hours QUEUED Test environments must mirror production closely, or certification proves nothing. Step 3 of 6 Test environments must mirror production closely IN PROGRESS Onboarding workshop, where the bank and the partner DONE Certification integration works DONE Test environments certification proves nothing. ACTIVE Management Change management keeps every partner QUEUED Emergency changes are allowed QUEUED Team first few hours QUEUED Test environments must mirror production closely, or certification proves nothing.
Management keeps every partner informed PAYMENT OPERATIONS IN PROGRESS LIVE 01 Onboarding - workshop, where the bank and the partner DONE 02 Certification - integration works DONE 03 Test environments - certification proves nothing. DONE 04 Management - Change management keeps every partner ACTIVE 05 Emergency - changes are allowed QUEUED 06 Team - first few hours QUEUED Change management keeps every partner informed when something changes, because a change on one side can break the other side without warning. Step 4 of 6 Management keeps every partner informed IN PROGRESS Onboarding workshop, where the bank and the partner DONE Certification integration works DONE Test environments certification proves nothing. DONE Management Change management keeps every partner ACTIVE Emergency changes are allowed QUEUED Team first few hours QUEUED Change management keeps every partner informed when something changes, because a change on one side can break the other side without warning.
Emergency: allowed PAYMENT OPERATIONS IN PROGRESS LIVE 01 Onboarding - workshop, where the bank and the partner DONE 02 Certification - integration works DONE 03 Test environments - certification proves nothing. DONE 04 Management - Change management keeps every partner DONE 05 Emergency - changes are allowed ACTIVE 06 Team - first few hours QUEUED Emergency changes are allowed, but they need a named approver and a rollback plan, because an untested emergency fix can cause more damage than the problem it solves. Step 5 of 6 Emergency: allowed IN PROGRESS Onboarding workshop, where the bank and the partner DONE Certification integration works DONE Test environments certification proves nothing. DONE Management Change management keeps every partner DONE Emergency changes are allowed ACTIVE Team first few hours QUEUED Emergency changes are allowed, but they need a named approver and a rollback plan, because an untested emergency fix can cause more damage than the problem it solves.
Team monitors the service closely PAYMENT OPERATIONS COMPLETE LIVE 01 Onboarding - workshop, where the bank and the partner DONE 02 Certification - integration works DONE 03 Test environments - certification proves nothing. DONE 04 Management - Change management keeps every partner DONE 05 Emergency - changes are allowed DONE 06 Team - first few hours ACTIVE The team monitors the service closely for the first few hours, and the rollback decision is made by a named incident manager, not by a committee. Step 6 of 6 Team monitors the service closely COMPLETE Onboarding workshop, where the bank and the partner DONE Certification integration works DONE Test environments certification proves nothing. DONE Management Change management keeps every partner DONE Emergency changes are allowed DONE Team first few hours ACTIVE The team monitors the service closely for the first few hours, and the rollback decision is made by a named incident manager, not by a committee.

Key points of this lesson, in order.

0:00 / 3:08 Step 1 of 6

Partner Onboarding, Certification and Change Management

Banking Integration Patterns, Lesson 6 of 9, Narration 3:08, D10 APIs and integration

SettlementSchemeReturn

What you will learn

Your objective. By the end of this lesson, you will be able to explain partner onboarding, certification and change management. Onboarding starts with a discovery workshop, where the bank and the partner agree on the business need, the volumes, and the technical approach.

Why it matters. The bank must pass every case and provide evidence, such as message logs and screenshots, before it is allowed into production.

Chapter objective: Learner explains banking integration patterns, including file transfer, messaging, APIs, and event streaming, and selects the right pattern for a given payment integration need. Learner demonstrates this skill using realistic banking examples, explaining each step clearly and using correct terminology throughout.

Key learning points

  • Onboarding starts with a discovery
  • Certification: formal proof
  • Test environments must mirror production closely
  • Management keeps every partner informed
  • Emergency: allowed
  • Team monitors the service closely

Key terms

Settlement: The final movement of funds between banks to discharge obligations created by cleared payments. Settlement is usually made in central bank money or through correspondent accounts.

Scheme: A card or payment network that sets the rules, standards and fees for transactions between issuers and acquirers.

Return: A payment that is sent back to the sender after settlement because it cannot be credited to the beneficiary.

Banking architecture diagram showing Partner Onboarding, Certification and Change Management.

Practise this lesson

Exercise

Write the request and the expected response for the API call described in this lesson.

Use the API resources, operations and fields named in this lesson.

  1. What to do. Write the JSON request with the required fields, the success response, and one error response with its error code.

Correct result. A correct request has all mandatory fields, a valid idempotency key, and the right resource and operation. The success response confirms acceptance, and the error response names the field or rule that failed.

Why. An API contract is a promise between two systems. If the request is wrong, the API must reject it cleanly, not fail silently.

Check your understanding

Practice question

Which of the following best describes partner onboarding, certification and change management?

Takeaway and next step

What to remember

A business analyst should plan for at least two rounds of testing and should never promise a go-live date before the first round is complete.

Call the API described in this lesson with a valid request, then with a missing field, and compare the responses.

Open the API Playground →

Builds on "APIs, Messaging Queues, Files and Event Streaming".

Transcript and full text

Show transcript

Onboarding starts with a discovery workshop, where the bank and the partner agree on the business need, the volumes, and the technical approach. A bank onboarding a new corporate customer that will send 30,000 payments a month needs to know the file format, the cutoff times, the settlement account, and the support contacts. The workshop produces a short onboarding document that names the systems, the interfaces, the test plan, and the go-live date. Skipping this step is a common mistake, because the two sides discover their misunderstandings only during testing, when fixing them is expensive and the date is already fixed. Certification is the formal proof that the integration works, and it is usually required by schemes and by large partners. The partner provides a test environment and a set of test cases, such as a valid payment of USD 1,000, a payment with an invalid account, a payment above the limit, and a duplicate payment. The bank must pass every case and provide evidence, such as message logs and screenshots, before it is allowed into production. Certification can take several weeks, because each failure requires a fix and a retest. A business analyst should plan for at least two rounds of testing and should never promise a go-live date before the first round is complete. Test environments must mirror production closely, or certification proves nothing. The test core banking system should behave like the live one, the test scheme simulator should return realistic responses, and the test data should include edge cases such as leap years, public holidays, and foreign characters in names. A bank that tests only with clean data will be surprised by the first real payment with a special character in the beneficiary name. Test data must also be refreshed regularly, because a stale environment hides the changes that have been made to production since the last refresh. Change management keeps every partner informed when something changes, because a change on one side can break the other side without warning. If a bank changes the format of its payment file, every corporate customer that sends that file must be told, given a test window, and given a date for the change. If a scheme changes its message version from one release to another, every participant must upgrade by a deadline. A change calendar lists all planned changes, their owners, and their impact, and a change advisory board reviews the high-risk ones. Emergency changes are allowed, but they need a named approver and a rollback plan, because an untested emergency fix can cause more damage than the problem it solves. Go-live is a controlled event, not a single moment, and it needs a runbook that everyone can follow. The runbook lists the deployment steps, the verification checks, the rollback trigger, and the contact numbers for every team involved. The first live payments are usually limited in volume and value, such as ten payments of GBP 100, so that any problem affects a small number of customers. The team monitors the service closely for the first few hours, and the rollback decision is made by a named incident manager, not by a committee. A successful go-live is often quiet, because the preparation was thorough, and the team celebrates the lack of drama rather than the heroics of a recovery.

Onboarding starts with a discovery workshop, where the bank and the partner agree on the business need, the volumes, and the technical approach. A bank onboarding a new corporate customer that will send 30,000 payments a month needs to know the file format, the cutoff times, the settlement account, and the support contacts. The workshop produces a short onboarding document that names the systems, the interfaces, the test plan, and the go-live date. Skipping this step is a common mistake, because the two sides discover their misunderstandings only during testing, when fixing them is expensive and the date is already fixed.

Certification is the formal proof that the integration works, and it is usually required by schemes and by large partners. The partner provides a test environment and a set of test cases, such as a valid payment of USD 1,000, a payment with an invalid account, a payment above the limit, and a duplicate payment. The bank must pass every case and provide evidence, such as message logs and screenshots, before it is allowed into production. Certification can take several weeks, because each failure requires a fix and a retest. A business analyst should plan for at least two rounds of testing and should never promise a go-live date before the first round is complete.

Test environments must mirror production closely, or certification proves nothing. The test core banking system should behave like the live one, the test scheme simulator should return realistic responses, and the test data should include edge cases such as leap years, public holidays, and foreign characters in names. A bank that tests only with clean data will be surprised by the first real payment with a special character in the beneficiary name. Test data must also be refreshed regularly, because a stale environment hides the changes that have been made to production since the last refresh.

Change management keeps every partner informed when something changes, because a change on one side can break the other side without warning. If a bank changes the format of its payment file, every corporate customer that sends that file must be told, given a test window, and given a date for the change. If a scheme changes its message version from one release to another, every participant must upgrade by a deadline. A change calendar lists all planned changes, their owners, and their impact, and a change advisory board reviews the high-risk ones. Emergency changes are allowed, but they need a named approver and a rollback plan, because an untested emergency fix can cause more damage than the problem it solves.

Go-live is a controlled event, not a single moment, and it needs a runbook that everyone can follow. The runbook lists the deployment steps, the verification checks, the rollback trigger, and the contact numbers for every team involved. The first live payments are usually limited in volume and value, such as ten payments of GBP 100, so that any problem affects a small number of customers. The team monitors the service closely for the first few hours, and the rollback decision is made by a named incident manager, not by a committee. A successful go-live is often quiet, because the preparation was thorough, and the team celebrates the lack of drama rather than the heroics of a recovery.

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.