Guest Articles / Learning brief
PAYMENTS – BASIC TECHNICAL CONCEPTS – PART 1
Your notes
In simple terms / 01
What this means in plain language
Introduces the integration and infrastructure concepts payment analysts encounter when engines exchange data with surrounding banking systems.
Payment engines rarely work alone. They receive instructions from channels or files, call customer and account services, screen parties, apply limits, route messages, post to ledgers, and exchange data with clearing networks. Analysts therefore need basic technical concepts such as APIs, files, queues, synchronous and asynchronous processing, identifiers, schemas, validation, acknowledgements, retries, and environments. The key is to connect each term to business behavior. For example, a timeout does not always mean failure; the receiving system may have processed the request even when the reply was lost.
Complete lesson / 02
Understand the full idea, step by step
When Riya taps Send and her app says Payment received, one screen made one promise. Behind it, a channel, a payment engine, and a handful of specialist systems just passed the same instruction between them — each one checking, answering, or holding. This lesson names the technical ideas an operations or technology person needs to read that behaviour, before we look at the engine that ties it together.
Straight-through processing (STP) — a payment that completes without a person touching it
STP means an instruction passes every check and posts to the far side automatically — validation, screening, routing, and settlement, all without manual repair. A bank measures how many payments go straight through because each one that stops costs an analyst's time. The goal is not zero human involvement everywhere; it is that only the genuinely unusual payment reaches a person.
Push and pull start in different places
Riya's transfer is a push: she instructs her bank to send money out, and the instruction travels toward the payee. A pull is the opposite — a gym or utility, with a mandate Riya signed, instructs *its* bank to collect from her account. A credit transfer pushes; a direct debit pulls. The distinction is not academic: a push is authorised by the payer up front, while a pull relies on a stored authority and can be disputed and reversed under scheme rules. Which one you are handling changes what can go wrong and who can undo it.
| Push (credit transfer) | Pull (direct debit) | |
|---|---|---|
| Who starts it | The payer instructs their own bank | The payee instructs their bank to collect |
| What authorises it | The payer, at the moment of sending | A mandate the payer signed earlier |
| Everyday example | Rent, salary, a supplier payment | Utility bill, subscription, loan instalment |
| Typical dispute path | Recall or investigation after the fact | Mandate-based refund under scheme rules |
Idempotency — the same request applied twice has the same effect as once
An operation is idempotent when repeating it does not repeat its effect. If Riya's app resends the exact same instruction after a dropped connection, an idempotent engine recognises the repeat — usually by a stable request key — and returns the original outcome instead of creating a second payment. Idempotency is the technical spine of duplicate control: it lets systems retry safely when they cannot tell whether the first attempt landed.
How the systems hand the payment along
- CUSTOMER
Riya confirms in the app and proves it is her.
- INSTRUCTION
The channel captures the instruction and stamps it with an identifier that will travel with it through every later system.
- VALIDATION
The payment engine validates format and data, then calls out to screening, limit, and account services — some answer at once, some queue work and report a status later.
- LEDGER
On acceptance the engine reserves or debits Riya's account and records the state as a durable event, not just a screen message.
- MESSAGE
The engine builds and sends the interbank message toward the far bank or a clearing system — information, not the money itself.
- NOTIFICATION
A status comes back and updates the payment record. Only now can any screen honestly say whether the far side accepted it.
A status is a stage, not a verdict
Accepted, screened, sent, settled, credited are not synonyms for success — each names a different point on the journey. A useful status describes business progress: an API can confirm the channel *received* the instruction while screening, posting, and external submission are still ahead. Reading statuses precisely is most of exceptions work, because the gap between two statuses is exactly where a payment can get stuck.
WHAT IF — A call times out: the engine sent a request but got no answer, so the downstream state is unknown
What happens: The payment sits between two statuses. It may have gone through, or not — and the two safe-looking actions, retry and mark-failed, are both wrong if the guess is wrong.
How it is handled: Maya resolves the uncertainty before acting: query the far system by the original identifier, inspect durable events, and check whether any posting occurred. Only once the last reliable state is known does she retry — safely, because the engine is idempotent — or move the item to controlled investigation. Recovery rules name who may retry and how duplicates are detected.
COMMON CONFUSION
“If a payment has no confirmation, the safe move is to send it again.”
Resending blind is how one instruction becomes two payments. "No confirmation" means the state is unknown, not that nothing happened. The safe move is to establish what actually occurred — by identifier, event log, and postings — and to rely on idempotency so a genuine retry cannot double-pay.
FOR NOW, REMEMBER
- STP is a payment that clears every check and posts without a person; each stop costs manual work.
- Push (credit transfer) is authorised by the payer up front; pull (direct debit) collects against a stored mandate.
- Idempotency lets a system retry safely — the same instruction applied twice has the effect of once.
- A status names a stage of the journey; the hardest failures are ambiguous states you must resolve before acting.
TRY IT YOURSELF
A payment shows `accepted` in the channel but no status from the clearing side, and the connection to that system timed out. What should Maya do first?
These ideas describe one payment moving between systems. The next question is architectural: why does a bank need a dedicated engine to coordinate all of them in the first place?
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
Payment processing depends on many connected systems.
- 02
Interfaces and acknowledgements shape operational outcomes.
- 03
Safe retry design must account for uncertain processing states.
Practical use cases / 04
Where you would use this
A business analyst specifies interface behavior for missing or delayed acknowledgements.
A tester verifies duplicate protection after a network timeout.
An operations designer maps technical errors to repair queues and customer statuses.
Worked example / 05
Put the idea into a real situation
Illustrative example: a mobile channel sends a payment request to the engine through an API, but the response times out. The channel must not immediately create a second payment. It queries using the original identifier while the engine checks validation, screening, ledger, and outbound-message states. If no result is available, the item enters controlled investigation. This design prevents a communications problem from becoming an accidental duplicate transfer.
Evidence & review / 07
Evidence & review
General payment-processing architecture; not tied to one scheme or jurisdiction.
What this brief simplifies: Treats the system chain as channel → engine → services in sequence; a real bank has more components, parallel calls, and richer status models. Idempotency is shown as key-based dedupe without protocol detail.
Sources for this brief2
- Market practiceMarch 2003 edition
A glossary of terms used in payments and settlement systems ↗ — CPSS (now CPMI), Bank for International Settlements · Straight-through processing; push/pull payment definitions
Terminology has evolved since this edition; newer CPMI publications refine some definitions.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.