PAYMENTS SIGNAL REFERENCE ARCHITECTURE · SYNTHETIC / TRAINING ONLY

Payment lifecycle, state, event, queue, and idempotency architecture

A payment is not one database row that changes mysteriously. It is an ordered history of commands, proven outcomes, deadlines, and external facts.

Reference architecture v1 · reviewed 2026-07-23

Reference architecture—not a scheme mandate. The blueprint assumes one logical payment-state owner and uses one queue and one journal. Real estates may shard by product or region and may use several brokers, stores, and recovery coordinators.

Audience and purpose

Solution architects, engineers, analysts, testers, and operations teams designing recoverable payment processing

Components

Command intake

Receives a request to do something and assigns it one identity.

Kind

service

Owner

Payment platform

Responsibilities

Authenticate the caller
Validate the requested command
Apply idempotency

Inputs

Submit, cancel, release, return, retry, or repair command

Outputs

Accepted command or reasoned rejection

Controls

Caller entitlement
Expected version
Idempotency key

Failure modes

Stale command
Repeated command
Unauthorised action

Recovery

Return the prior result or reject the stale action

Non-functional requirements

Traceable processing with stable identifiers
Capacity and availability matched to the supported payment service
Auditable state changes and operator actions

Payment state machine

Allows only transitions that make sense for the payment’s proven history.

Kind

application

Owner

Payment platform

Responsibilities

Evaluate transitions
Issue downstream commands
Record pending and final states

Inputs

Commands and dependency outcomes

Outputs

New state, events, timers, and exceptions

Controls

Optimistic concurrency
Final-state protection
Reason codes

Failure modes

Impossible transition
Two writers
State ahead of evidence

Recovery

Quarantine conflicts
Rebuild from the journal
Reconcile external facts

Non-functional requirements

Traceable processing with stable identifiers
Capacity and availability matched to the supported payment service
Auditable state changes and operator actions

Immutable event journal

Keeps the ordered facts from which the current payment state can be explained.

Kind

data-store

Owner

Payment platform

Responsibilities

Append facts once
Preserve order
Link commands and results

Inputs

Accepted state events

Outputs

Event stream and reconstructed history

Controls

Sequence
Integrity
Retention
Access control

Failure modes

Event gap
Duplicate event
Out-of-order event

Recovery

Detect sequence breaks
Replay idempotently
Repair projections without rewriting facts

Non-functional requirements

Traceable processing with stable identifiers
Capacity and availability matched to the supported payment service
Auditable state changes and operator actions

Transactional outbox and queue

Carries commands and events without losing them between the payment record and another system.

Kind

service

Owner

Payment platform

Responsibilities

Publish after durable commit
Retry delivery
Preserve ordering where required

Inputs

Committed outbound work

Outputs

At-least-once delivery with stable message identity

Controls

Stable message ID
Retry backoff
Dead-letter monitoring

Failure modes

Poison message
Queue backlog
Duplicate delivery

Recovery

Fix or quarantine poison data
Replay safely
Scale consumers

Non-functional requirements

Traceable processing with stable identifiers
Capacity and availability matched to the supported payment service
Auditable state changes and operator actions

Timer and deadline service

Turns a business deadline into a recorded event instead of an untracked sleep.

Kind

control

Owner

Payment platform

Responsibilities

Schedule cut-offs and timeouts
Fire once logically
Cancel obsolete timers

Inputs

Deadline and payment identity

Outputs

Timeout or cut-off event

Controls

Clock source
Deduplication
Late-event handling

Failure modes

Timer fires twice
Clock drift
Timer lost

Recovery

Reconcile due timers
Apply idempotent timeout handling

Non-functional requirements

Traceable processing with stable identifiers
Capacity and availability matched to the supported payment service
Auditable state changes and operator actions

Ledger system

Owns the accounting fact independently from the payment engine’s processing state.

Kind

ledger

Owner

Core banking and finance

