Payments Academy
Payment gateway PAYMENT OPERATIONS STARTED LIVE 01 Payment gateway - service that accepts payment instructions ACTIVE 02 Aggregator versus gateway - goes further than a gateway QUEUED 03 Third-party services supply specialist functions - bank cannot build efficiently QUEUED 04 Pre-launch load test - bank must test the service under load before QUEUED 05 Provider - environment is a risk QUEUED 06 Untested plan - has never been tested is only a document QUEUED A payment gateway is a service that accepts payment instructions from a bank or a merchant and forwards them to the correct scheme. Step 1 of 6 Payment gateway STARTED Payment gateway service that accepts payment instructions ACTIVE Aggregator versus gateway goes further than a gateway QUEUED Third-party services supply specialist bank cannot build efficiently QUEUED Pre-launch load test bank must test the service under load before QUEUED Provider environment is a risk QUEUED Untested plan has never been tested is only a document QUEUED A payment gateway is a service that accepts payment instructions from a bank or a merchant and forwards them to the correct scheme.
Aggregator versus gateway PAYMENT OPERATIONS IN PROGRESS LIVE 01 Payment gateway - service that accepts payment instructions DONE 02 Aggregator versus gateway - goes further than a gateway ACTIVE 03 Third-party services supply specialist functions - bank cannot build efficiently QUEUED 04 Pre-launch load test - bank must test the service under load before QUEUED 05 Provider - environment is a risk QUEUED 06 Untested plan - has never been tested is only a document QUEUED An aggregator goes further than a gateway, because it holds the scheme membership and the settlement relationship on behalf of smaller participants. Step 2 of 6 Aggregator versus gateway IN PROGRESS Payment gateway service that accepts payment instructions DONE Aggregator versus gateway goes further than a gateway ACTIVE Third-party services supply specialist bank cannot build efficiently QUEUED Pre-launch load test bank must test the service under load before QUEUED Provider environment is a risk QUEUED Untested plan has never been tested is only a document QUEUED An aggregator goes further than a gateway, because it holds the scheme membership and the settlement relationship on behalf of smaller participants.
Third-party services supply specialist functions PAYMENT OPERATIONS IN PROGRESS LIVE 01 Payment gateway - service that accepts payment instructions DONE 02 Aggregator versus gateway - goes further than a gateway DONE 03 Third-party services supply specialist functions - bank cannot build efficiently ACTIVE 04 Pre-launch load test - bank must test the service under load before QUEUED 05 Provider - environment is a risk QUEUED 06 Untested plan - has never been tested is only a document QUEUED Third-party services supply specialist functions that a bank cannot build efficiently, such as sanctions screening, fraud detection, foreign exchange pricing, and address validation. Step 3 of 6 Third-party services supply specialist functions IN PROGRESS Payment gateway service that accepts payment instructions DONE Aggregator versus gateway goes further than a gateway DONE Third-party services supply specialist bank cannot build efficiently ACTIVE Pre-launch load test bank must test the service under load before QUEUED Provider environment is a risk QUEUED Untested plan has never been tested is only a document QUEUED Third-party services supply specialist functions that a bank cannot build efficiently, such as sanctions screening, fraud detection, foreign exchange pricing, and address validation.
Pre-launch load test PAYMENT OPERATIONS IN PROGRESS LIVE 01 Payment gateway - service that accepts payment instructions DONE 02 Aggregator versus gateway - goes further than a gateway DONE 03 Third-party services supply specialist functions - bank cannot build efficiently DONE 04 Pre-launch load test - bank must test the service under load before ACTIVE 05 Provider - environment is a risk QUEUED 06 Untested plan - has never been tested is only a document QUEUED The bank must test the service under load before launch, because a slow provider becomes the slowest step in the whole payment. Step 4 of 6 Pre-launch load test IN PROGRESS Payment gateway service that accepts payment instructions DONE Aggregator versus gateway goes further than a gateway DONE Third-party services supply specialist bank cannot build efficiently DONE Pre-launch load test bank must test the service under load before ACTIVE Provider environment is a risk QUEUED Untested plan has never been tested is only a document QUEUED The bank must test the service under load before launch, because a slow provider becomes the slowest step in the whole payment.
Provider that offers no test PAYMENT OPERATIONS IN PROGRESS LIVE 01 Payment gateway - service that accepts payment instructions DONE 02 Aggregator versus gateway - goes further than a gateway DONE 03 Third-party services supply specialist functions - bank cannot build efficiently DONE 04 Pre-launch load test - bank must test the service under load before DONE 05 Provider - environment is a risk ACTIVE 06 Untested plan - has never been tested is only a document QUEUED A provider that offers no test environment is a risk, because the bank cannot verify a new version without risking live payments. Step 5 of 6 Provider that offers no test IN PROGRESS Payment gateway service that accepts payment instructions DONE Aggregator versus gateway goes further than a gateway DONE Third-party services supply specialist bank cannot build efficiently DONE Pre-launch load test bank must test the service under load before DONE Provider environment is a risk ACTIVE Untested plan has never been tested is only a document QUEUED A provider that offers no test environment is a risk, because the bank cannot verify a new version without risking live payments.
An untested plan is only a document PAYMENT OPERATIONS COMPLETE LIVE 01 Payment gateway - service that accepts payment instructions DONE 02 Aggregator versus gateway - goes further than a gateway DONE 03 Third-party services supply specialist functions - bank cannot build efficiently DONE 04 Pre-launch load test - bank must test the service under load before DONE 05 Provider - environment is a risk DONE 06 Untested plan - has never been tested is only a document ACTIVE A plan that has never been tested is only a document, and the first real failure is the worst time to discover that it does not work. Step 6 of 6 An untested plan is only a document COMPLETE Payment gateway service that accepts payment instructions DONE Aggregator versus gateway goes further than a gateway DONE Third-party services supply specialist bank cannot build efficiently DONE Pre-launch load test bank must test the service under load before DONE Provider environment is a risk DONE Untested plan has never been tested is only a document ACTIVE A plan that has never been tested is only a document, and the first real failure is the worst time to discover that it does not work.

