Payments Training Hub
Payment hub processes thousands of payments 1 Payment hub processes thousands of payments NOW 2 Kafka organises events into topics 3 Consumer 4 Kafka delivers events at least once 5 Idempotency 6 A payment hub processes thousands of payments a minute, and every important change is an event. Step 1 of 6 Payment hub processes thousands of payments 1 NOW Payment hub processes thousands of payments 2 Kafka organises events into topics 3 Consumer 4 Kafka delivers events at least once 5 Idempotency 6 A payment hub processes thousands of payments a minute, and every important change is an event. Step 1 of 6
Kafka organises events into topics 1 Payment hub processes thousands of payments 2 Kafka organises events into topics NOW 3 Consumer 4 Kafka delivers events at least once 5 Idempotency 6 Kafka organises events into topics, and each topic is split into partitions. Step 2 of 6 Kafka organises events into topics 1 Payment hub processes thousands of payments 2 NOW Kafka organises events into topics 3 Consumer 4 Kafka delivers events at least once 5 Idempotency 6 Kafka organises events into topics, and each topic is split into partitions. Step 2 of 6
Consumer reads events 1 Payment hub processes thousands of payments 2 Kafka organises events into topics 3 Consumer NOW 4 Kafka delivers events at least once 5 Idempotency 6 A consumer reads events from a topic and keeps track of its position, called an offset. Step 3 of 6 Consumer reads events 1 Payment hub processes thousands of payments 2 Kafka organises events into topics 3 NOW Consumer 4 Kafka delivers events at least once 5 Idempotency 6 A consumer reads events from a topic and keeps track of its position, called an offset. Step 3 of 6
Kafka delivers events at least once 1 Payment hub processes thousands of payments 2 Kafka organises events into topics 3 Consumer 4 Kafka delivers events at least once NOW 5 Idempotency 6 Kafka delivers events at least once, not exactly once, which means a consumer can receive the same event twice. Step 4 of 6 Kafka delivers events at least once 1 Payment hub processes thousands of payments 2 Kafka organises events into topics 3 Consumer 4 NOW Kafka delivers events at least once 5 Idempotency 6 Kafka delivers events at least once, not exactly once, which means a consumer can receive the same event twice. Step 4 of 6
Idempotency is not optional 1 Payment hub processes thousands of payments 2 Kafka organises events into topics 3 Consumer 4 Kafka delivers events at least once 5 Idempotency NOW 6 Idempotency is not optional in an event-driven design; it is the safety net that makes at-least-once delivery safe. Step 5 of 6 Idempotency is not optional 1 Payment hub processes thousands of payments 2 Kafka organises events into topics 3 Consumer 4 Kafka delivers events at least once 5 NOW Idempotency 6 Idempotency is not optional in an event-driven design; it is the safety net that makes at-least-once delivery safe. Step 5 of 6
1 Payment hub processes thousands of payments 2 Kafka organises events into topics 3 Consumer 4 Kafka delivers events at least once 5 Idempotency 6 NOW And the BA must define the dead letter queue, which is where events go when they cannot be processed, so that a bad event does not block the whole topic. Step 6 of 6 1 Payment hub processes thousands of payments 2 Kafka organises events into topics 3 Consumer 4 Kafka delivers events at least once 5 Idempotency 6 NOW And the BA must define the dead letter queue, which is where events go when they cannot be processed, so that a bad event does not block the whole topic. Step 6 of 6

Flow of the explanation in this lesson.

0:00 / 3:22 Step 1 of 6

Event-driven payments and Kafka: topics, partitions, ordering and replay

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

Event-drivenPayment hubIdempotency

What you will learn

Your objective. By the end of this lesson, you will be able to explain event-driven payments and KAFKA: topics, partitions, ordering and replay. A payment hub processes thousands of payments a minute, and every important change is an event.

Why it matters. For a business analyst, event-driven design changes how requirements are written.

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

  • Events: every change is published
  • Topics and partitions: ordering per payment
  • Consumers, offsets and replay
  • At-least-once delivery: duplicates are possible
  • Idempotency: the safety net for replay
  • Dead letter queue: where bad events go

Key terms

Event-driven: An architecture where systems react to events, such as a payment received or a status changed, rather than polling for updates.

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...

Banking architecture diagram showing Event-driven payments and Kafka: topics, partitions, ordering and replay.

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

Two banks connect their payment systems with mutual TLS (mTLS). What does mTLS prove that one-way TLS does not?

Takeaway and next step

What to remember

The key decides which partition an event goes to, and for payments the key is usually the payment identifier, so every event for the same payment goes to the same partition and arrives in order.

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 "OpenAPI contracts: designing a payment API contract".

Transcript and full text

Show transcript