Responsibilities

Post once
Return journal evidence
Reverse through a separate entry

Inputs

Posting command

Outputs

Posting result and journal reference

Controls

Balanced entries
Posting key
No destructive edit

Failure modes

Unknown response
Rejected posting
Duplicate conflict

Recovery

Query
Adopt
Retry or reverse under authority

Non-functional requirements

Traceable processing with stable identifiers
Capacity and availability matched to the supported payment service
Auditable state changes and operator actions

External network

Owns delivery, acceptance, clearing, or settlement facts outside the bank.

Kind

external-network

Owner

External network or market infrastructure

Responsibilities

Apply network rules
Return acknowledgement and status
Preserve duplicate treatment

Inputs

Network instruction

Outputs

Acknowledgement, status, settlement evidence, report

Controls

Message identity
Participant entitlement
Finality

Failure modes

Late status
Unknown outcome
Service outage

Recovery

Use network enquiry and contingency procedures

Non-functional requirements

Traceable processing with stable identifiers
Capacity and availability matched to the supported payment service
Auditable state changes and operator actions

Read model and status API

Presents a useful current view without becoming a second source of truth.

Kind

service

Owner

Payment platform

Responsibilities

Project events
Explain pending states
Serve channels and operations

Inputs

Payment event stream

Outputs

Current status, history, and next permitted actions

Controls

Freshness indicator
Version
No unauthorised actions

Failure modes

Stale projection
Missing event
Misleading final status

Recovery

Rebuild from the journal
Expose freshness and uncertainty

Non-functional requirements

Traceable processing with stable identifiers
Capacity and availability matched to the supported payment service
Auditable state changes and operator actions

Exception and reconciliation desk

Resolves cases where internal state and external evidence do not yet tell one consistent story.

Kind

operations

Owner

Payment operations

Responsibilities

Compare facts
Stop unsafe replay
Apply controlled recovery
Close only on evidence

Inputs

Payment history, ledger journal, network evidence, timers, alerts

Outputs

Reasoned command, escalation, or reconciled closure

Controls

Segregation of duties
Evidence checklist
State-aware action permissions

Failure modes

Premature closure
Manual duplicate
Action on stale state

Recovery

Refresh facts
Reopen
Apply compensating action under authority

Non-functional requirements

Traceable processing with stable identifiers
Capacity and availability matched to the supported payment service
Auditable state changes and operator actions

Interfaces

Expected-state command

state-command → state-machine

Ask for one transition against a known payment version.

Contract

api · synchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

Reject stale, duplicate, or unauthorised commands.

Append state event

state-machine → state-journal

Record the accepted fact before publishing downstream work.

Contract

event · asynchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

Do not expose an uncommitted transition.

Committed work

state-journal → state-outbox

Publish only work associated with a committed state.

Contract

event · asynchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

Retry delivery with the same event identity.

Posting command

state-outbox → state-ledger

Request one posting using a stable key.

Contract

posting · asynchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

Duplicate delivery must return the existing posting result.

Network command

state-outbox → state-network

Release one network instruction after its prerequisite state is committed.

Contract

message · asynchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

Use message identity and network enquiry before replay.

Network result

state-network → state-machine

Advance the payment using external evidence.

Contract

event · asynchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

Late or duplicate results are correlated and assessed against the current state.

Deadline event

state-timer → state-machine

Turn time expiry into a normal idempotent state input.

Contract

control · asynchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

A duplicate timeout must not apply its effect twice.

Projection feed

state-journal → state-projection

Build channel and operator views from authoritative events.

Contract

event · asynchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

Expose staleness and rebuild without changing the event journal.

Case evidence

state-projection → state-operations

Present current state, uncertainty, and permitted actions.

Contract

operator · operator

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

Refresh and reject commands if the payment version changed.

Authored traces

One durable state journey

Follow a payment from command to journal, posting, network result, and operator-visible status.

