A secure payment flow

System design scenarios Senior Swift 5.9+ iOS 17+ Reviewed By Alok Singh

Order the steps

Order the payment steps.

  • The server validates and charges through the provider
  • The app sends the request over pinned TLS with an idempotency key
  • The app shows the result, retrying with the same key if the response was lost
  • The user confirms, and Face ID releases the Keychain-protected token
Hint 1 of 1

Authenticate, send, charge, confirm.

Choose an answer, then open Show answer below to check it.

Show answer

Answer: D B A C

  1. The user confirms, and Face ID releases the Keychain-protected token Biometrics gate access to the credential.
  2. The app sends the request over pinned TLS with an idempotency key Secure transport and safe retries.
  3. The server validates and charges through the provider The server is the authority.
  4. The app shows the result, retrying with the same key if the response was lost Users get a clear outcome with no double charge.

30-second answer

Keep payment credentials out of the app where possible: use Apple Pay or the payment provider's tokenisation SDK. Protect any stored token in the Keychain with biometric access control, so Face ID releases it. Send requests over TLS with public key pinning and an idempotency key, let the server validate and charge, and show a clear result, retrying safely with the same key.

Practise saying it · 60 s. No recording, just a timer

Design a secure payment flow.

Say your answer out loud, then check which of these points you covered:

  • Tokenisation
  • Biometric Keychain
  • Pinning + idempotency
  • Server authority

Deep dive

Never store card numbers on the device.

Apple Pay tokens are single-use and device-bound.

Use App Attest to prove the request comes from your app.

Log payment events without sensitive data.

Common mistakes

  • Charging on the client's say-so.
  • Retrying payments without idempotency keys.

Senior take & follow-ups

Seniors keep secrets off the device and make the server authoritative.

Follow-up questions

Think of your answer first, then open the hint.

  1. Why an idempotency key?

    Show hint

    A retry after a timeout mustn't charge twice.

  2. Who decides the payment succeeded?

    Show hint

    The server, after the provider confirms.

Related questions

Suggest a fix if something here is wrong or out of date.