A payment hub processes thousands of payments a minute, and every important change is an event. When a payment is validated, the hub publishes a PaymentValidated event. When it is screened, it publishes a PaymentScreened event. When it settles, it publishes a PaymentSettled event. Other systems subscribe to the events they care about: the ledger subscribes to PaymentSettled, the notification service subscribes to PaymentValidated, the reporting service subscribes to everything. No system needs to know about the others. That is event-driven architecture, and in payments it is usually built on Apache Kafka. Kafka organises events into topics, and each topic is split into partitions. A topic is a named stream, for example payments.settled. A partition is a slice of that topic, and events are appended to a partition in order. The key decides which partition an event goes to, and for payments the key is usually the payment identifier, so every event for the same payment goes to the same partition and arrives in order. That ordering matters, because a PaymentSettled event must never be processed before the PaymentValidated event for the same payment. Ordering across different payments does not matter, because one payment does not depend on another. A consumer reads events from a topic and keeps track of its position, called an offset. If the consumer crashes, it restarts from its last offset and re-reads the events it missed. That is replay, and it is the feature that makes Kafka reliable for payments. If the ledger goes down for ten minutes, it does not lose any settlements. When it comes back, it replays the payments.settled topic from where it stopped and catches up. The events are retained for a configured period, for example seven days, so replay is possible for that long. After retention expires, the events are deleted and replay is no longer possible. Kafka delivers events at least once, not exactly once, which means a consumer can receive the same event twice. If the ledger processes a PaymentSettled event, crashes before it records its offset, and then replays, it will see the same event again. The ledger must therefore be idempotent: processing the same settlement twice must have the same effect as processing it once. In practice that means checking whether the payment identifier has already been posted before posting it again. A system that is not idempotent will double post on replay, and the ledger will go out of balance. Idempotency is not optional in an event-driven design; it is the safety net that makes at-least-once delivery safe. For a business analyst, event-driven design changes how requirements are written. Instead of writing a sequence of API calls, the BA writes the events: what triggers each event, what data it carries, who subscribes to it, and what happens if it arrives out of order or twice. The BA must also decide the retention period, because a short retention saves storage but limits replay, and a long retention costs more but gives operations more room to recover. And the BA must define the dead letter queue, which is where events go when they cannot be processed, so that a bad event does not block the whole topic. The lesson to carry forward is that events decouple systems, partitions preserve order per payment, replay recovers from crashes, and idempotency makes it all safe.

A payment hub processes thousands of payments a minute, and every important change is an event. When a payment is validated, the hub publishes a PaymentValidated event. When it is screened, it publishes a PaymentScreened event. When it settles, it publishes a PaymentSettled event. Other systems subscribe to the events they care about: the ledger subscribes to PaymentSettled, the notification service subscribes to PaymentValidated, the reporting service subscribes to everything. No system needs to know about the others. That is event-driven architecture, and in payments it is usually built on Apache Kafka.

Kafka organises events into topics, and each topic is split into partitions. A topic is a named stream, for example payments.settled. A partition is a slice of that topic, and events are appended to a partition in order. The key decides which partition an event goes to, and for payments the key is usually the payment identifier, so every event for the same payment goes to the same partition and arrives in order. That ordering matters, because a PaymentSettled event must never be processed before the PaymentValidated event for the same payment. Ordering across different payments does not matter, because one payment does not depend on another.

A consumer reads events from a topic and keeps track of its position, called an offset. If the consumer crashes, it restarts from its last offset and re-reads the events it missed. That is replay, and it is the feature that makes Kafka reliable for payments. If the ledger goes down for ten minutes, it does not lose any settlements. When it comes back, it replays the payments.settled topic from where it stopped and catches up. The events are retained for a configured period, for example seven days, so replay is possible for that long. After retention expires, the events are deleted and replay is no longer possible.

Kafka delivers events at least once, not exactly once, which means a consumer can receive the same event twice. If the ledger processes a PaymentSettled event, crashes before it records its offset, and then replays, it will see the same event again. The ledger must therefore be idempotent: processing the same settlement twice must have the same effect as processing it once. In practice that means checking whether the payment identifier has already been posted before posting it again. A system that is not idempotent will double post on replay, and the ledger will go out of balance. Idempotency is not optional in an event-driven design; it is the safety net that makes at-least-once delivery safe.

For a business analyst, event-driven design changes how requirements are written. Instead of writing a sequence of API calls, the BA writes the events: what triggers each event, what data it carries, who subscribes to it, and what happens if it arrives out of order or twice. The BA must also decide the retention period, because a short retention saves storage but limits replay, and a long retention costs more but gives operations more room to recover. And the BA must define the dead letter queue, which is where events go when they cannot be processed, so that a bad event does not block the whole topic. The lesson to carry forward is that events decouple systems, partitions preserve order per payment, replay recovers from crashes, and idempotency makes it all safe.

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.