Receive one command — COMMAND_RECEIVED. The caller asks for one change against a known payment identity.
Accept one transition — TRANSITION_ACCEPTED. The state machine confirms the command is valid for the current state.
Write the fact — RECORDED. The accepted transition becomes durable before work leaves the core.
Publish committed work — DISPATCHED. The outbox carries the command using a stable identity and retry policy.
Record the accounting result — POSTED. The ledger posts once and returns its own journal fact.
Release the network instruction — SENT. The external service receives one identified instruction.
Apply the external result — NETWORK_CONFIRMED. The payment advances only when the external evidence is compatible with its current state.
Present an explainable status — VISIBLE. Channels and operators see the current state, history, and any remaining uncertainty.

Stress cases

Queue delivers twice

The outbox retries after the consumer processed the first delivery but its acknowledgement was lost.

Last confirmed state

The outbound work is committed and may already have been processed.

Settlement

Depends on the first network delivery; the repeat cannot be assumed new.

Funds and entries

The posting may already exist under the original key.

Next owner

Payment-platform operations

Safe action

Consumers return the existing result for the same identity and reject changed reuse.

Evidence required

Event ID
Posting key
Network message ID
Consumer result

Recovery

Deduplicate
Return existing outcome
Advance state once

Timeout followed by late success

The business timer fires, then a positive network status arrives later.

Last confirmed state

The instruction was sent; completion was not confirmed before the deadline.

Settlement

Unknown at timeout; the late status may prove that settlement succeeded.

Funds and entries

Any timeout restoration or release must be reconciled against the late success.

Next owner

Payment operations with payment-platform support

Safe action

Treat timeout as uncertainty, block blind retry, and reconcile the late status against the original payment.

Evidence required

Timer event
Original network ID
Late status
Ledger effects
Customer adjustment

Recovery

Correlate late status
Determine settlement
Correct any temporary customer treatment
Close with evidence

Operator acts on stale status

An operator opens a held payment, but a network result changes its state before the operator presses release.

Last confirmed state

The screen is older than the authoritative event journal.

Settlement

The current state may already be final.

Funds and entries

No second release or compensating posting is permitted from a stale view.

Next owner

Payment operations

Safe action

Use expected-version checks and reject the stale command before it changes anything.

Evidence required

Displayed version
Current version
Operator identity
Rejected command

Recovery

Refresh
Explain the new state
Offer only currently permitted actions

Design decisions

Is the current-state row or the event journal authoritative?

Event journal plus projection — Provides an explainable history and rebuild path but demands strict event governance.
Current row plus audit log — Can be simpler, but the audit log must still prove every transition and partial failure.

Either model can work; name one authority, preserve immutable history, and test reconstruction after partial failure.

How does the design handle the claim of exactly-once processing?

At-least-once plus idempotency — Accepts that delivery can repeat and makes every economic command safe to repeat.
Single transactional boundary — Works only where all state and side effects truly share one transaction; external networks and ledgers usually do not.

Do not promise end-to-end exactly once across independent systems. Design stable identities, deduplication, enquiry, and reconciliation.

Sources and disclosed synthesis

