Fintech and payments architecture: secure every transaction
Money apps are judged on trust: no lost payments, no leaked data, and proof of what happened. Here is how the pieces fit, which service plays each part on AWS, Azure and Google Cloud, which rules shape the design in different regions, and what auditors will ask to see.
Quick answer
A fintech or payments architecture puts a web application firewall in front of a payment API, queues each step so no transaction is lost, and records every transaction in a strongly consistent ledger database. Keys you hold, a protected audit trail and a second recovery site sit around that core.
| Best for | Payment gateways, wallets, lending and insurance apps, and banking features for regulated firms in any country |
|---|---|
| Less suited when | A prototype that handles no real money or card data, where a hosted payment page does the heavy lifting |
| Start with | A certified payment provider for card data, one region that fits your rules, your own keys and an audit trail from day one |
| Main services on AWS | Amazon Cognito, AWS CloudTrail, AWS Key Management Service, AWS WAF, AWS Elastic Beanstalk, Amazon SQS, Amazon RDS |
| Main services on Azure | Microsoft Entra External ID, Azure Activity Log, Azure Key Vault, Azure Web Application Firewall, Azure App Service, Azure Service Bus, Azure SQL Database |
| Main services on Google Cloud | Identity Platform, Cloud Audit Logs, Cloud Key Management Service, Cloud Armor, Cloud Run, Pub/Sub, Cloud SQL |
The idea in plain words
A payment app must get three things right: never lose or double-count a transaction, keep card and account data safe, and prove afterwards exactly what happened. Every part of the design serves one of these.
In practice that means a protected front door, an API that checks every request, a queue that holds each step until it is safely processed, and a ledger database that records every change. Keys, logs and a second recovery site surround them. Card data is the hardest to protect, so most teams hand card capture to a certified payment provider and never store full card numbers themselves.
Build the controls and the audit trail first, then the features. They are far harder to add once real money is moving.
The architecture
Boxes show the job each part does. Pick a cloud to see the service for each job.
Step by step
- The customer starts a paymentThe app or website sends the request over HTTPS. A web application firewall in front blocks bots, floods and common attacks before they touch your systems.
- Check who is payingA sign-in service verifies the customer with a second factor and asks again for risky actions, such as a first large transfer.
- The payment API checks the requestYour API validates the amount and account, applies limits and fraud rules, and gives each request a unique ID so a retry never charges twice.
- Card data goes to a certified providerCard details are captured by a PCI DSS certified payment provider or hosted fields, so your own systems never see or store full card numbers.
- Queue each stepSteps such as debit, credit, notify and reconcile go on a queue. A failed step is retried safely, so no payment is lost or applied twice.
- Record it in the ledgerA relational database with strong transactions writes the entry. Entries are added, never edited, so the history can always be checked.
- Lock the data with your keysAccount data and secrets are encrypted with keys in a key service you control and rotate, with the most sensitive keys kept in dedicated hardware.
- Keep a protected audit trailEvery action, from sign-in to refund, goes to a log store that nobody can edit, so you can answer a regulator's or a customer's question later.
- Plan for failureData is copied to a second location and the app can start there. Decide how much data you can lose and how long you can be down, then test it.
Services side by side
The main service for each job on each cloud, with a second option where one exists. Names checked on 23 October 2026.
| Job | AWS | Azure | Google Cloud |
|---|---|---|---|
| Customer sign-up and login |
|
|
|
| Audit logs: who did what |
|
|
|
| Encryption keys (KMS and HSM) |
|
|
|
| Web application firewall and DDoS protection |
|
|
|
| Web app or API hosting (managed platform) |
|
|
|
| Message queue (decouple parts of an app) |
|
|
|
| Relational (SQL) database |
|
|
|
| Compliance reports and certificationsOptional |
|
|
|
| Find and protect sensitive data (PII)Optional |
|
|
|
| Disaster recovery and failoverOptional |
|
|
|
Common variations
- You take card payments. Use hosted payment fields or a certified provider, so card numbers never reach your servers. This usually removes most of your PCI DSS scope.
- You pay out money or run a wallet. Keep a double-entry ledger, reconcile with your bank every day, and require a second approval for large payouts.
- You need real-time fraud checks. Send transaction events to a streaming service and a scoring model, and hold risky payments for review.
- You serve customers in other countries. Check the data rules of each country and keep each country's data where its rules require, for example India's payment data in India. Use separate regional stacks if the rules differ.
Provider-managed keys or dedicated hardware you control?
A key service creates and guards your encryption keys. For the most sensitive keys, each cloud also offers dedicated hardware security modules (HSMs), shown in the table.
| AWS | Azure | Google Cloud | |
|---|---|---|---|
| Encryption keys (KMS and HSM) |
|
|
|
Key management service
Good
- Simple to turn on and rotate
- Works with most storage and database services
- Every use of a key is logged
Watch out
- The provider runs the hardware
- Keys may sit in shared hardware
- Some regulators and card schemes ask for more
Dedicated HSM
Good
- Hardware used only by you
- Meets stricter rules on key custody
- You hold the master keys
Watch out
- Costs more
- You plan the availability and backup of the keys
- More skills needed to run it
Rules that shape a fintech design
Which rules apply depends on your licence and your markets: taking payments, lending, holding money and offering a bank service each bring different duties. The cards below list common ones, global first and then India, with the design feature that answers each.
PCI DSS (card data)
What it asksAny business that stores, processes or sends card data must meet PCI DSS: network controls, strong access, encryption, logging and regular testing.
How this design helpsA certified payment provider keeps card numbers out of your systems and shrinks the audit. The firewall, keys and audit trail cover the rest.
Anti-money-laundering and know-your-customer rules (FATF-based)
What it asksMost countries follow FATF standards: verify who your customers are, watch transactions for suspicious activity, report it to the authorities and keep records, often for at least five years.
How this design helpsThe ledger and audit trail keep the records, and a feed of transaction events can drive monitoring. Identity checks sit in the sign-up flow.
PSD2 strong customer authentication (EU and UK)
What it asksMost online payments in the EU and UK need two of three proofs: something known, something held and something the customer is.
How this design helpsThe sign-in service adds the second factor, and the payment API asks again for risky actions.
EU DORA (financial firms)
What it asksApplies from January 2025 to financial firms and their critical ICT providers: ICT risk management, incident reporting, resilience testing and oversight of third-party providers such as cloud.
How this design helpsA tested recovery site, the audit trail and a written exit plan from your provider support these duties.
GDPR and similar privacy laws
What it asksHandle personal data lawfully, collect only what you need, protect it, contract your processors, limit transfers abroad and report breaches, within 72 hours under GDPR.
How this design helpsEncryption, access control and the audit trail are the safeguards. Choose regions that fit your customers, and plan deletion alongside records that financial rules require.
RBI payment data storage rule, 2018
What it asksPayment system operators must store all data about the payments they handle only in India. If processing happens abroad, the data must come back to India within one business day or 24 hours.
How this design helpsChoose an Indian region for the ledger, backups and logs, and check where each managed service keeps its data and copies.
RBI outsourcing of IT services, 2023
What it asksRegulated entities that use outside IT or cloud providers stay fully responsible. They need due diligence, contracts that allow audits, an exit plan and prompt incident reporting.
How this design helpsA provider's compliance reports, a written exit path and the audit trail support these duties. Keep the contract terms next to the design.
RBI IT governance and security rules, 2023
What it asksRegulated entities need board-approved IT and security governance, strong access control and logging, tested recovery and prompt reporting of incidents.
How this design helpsThe access controls, audit trail and tested recovery site map directly to these duties.
Digital Personal Data Protection (DPDP) Act, 2023
What it asksCustomer details and payment data are personal data: process them with consent or another lawful ground, take only what you need, secure them, tell people about breaches and honour correction and erasure requests.
How this design helpsEncryption, tight access and the audit trail protect the data. Plan deletion requests around the records that financial rules oblige you to keep.
CERT-In incident directions, 2022
What it asksCyber incidents of the listed types must reach CERT-In within 6 hours, and ICT system logs must be kept for a rolling 180 days within Indian jurisdiction.
How this design helpsCentral logs held in an Indian region for at least 180 days give you the evidence for a timely report.
Who looks after what
The cloud provider looks after
- The data centres, hardware and network
- Patching and running the managed services
- Certifications and audit reports for its own controls
- The tools to encrypt, log and isolate your workloads
You look after
- Your payment logic, limits and fraud rules
- Who can sign in and who can approve what
- Turning on and testing encryption, logs and recovery
- Where data lives and which vendors can reach it
- Reporting incidents to the regulator and your partners
Evidence an auditor will ask to see
Tick what you could show today. The gaps are your to-do list.
Keep in mind
- Idempotency. Give every payment request a unique ID, so a retry after a timeout does not charge twice. Test what happens when each step fails halfway.
- Reconciliation. Compare your ledger with the bank or network every day and chase differences quickly. It is the best early warning of a bug.
- Data location. Keep payment data in the regions your rules require, check where each managed service stores copies and logs, and write it down for the regulator. India, for one, requires payment data to stay in India.
- Secrets and keys. Keep keys and passwords in a secrets service, rotate them, never put them in code, and restrict who can use the most sensitive keys.
- Recovery targets. Decide how many minutes of data you can lose and how long you can be down, then build and rehearse to those numbers.
- Licences and partners. Your regulator licence, bank partner or card scheme may add rules beyond this page. Ask them before you design, not after.
- Cost. Cost grows with transactions, logging and the second site. Price it with real payment volumes, and watch log and backup storage, which grows with every transaction.
Words used on this page
Services in this pattern that have changed
Cloud providers rename and retire services often. These affect the parts above. Checked on 23 October 2026.
- AWS Closed to new customers AWS App Runner stopped accepting new customers on 30 April 2026. AWS recommends Amazon ECS Express Mode for new container web apps. Details
- Azure Closed to new customers Azure AD B2C has not been sold to new customers since 1 May 2025. Microsoft Entra External ID is the replacement for new projects. Details
Sources and further reading
Check details such as features, limits, prices and regions in the providers' own documentation.
- AWS documentation (opens in a new tab)
- Microsoft Azure documentation (opens in a new tab)
- Google Cloud documentation (opens in a new tab)
Announcements about the changed services above
Frequently asked questions
What is PCI DSS?
PCI DSS is the security standard for businesses that store, process or send card data. It covers networks, access, encryption, logging and testing. Using a certified payment provider for card capture can shrink what you must prove.
Can payment data be stored in the cloud?
Yes, with conditions. Card data falls under PCI DSS, personal data under laws such as GDPR, and regulated firms under rules on outsourcing and resilience, such as DORA in the EU and RBI's directions in India, which also require payment data to stay in India. Check the rules for your licence and markets.
How do I stop a payment being charged twice?
Give every request a unique ID and store it with the result. If the same ID arrives again, return the saved result instead of charging again. Queues and a transactional database make retries safe.
Which database suits a payment ledger?
A relational database with strong transactions suits most ledgers, because every entry must be all-or-nothing and consistent. Each cloud offers managed options with backups and a standby copy in another zone.
What is a hardware security module (HSM)?
An HSM is dedicated hardware that creates and guards encryption keys so they cannot be copied out. Each cloud offers one as a service. Use it for your most sensitive keys when rules or partners require it.
Want this reviewed for your case?
CloudBrum architects can adapt this pattern to your documents, users, rules and budget, and estimate the cost. Nothing is sent until you choose.
Building something else?
Describe it in plain words and get matching services on all three clouds.
Service suggester → Cloud consulting →