Payment processing that never charges twice

The client sends a unique key per payment attempt. The server stores the key with the request hash and, once done, the response. A repeat with the same key returns the stored response instead of charging again; a repeat with a different body is rejected. Keys are unique-indexed, so two concurrent requests cannot both win.

Every transaction is recorded as equal debits and credits across accounts, so the books always balance and any error shows up as an imbalance. It is append-only, which gives a full audit trail, and balances can be recomputed from entries at any time.

The customer submits card details to the payment provider (tokenised, never touching your servers), you create a payment intent with an idempotency key, the provider authorises with the card network and issuer (possibly with 3-D Secure), you capture the funds (immediately or later), and settlement moves money to your account days later. Refunds and chargebacks can follow.

As an explicit state machine: created, requires_action, authorised, captured, failed, refunded, partially_refunded, disputed. Only allowed transitions are applied, every change is recorded with its source event, and webhooks or API responses drive transitions idempotently.

Verify the signature, store the raw event with its ID, respond 2xx quickly, process asynchronously, deduplicate by event ID, tolerate out-of-order delivery by checking state, and reconcile periodically in case webhooks are missed.

Use the payment provider as the source of truth for money, record the payment intent before calling it, update order status only from confirmed payment events, and run reconciliation jobs that compare your records with the provider's to fix any mismatch.

The client sends a unique key with each payment request. The server stores the key with the request hash and result in the same transaction as the payment, and on a retry with the same key returns the stored result instead of charging again. A different body with a reused key is rejected.

Mark the payment pending, never failed. Query the provider's status API with the same idempotency key, and wait for the webhook. Reconciliation catches anything still unresolved. Only retry the charge with the same key.

Authorisation reserves funds on the card without moving them; capture actually charges them. Separate capture suits marketplaces and shipping-on-dispatch, but authorisations expire after days, so capture in time or re-authorise.

Never let raw card numbers touch your servers: use the provider's hosted fields, checkout pages or SDKs that tokenise in the browser. Then you only handle tokens, which keeps you in the lightest compliance category.

Create refunds through the provider with an idempotency key, track refunded amounts against the captured amount, update the ledger with reversing entries, and only mark the order refunded when the provider confirms.

Receive dispute webhooks, freeze related payouts if needed, gather evidence automatically (receipts, delivery proof, logs), submit it before the deadline, record outcomes in the ledger, and track dispute rates because high rates bring penalties.

Store amounts in minor units with an ISO currency code, never mix currencies in one sum, record exchange rates used at the time of conversion, and settle in the currencies your provider supports.

Retry only transient errors (network, timeout, rate limits) with the same idempotency key and backoff. Do not retry hard declines like insufficient funds automatically; for subscriptions use dunning schedules with customer notifications.

Store a payment method token with the customer's consent (mandate), create invoices per billing cycle, charge automatically, handle failures with dunning and grace periods, and apply proration when plans change mid-cycle.

Every money movement is a balanced transaction of debit and credit entries across accounts, such as customer, merchant, fees and settlement, so the sum is always zero. Entries are append-only; corrections are new reversing entries. Balances are derived from entries and reconciled against bank statements.

Daily, download the provider's settlement and transaction reports, match each item to your payments by provider ID and amount, flag mismatches such as missing captures, unexpected refunds or fee differences, and route unresolved items to a finance queue with an owner.

An authentication step where the issuer verifies the cardholder (for example via an app or OTP). It shifts fraud liability to the issuer and is required for many transactions under rules like PSD2 SCA in Europe or RBI mandates in India.

Use the provider's risk scoring, check velocity (many attempts per card or IP), mismatched addresses, unusual amounts and device fingerprints, block card-testing patterns with rate limits and CAPTCHA, and review high-risk orders manually.

Collect payment into the platform, record each seller's share in the ledger, hold funds until delivery or a period passes, then pay out through the provider's connected accounts, handling fees, refunds and negative balances.

It needs stricter security, auditing and change control, has different scaling and availability needs, and isolating it keeps compliance scope small and protects it from unrelated bugs.

Every API request and response (without card data), state transitions, webhooks with IDs, idempotency keys and correlation IDs, enough to reconstruct any transaction for support, audits and disputes.

Use the provider's test mode and test cards for success, decline and 3-D Secure, replay recorded webhooks, test idempotency by sending duplicate requests, and run end-to-end tests in a sandbox before releases.

The gateway securely collects and transmits payment details from the merchant; the processor communicates with card networks and banks to authorise and settle. Modern providers like Stripe or Razorpay bundle both.

Mark it unknown, never failed, then query the provider with the same idempotency key or payment ID until it reports a final state, and rely on webhooks and reconciliation as backstops. Tell the user the payment is being confirmed rather than inviting a second attempt.

Compute tax at checkout from the place of supply, product category and customer's tax ID using a versioned rules table or tax service, store the tax breakdown on the invoice line items, and never recompute old invoices when rates change.

Collect the new card through the provider's hosted fields or SDK, which returns a token or payment method ID, attach it to the customer, run a zero-amount or small authorisation to verify it if required, set it as default, and retry any open failed invoice on it.

UPI moves money directly between bank accounts in real time through NPCI, with the customer approving in their UPI app; there is no separate authorisation and capture step, and failures or pending states need status checks and reconciliation.

As long as tax, accounting and regulatory rules require (often several years), with sensitive data minimised, encrypted and access-controlled.

Show pending, success or failure with next steps, avoid asking users to pay again while a payment is pending, and send receipts by email once confirmed.

Authorisation and success rates by method and issuer, latency, error types, refund and dispute rates, reconciliation mismatches and revenue per day, with alerts on sudden drops.