Principles for financial market infrastructures — Principle 17 — operational risk · CPMI-IOSCO Principles for financial market infrastructures · checked 2026-07-23
Payments Signal editorial teaching models — Payment-state synthesis · Payments Signal reference architecture v1 · checked 2026-07-23 · This is a software reference pattern. Payment schemes define outcomes and timing; they do not prescribe this internal event architecture.
Payments Signal editorial teaching models — Component: Command intake · Payments Signal reference architecture v1 · checked 2026-07-23 · Component boundaries and product names vary between institutions.
Payments Signal editorial teaching models — Component: Payment state machine · Payments Signal reference architecture v1 · checked 2026-07-23 · Component boundaries and product names vary between institutions.
Payments Signal editorial teaching models — Component: Immutable event journal · Payments Signal reference architecture v1 · checked 2026-07-23 · Component boundaries and product names vary between institutions.
Payments Signal editorial teaching models — Component: Transactional outbox and queue · Payments Signal reference architecture v1 · checked 2026-07-23 · Component boundaries and product names vary between institutions.
Payments Signal editorial teaching models — Component: Timer and deadline service · Payments Signal reference architecture v1 · checked 2026-07-23 · Component boundaries and product names vary between institutions.
Payments Signal editorial teaching models — Component: Ledger system · Payments Signal reference architecture v1 · checked 2026-07-23 · Component boundaries and product names vary between institutions.
Principles for financial market infrastructures — Principles 8, 17, and 22 · CPMI-IOSCO Principles for financial market infrastructures · checked 2026-07-23
Payments Signal editorial teaching models — Component: Read model and status API · Payments Signal reference architecture v1 · checked 2026-07-23 · Component boundaries and product names vary between institutions.
Payments Signal editorial teaching models — Component: Exception and reconciliation desk · Payments Signal reference architecture v1 · checked 2026-07-23 · Component boundaries and product names vary between institutions.
Payments Signal editorial teaching models — Interface: Expected-state command · Payments Signal reference architecture v1 · checked 2026-07-23 · The transport and interface contract are illustrative; implementations select their own protocol.
Payments Signal editorial teaching models — Interface: Append state event · Payments Signal reference architecture v1 · checked 2026-07-23 · The transport and interface contract are illustrative; implementations select their own protocol.
Payments Signal editorial teaching models — Interface: Committed work · Payments Signal reference architecture v1 · checked 2026-07-23 · The transport and interface contract are illustrative; implementations select their own protocol.
Payments Signal editorial teaching models — Interface: Posting command · Payments Signal reference architecture v1 · checked 2026-07-23 · The transport and interface contract are illustrative; implementations select their own protocol.
Payments Signal editorial teaching models — Interface: Network command · Payments Signal reference architecture v1 · checked 2026-07-23 · The transport and interface contract are illustrative; implementations select their own protocol.
Payments Signal editorial teaching models — Interface: Network result · Payments Signal reference architecture v1 · checked 2026-07-23 · The transport and interface contract are illustrative; implementations select their own protocol.
Payments Signal editorial teaching models — Interface: Deadline event · Payments Signal reference architecture v1 · checked 2026-07-23 · The transport and interface contract are illustrative; implementations select their own protocol.
Payments Signal editorial teaching models — Interface: Projection feed · Payments Signal reference architecture v1 · checked 2026-07-23 · The transport and interface contract are illustrative; implementations select their own protocol.
Payments Signal editorial teaching models — Interface: Case evidence · Payments Signal reference architecture v1 · checked 2026-07-23 · The transport and interface contract are illustrative; implementations select their own protocol.
Payments Signal editorial teaching models — State journey · Payments Signal reference architecture v1 · checked 2026-07-23 · State names and ordering are illustrative; institutions and rails use different lifecycle models.
Payments Signal editorial teaching models — At-least-once delivery stress case · Payments Signal reference architecture v1 · checked 2026-07-23 · Queue products differ; the invariant is stable identity and idempotent consumption.
Payments Signal editorial teaching models — Late-success stress case · Payments Signal reference architecture v1 · checked 2026-07-23 · Exact timeout and restoration rules depend on the payment service.
Payments Signal editorial teaching models — Stale-command stress case · Payments Signal reference architecture v1 · checked 2026-07-23 · User-interface implementation varies; the control is version-aware command handling.
Payments Signal editorial teaching models — Architecture decision: state authority · Payments Signal reference architecture v1 · checked 2026-07-23 · No payment standard prescribes the bank’s internal persistence pattern.
Payments Signal editorial teaching models — Architecture decision: delivery semantics · Payments Signal reference architecture v1 · checked 2026-07-23 · The limitation follows from independent transaction boundaries, not a scheme rule.