Key points of this lesson, in order.

0:00 / 3:14 Step 1 of 6

Gateway, Aggregator and Third-Party Service Integration

Banking Integration Patterns, Lesson 4 of 9, Narration 3:14, D10 APIs and integration

Sanctions screeningAggregatorSettlement

What you will learn

Your objective. By the end of this lesson, you will be able to explain gateway, aggregator and third-party service integration. A payment gateway is a service that accepts payment instructions from a bank or a merchant and forwards them to the correct scheme.

Why it matters. The bank must test the service under load before launch, because a slow provider becomes the slowest step in the whole payment.

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

  • Payment gateway
  • Aggregator versus gateway
  • Third-party services supply specialist functions
  • Pre-launch load test
  • Provider that offers no test
  • An untested plan is only a document

Key terms

Sanctions screening: Checking payment parties, countries and references against sanctions lists published by governments and international bodies.

Aggregator: A payment provider that lets many small merchants accept card payments under the aggregator master merchant account, without each merchant holding its own acquirer contract.

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.

Banking architecture diagram showing Gateway, Aggregator and Third-Party Service Integration.

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

Map the payment in this lesson through the hub components.

Use the hub components and their order in this lesson.

  1. What to do. List each component the payment passes through, what it does, and what happens if it fails.

Correct result. The payment enters through a channel, passes the gateway, validation, fraud and sanctions checks, routing, and the ledger, then leaves through the right clearing system. A failure at any component stops or holds the payment, and the hub must record where it stopped.

Why. The hub is where most payment requirements live. If you cannot map a payment through it, you cannot specify, test or fix it.

Check your understanding

Practice question

A bank is integrating a new payment channel. The channel sends payment instructions in a format the hub does not understand. What should the BA define first?

Takeaway and next step

What to remember

A plan that has never been tested is only a document, and the first real failure is the worst time to discover that it does not work.

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 "Ledger, General Ledger and Accounting Integration".

Transcript and full text

Show transcript

