How Payments Are Processed: Clear Steps, Strong Controls, No Surprises
Part 12 Building Tomorrow's Financial Systems
Hi Everyone,
Firstly, thank you to all my new followers, and subscribers this week. It’s been an exciting fews months here at Architects Assemble so we are thrilled you have joined us.
The aim of this series is to simplify architecting payment systems. The series covers understanding the logic and the data flow throughout the system to enable us to design an efficient system.
As you know we have set the foundational architecture for designing the system and we continue our journey designing and evolving the architecture.
Here’s what’s coming up:
The strategy report Future-Proofing Faster Payments 2025-2030 is out at the end of the month.
How leading UK fintechs using FPS have architected cost-efficient systems.
Core Step Functions patterns to use in payments.
If you have missed any parts of the series you can catch up here:
Throughout our work designing a payments system, we have focused on a tightly controlled flow of decisions, external calls, and immutable records.
Here’s what we’ve discovered.
The business of moving money lives in one place: the Orchestration Layer.
A Lambda called Orchestrate Payment Logic, backed by Step Functions, runs the rules, manages retries and compensation, and writes the immutable evidence auditors demand.
Step Functions is the orchestration brain. It sequences validation, idempotency checks, PSP calls, retries and compensation, records every transition in execution history, and gives you a single, auditable timeline for each transaction. Instead of stuffing complex branching and retry logic inside Lambdas, you model the flow as states — making behavior obvious to operators and auditors.
“The Orchestration Layer moves money — the rest of the stack proves you did it right.”
The payments path simplified
Understanding the logic behind architecting a system like payments requires a thought process that balances security, compliance, and non-repudiation with performance, cost, and operational simplicity designing every path to be observable, auditable, and resilient to failure.
Traffic hits API Gateway (WAF/Shield at the edge). The gateway invokes the Orchestrate Payment Logic Lambda. That Lambda validates input, pulls PSP credentials from Secrets Manager (KMS decrypts them), and either completes the payment or hands a longer flow to Step Functions. Final outcomes are written as immutable, auditable records: high-throughput ledger writes in DynamoDB, transactional state in RDS, and tamper-evident logs in S3 (Object Lock + encryption). Events stream to Kinesis/SageMaker for near-real-time fraud scoring and to Athena for ad-hoc queries.
This is the hot path — elastic, observable, and instrumented. Lambda supplies scale and cost efficiency; Step Functions provide deterministic workflows and visibility that make retries, compensations, and audits straightforward.
Why this pattern wins
Scalable + cheap: serverless for bursty traffic.
Deterministic: Step Functions make flows auditable and debuggable.
Compliant by design: orchestration points are natural places to inject KYC/AML checks, consent captures, and evidence collection.
Recoverable: idempotency, immutable ledgers, and durable audit logs enable reconciliation and forensics.
Security and compliance
We don’t bolt compliance on we build it into every transaction.
Key & secret hygiene: Secrets Manager + customer-managed KMS (CloudHSM where required) for credentials and ledger signing.
Edge protection & detection: WAF/Shield, GuardDuty, CloudTrail, CloudWatch and Macie for PII discovery.
Data residency & segmentation: PII restricted to the required region; production systems in isolated VPCs.
Immutable evidence: S3 Object Lock, versioning and DynamoDB ledger entries backed by signed hashes.
AML/KYC & fraud: Screening and models run in the orchestration pipeline; persist model input + version for audit trails.
“Tokenize PANs, sign ledgers, lock the logs — make every step provable.”
Practical compliance mapping (what auditors ask for — where it lives)
PCI: Tokenize or avoid PAN storage, use KMS for keys, document key usage and Secrets Manager rotation.
SOC 2: CloudTrail + Config snapshots, change control logs, role matrices, runbooks.
GDPR / DSARs: Data inventory, consent records, regional PII handling, DSAR runbook + evidence.
AML/KYC: Screening logs, transaction monitoring feeds, saved decisions with model versions.
Retention / Legal Hold: S3 Object Lock and immutable ledger entries as evidence.
Checklist — what to implement this week
Tokenize or never store PANs.
Enable Secrets Manager rotation and use customer-managed KMS keys.
Turn on S3 Object Lock for audit buckets and automate daily CloudTrail + Config snapshots.
Enforce MFA, short-lived creds, and least-privilege IAM roles.
Add idempotency keys to API flows and instrument Step Functions retries/compensation.
Persist model inputs and model versions for fraud decisions.
Schedule regular reconciliation + DR drills and retain evidence.
The Architect’s Perspective (for engineering leads & CTOs)
Payments are trust instruments. The Orchestration Layer moves money; the rest of the stack proves you did it properly. Build compliance into the runtime — tokenization, signed ledgers, immutable logs, region controls, and auditable workflows and you’ll scale faster.
Thank you for being a valuable reader and until next time keep syncing…..