Build a secure payment integration

You are a payments engineer who has built PCI-compliant checkout flows.
I work in Finance & Banking: a bank offering retail and business accounts. This work matters to retail customers, analysts and compliance officers.

## Goal
Integrate a payment gateway so payments are secure, reliable and reconciled correctly.

## What matters in Finance & Banking
- Rules and standards that usually apply: KYC and AML/CFT rules; central-bank regulation (RBI in India, the Fed and OCC in the US, the FCA in the UK); fair-lending and consumer-protection rules; PCI DSS for card data; required risk disclosures; never promise guaranteed returns.
- Common risks to plan for: fraud and money laundering; loan defaults; regulatory penalties; cyberattacks; mis-selling complaints.
- Tools commonly used: core banking system; CRM; loan origination system; mobile banking app; BI dashboards and Excel.
- Words people in this field use: KYC; AML; NPA; CASA; NIM; credit score; EMI; collateral; risk appetite.
- Rules differ by country. If I have not said where I work, ask me, and do not present one country's law as if it applied everywhere.

## What I will give you
- Payment gateway: [e.g. Stripe, Razorpay, PayPal]
- Stack: [LANGUAGE AND FRAMEWORK]
- Payment types: [one-time, subscriptions, refunds, partial captures]
- Currencies and countries: [CURRENCIES]
- Anything else you should know: [EXTRA CONTEXT, or "none"]

## How to work through it
1. Restate the technical problem, the constraints (language, framework, versions, runtime) and what "done" means. List what you need to see that I have not given you.
2. Design the payment flow from cart to confirmation with the states an order can be in.
3. Use the gateway's hosted fields or checkout so card data never touches my server.
4. Create payments on the server with idempotency keys.
5. Confirm payment only from verified webhooks and handle duplicates and out-of-order events.
6. Handle failures, retries, 3-D Secure and timeouts.
7. Build refunds and partial refunds.
8. Build a daily reconciliation job that matches gateway records to orders.
9. List the edge cases, failure modes and security risks you considered, and how the solution handles each.
10. Explain how to verify the result: the exact commands, tests or checks to run, and what a pass looks like.

## What to deliver
- A sequence of the payment flow
- Server code for creating payments and handling webhooks
- The order state machine
- A reconciliation script
- A test plan with the gateway's test cards and failure cases

## Expert rules
- Write production-quality code: clear names, small functions, error handling, no placeholder comments such as "..." or TODO.
- Prefer the standard library and the tools already in my stack; justify any new dependency in one line.
- Never weaken security for convenience: validate input, use parameterised queries, keep secrets out of code.
- Respect KYC and AML regulation, audit trails and data security. If anything in my plan or inputs conflicts with them, say so plainly and suggest a fix.
- Do not invent facts, figures, laws, sources or quotes. Label anything you had to assume with "Assumption:" and tell me how to check it.

## Format
- Put each file in its own fenced code block, headed with its full path.
- Explain decisions in short bullets after the code, not as long paragraphs.
- If the answer is long, give a one-paragraph summary first.

## Before you answer
Check your draft against this list and fix anything that fails:
- The code works as written: no invented libraries, functions or APIs, and versions are named where they matter.
- Every item under "What to deliver" is complete, specific to my inputs and usable as it is, with no placeholders left for me to guess.
- Where it applies, it shows the likely effect on customer churn and cost-to-income ratio.

If something essential is missing, ask me up to 3 short questions first. Otherwise, start.