A payment gateway is a service that accepts payment instructions from a bank or a merchant and forwards them to the correct scheme. A corporate customer might send a file of 10,000 salary payments to the bank gateway, which validates the file, converts it to the scheme format, and delivers it onward. A merchant might send card and instant payment requests through the same gateway. The gateway hides the complexity of many schemes behind a single interface, which simplifies the bank internal systems. The bank still owns the customer relationship and the regulatory responsibility, even though the gateway performs the technical routing. An aggregator goes further than a gateway, because it holds the scheme membership and the settlement relationship on behalf of smaller participants. A small bank or a fintech company might connect to an aggregator rather than joining a scheme directly, because direct membership requires capital, certification, and a settlement account. The aggregator sends the payments under its own membership and settles with the participant separately. A fintech sending USD 200,000 a day through an aggregator depends entirely on that aggregator for its service, so the contract must define limits, settlement timing, and the procedure if the aggregator fails or the relationship ends. Third-party services supply specialist functions that a bank cannot build efficiently, such as sanctions screening, fraud detection, foreign exchange pricing, and address validation. A screening provider might check 50,000 payments a day against lists that change hourly, and return a result in under 200 milliseconds. A foreign exchange provider might quote a rate for a EUR to USD conversion that is valid for thirty seconds. These services are usually consumed through an application programming interface, with a contract that defines the request format, the response format, the timeout, and the error codes. The bank must test the service under load before launch, because a slow provider becomes the slowest step in the whole payment. Service levels and penalties make the dependency explicit, and they must be negotiated before the service goes live. A gateway contract might promise 99.95 percent availability and a response time under one second for ninety-five percent of requests. If the provider misses the target, the contract might require a service credit or a root cause report within five business days. The bank should also demand a test environment that mirrors production, so that changes can be tested before they reach customers. A provider that offers no test environment is a risk, because the bank cannot verify a new version without risking live payments. Failover planning is essential, because a third-party failure can stop a bank payment service completely. The bank should know what happens if the gateway is unavailable for ten minutes, for one hour, or for a full day. The plan might include a secondary provider, a direct scheme connection held in reserve, or a manual process for urgent payments above a threshold, such as GBP 50,000. The failover must be tested at least twice a year, with a realistic scenario and a measured recovery time. A plan that has never been tested is only a document, and the first real failure is the worst time to discover that it does not work.

A payment gateway is a service that accepts payment instructions from a bank or a merchant and forwards them to the correct scheme. A corporate customer might send a file of 10,000 salary payments to the bank gateway, which validates the file, converts it to the scheme format, and delivers it onward. A merchant might send card and instant payment requests through the same gateway. The gateway hides the complexity of many schemes behind a single interface, which simplifies the bank internal systems. The bank still owns the customer relationship and the regulatory responsibility, even though the gateway performs the technical routing.

An aggregator goes further than a gateway, because it holds the scheme membership and the settlement relationship on behalf of smaller participants. A small bank or a fintech company might connect to an aggregator rather than joining a scheme directly, because direct membership requires capital, certification, and a settlement account. The aggregator sends the payments under its own membership and settles with the participant separately. A fintech sending USD 200,000 a day through an aggregator depends entirely on that aggregator for its service, so the contract must define limits, settlement timing, and the procedure if the aggregator fails or the relationship ends.

Third-party services supply specialist functions that a bank cannot build efficiently, such as sanctions screening, fraud detection, foreign exchange pricing, and address validation. A screening provider might check 50,000 payments a day against lists that change hourly, and return a result in under 200 milliseconds. A foreign exchange provider might quote a rate for a EUR to USD conversion that is valid for thirty seconds. These services are usually consumed through an application programming interface, with a contract that defines the request format, the response format, the timeout, and the error codes. The bank must test the service under load before launch, because a slow provider becomes the slowest step in the whole payment.

Service levels and penalties make the dependency explicit, and they must be negotiated before the service goes live. A gateway contract might promise 99.95 percent availability and a response time under one second for ninety-five percent of requests. If the provider misses the target, the contract might require a service credit or a root cause report within five business days. The bank should also demand a test environment that mirrors production, so that changes can be tested before they reach customers. A provider that offers no test environment is a risk, because the bank cannot verify a new version without risking live payments.

Failover planning is essential, because a third-party failure can stop a bank payment service completely. The bank should know what happens if the gateway is unavailable for ten minutes, for one hour, or for a full day. The plan might include a secondary provider, a direct scheme connection held in reserve, or a manual process for urgent payments above a threshold, such as GBP 50,000. The failover must be tested at least twice a year, with a realistic scenario and a measured recovery time. A plan that has never been tested is only a document, and the first real failure is the worst time to discover that it does not work.

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.