Show the price in the buyer's currency using a rate locked for a short window, store both the presented amount and the settlement amount with the rate used, and let the provider or bank do the actual conversion. Record FX gains or losses in the ledger.

1. AAs strings with a currency symbol
2. BAs doubles rounded on display
3. CAs floats in rupees
4. DAs integers in the smallest unit (paise, cents)Correct answer

Why: Integers avoid floating-point rounding errors; 10.10 is stored as 1010 paise.

1. AYour logs
2. BThe payment provider's hosted fields or SDKCorrect answer
3. CYour API server
4. DYour database

Why: This keeps PCI scope minimal.

1. AVerify the signatureCorrect answer
2. BShip the order
3. CEmail the customer
4. DRetry the payment

Why: Unsigned events could be forged.

1. AThe browser redirect
2. BThe order form
3. CA log message
4. DThe payment provider's confirmed eventsCorrect answer

Why: Redirects can be faked or lost.

1. AA 500 error
2. BA random payment ID
3. CThe stored result of the first requestCorrect answer
4. DA new charge

Why: Retries must not move money twice.

1. AReply with 500 first
2. BVerify its signatureCorrect answer
3. CStore it in Redis
4. DForward it to the browser

Why: The signature proves the provider sent it and it was not altered, so attackers cannot fake a payment success.

1. ACharges immediately
2. BRefunds the customer
3. CSettles to your bank
4. DReserves funds without chargingCorrect answer

Why: Authorisations expire after days.

1. ANetwork errors and timeoutsCorrect answer
2. BInsufficient funds
3. CStolen card declines
4. DExpired cards

Why: Hard declines need the customer.

1. AStrings with symbols
2. BRounded to whole numbers
3. CMinor units with an ISO currency codeCorrect answer
4. DFloats without currency

Why: Never mix currencies in a sum.

1. ACard fees to customers
2. BData to the merchant
3. CFraud liability to the issuerCorrect answer
4. DSettlement time

Why: Strong customer authentication.

1. AApply them blindly
2. BDelete them
3. CReturn 500
4. DCheck current state before applyingCorrect answer

Why: State machines reject invalid transitions.

1. AClearing caches
2. BManual emails
3. CReconciliation against the providerCorrect answer
4. DRestarting servers

Why: Compare records regularly.

1. ABe deletable
2. BUse floating-point amounts
3. CSum to zero across accountsCorrect answer
4. DUpdate balances in place

Why: Balanced entries make every movement traceable.

1. AUnknown until confirmedCorrect answer
2. BFailed immediately
3. CSuccessful
4. DRefunded

Why: It may have succeeded, so retrying blindly risks a double charge.

1. AFrontend and backend versions
2. BLogs with metrics
3. CYour ledger with the provider's settlement reportsCorrect answer
4. DTwo database replicas

Why: It finds payments that one side has and the other does not, or with different amounts.

1. ARetrying failed subscription charges with noticesCorrect answer
2. BCard tokenisation
3. CFraud scoring
4. DPayouts

Why: With grace periods for customers.

1. ABigger servers
2. BLogging card numbers
3. CRate limits and CAPTCHACorrect answer
4. DLonger sessions

Why: Attackers try many cards quickly.

1. ANothing
2. BA new payment
3. CEvidence like receipts and delivery proofCorrect answer
4. DThe card's PIN

Why: Submit before the deadline.

1. ATo avoid testing
2. BIt is faster always
3. CStricter security and smaller compliance scopeCorrect answer
4. DTo use more servers

Why: Change control matters.

1. ACorrelation IDs
2. BState transitions
3. CFull card numbersCorrect answer
4. DEvent IDs

Why: Logs must not hold card data.

1. ASkipping tests
2. BProvider test cards in test modeCorrect answer
3. CReal customer cards
4. DProduction traffic

Why: Test mode simulates outcomes.

1. ABefore the customer pays
2. BIn cash
3. CThrough payouts after holds, from the ledgerCorrect answer
4. DDirectly by customers' cards

Why: The ledger tracks each share.

1. ANeed authorisation then capture
2. BUse card numbers
3. CSettle after a month
4. DMove money between bank accounts in real timeCorrect answer

Why: Status checks handle pending states.

1. ABy deleting the account
2. BBy changing the balance column
3. CWith new reversing entriesCorrect answer
4. DBy editing old rows

Why: History stays intact and auditable.

1. ALogs with metrics
2. BPrices with competitors
3. CYour records with the provider's settlement reportCorrect answer
4. DTwo copies of the frontend

Why: Mismatches reveal missed webhooks and fee errors.

1. ADoubled
2. BLeft as originally calculatedCorrect answer
3. CRecomputed with the new rate
4. DRemoved

Why: Invoices are legal records of what was charged.

1. AStores product images
2. BTalks to card networks and banksCorrect answer
3. CDesigns checkout pages only
4. DHosts websites

Why: The gateway collects details.

1. ANumber of products
2. BCPU usage
3. CAuthorisation success rate by issuerCorrect answer
4. DPage views

Why: Alert on sudden drops.

1. AShow success
2. BHide the order
3. CAvoid asking the user to pay againCorrect answer
4. DAsk to pay again

Why: Double payments come from retries.

1. AThe captured amountCorrect answer
2. BThe cart size
3. CThe user's age
4. DThe tax rate only

Why: Never refund more than captured.

1. AThe card's CVV stored
2. BNo consent
3. CA new card each month
4. DThe customer's consent mandateCorrect answer

Why: CVV must never be stored.

1. AOnly the rate
2. BNothing extra
3. CBoth amounts and the exchange rate usedCorrect answer
4. DOnly the converted amount

Why: Refunds and accounting need the original figures.