Payments and Third-Party Integrations

At 4+ years, interviewers do not ask "how do you take a payment?". They ask "what if the customer pays and then closes the tab?", "what if the same webhook arrives twice?" and "why did the upload work on your laptop but fail in the browser?". This lesson gives you the model behind those answers, and then 19 questions with spoken answers.

I checked the code in this lesson in October 2026 with Stripe SDK 23 (pinned API version 2026-09-30.endive), AWS SDK for JavaScript v3 (3.1148), Nodemailer 10, Resend SDK 6, Opossum 10 and Express 5. The webhook handler, the idempotency retry, the retry-and-breaker client and the DKIM signing were run for real. The S3 URLs were built (not sent) with dummy keys. Several claims about Stripe, AWS and the big mailbox providers come from their documentation, which I could not open in my work environment. I mark those with "per the provider's docs", so double-check the exact numbers before you quote them.

Related lessons: the full design of file uploads is in Design Problems, Lesson 04. The full design of idempotent payments (key table, state machine, reconciliation) is in Design Problems, Lesson 07. The basic Stripe webhook handler is in Libraries, Lesson 13, and a debugging view of duplicate webhooks is in Debugging, Lesson 11. This lesson does not repeat them. It adds what is around them.

Words used in this lesson

• A payment provider is a company (for example Stripe) that talks to the card networks and banks for you and moves the money.
• A webhook is an HTTP request that the provider sends to your server when something happens, such as "this payment succeeded". It is like a delivery company ringing your door bell, instead of you walking to the depot every minute.
• Idempotent means that doing the same thing many times has the same result as doing it once. An idempotency key is a unique value you send with a request so the provider can recognise a repeat and not do the work twice.
• PCI DSS is a security rulebook from the card industry for anyone who handles card numbers. PCI scope is the part of your systems that touches card data, and every part in scope must follow the rules.
• SCA (Strong Customer Authentication) is a European and UK rule that the buyer must prove who they are with two of three things (something they know, have or are). 3D Secure (3DS) is the card-network method that does this, usually with a bank pop-up or a phone approval.
• A presigned URL is a normal storage URL with a signature and an expiry time inside it. Whoever holds it can do one named action (for example upload one file) until it expires, without having any account keys.
• SPF, DKIM and DMARC are three DNS-based checks that prove an email really comes from your domain. They are explained in the email section.
• A circuit breaker is a small piece of code that stops calling a failing service for a while, like the fuse in your house that cuts power when something is wrong.
• A sandbox is a safe copy of a service with fake money or fake mail, used for testing.

Stripe

Checkout or Payment Intents?

Stripe has two main ways to take a one-time payment. A Checkout Session is a payment page that Stripe builds and hosts for you (or embeds). A PaymentIntent is Stripe's record of one payment attempt. You can use it with your own form built from Stripe's Elements (card fields that Stripe draws inside an iframe on your page).

Checkout can also be embedded in your page, not only opened as a redirect. Under the hood a Checkout Session creates a PaymentIntent for you. Difference in one line: Checkout is a finished payment page, a PaymentIntent is the engine that you wrap in your own page.

The server code for each is short and it type-checks against the SDK:

const session = await stripe.checkout.sessions.create(  {    mode: 'payment', // or 'subscription' or 'setup' (save a card, no charge)    line_items: [{ price: priceId, quantity: 1 }],    client_reference_id: orderId, // comes back on the webhook    success_url: 'https://app.example.com/orders/done?session_id={CHECKOUT_SESSION_ID}',    cancel_url: 'https://app.example.com/cart',  },  { idempotencyKey: `checkout:${orderId}` },)// redirect the browser to session.urlconst pi = await stripe.paymentIntents.create(  { amount: 1999, currency: 'usd', automatic_payment_methods: { enabled: true } },  { idempotencyKey: `pi:${orderId}` },)// send pi.client_secret to the browser (never the secret API key)

Amounts are integers in the smallest unit (1999 means 19.99 USD). Some currencies, such as JPY, have no minor unit, so 1999 means 1999 yen. Never use floats for money.

The golden rule: the webhook is the truth

When the buyer pays, two things happen at the same time. The browser lands on your success_url. Stripe sends a webhook to your server. They are not in a fixed order, and the first one can be missing (the buyer may close the tab, or lose the network). So:

For Checkout, the event is checkout.session.completed. For some slow payment methods (bank debits, for example) the session can complete before the money arrives. So check session.payment_status === 'paid', and also handle checkout.session.async_payment_succeeded and checkout.session.async_payment_failed. For a PaymentIntent, the events are payment_intent.succeeded and payment_intent.payment_failed.

A PaymentIntent moves through these statuses (taken from the SDK types):

Card data and PCI scope

The safe design is: card numbers never touch your server. The card fields are drawn by Stripe inside an iframe (or on Stripe's own page), and the browser sends the number straight to Stripe. Your server only sees a token or an id (a pm_... payment method, a pi_... intent). That keeps your PCI scope small. With Checkout or Elements the paperwork you owe is normally the shortest self-assessment form (called SAQ A); check the exact form with your provider and your bank.

• Never log request bodies on payment routes without removing card fields. Never put a card number in a URL, an analytics event or an error report.
• Never store the CVC (the 3 or 4 digit code), even encrypted. The rules forbid it.
• If you build your own card input and post the number to your own API, you move your whole backend into scope. That is the mistake the iframe design prevents.
• Store only what you need: the Stripe customer id, the payment method id, the last four digits and the brand for display.

SCA and 3D Secure

In Europe and the UK, most online card payments need SCA. In practice, Stripe asks the bank, and the bank may ask the buyer to approve in their banking app. For you this shows up as a PaymentIntent in requires_action. If you use Checkout, or Stripe.js confirmPayment, the pop-up is handled for you. Two parts matter for your design:

1. Customer present (they are on your page): Stripe.js shows the pop-up. Nothing special to build.
2. Customer absent (a subscription renewal, an automatic top-up): the bank may demand authentication but nobody is there. The payment fails with an "authentication required" result. You must email the buyer a link to come back and finish. For subscriptions, Stripe sends invoice.payment_action_required and can send the email for you (a setting in the dashboard). To reduce this, save the card with the right setup when it is first used (setup_future_usage on the PaymentIntent, or mode: 'setup'), so the bank knows the later payments are agreed.

For testing, Stripe gives test cards: 4242 4242 4242 4242 always succeeds, and 4000 0025 0000 3155 asks for 3DS (per Stripe's test docs).

Idempotency keys with Stripe

The long design is in Design Problems, Lesson 07. The Stripe-specific facts are these:

• You pass the key as an option: stripe.paymentIntents.create(params, { idempotencyKey }). The SDK sends it as the Idempotency-Key header.
• The SDK already adds a key for you on every POST (a random stripe-node-retry-... value), so its own automatic retries are safe. I checked this with a fake server that answers 500 once: the SDK called twice and the key was the same both times.
• That automatic key is new for each of your calls. It does not protect you if your own code retries, or your user clicks twice. For that you need a key that comes from your business fact, for example checkout:${orderId}. The same order always gives the same key.
• The SDK defaults, from its source: timeout 80 seconds, 2 automatic retries (for connection errors, 409 conflicts and 5xx errors, and when Stripe's stripe-should-retry header says so), with exponential waiting.
• Stripe remembers a key only for a limited time (per its docs, keys can be removed after about 24 hours), and if you reuse a key with different parameters it returns an error, so keys are not a place to hide bugs.

Webhooks: signature, raw body, tolerance

The basic handler is in Libraries, Lesson 13. The points interviewers still push on:

• Why verify? Your endpoint is a public URL. Anyone can post "payment succeeded" to it. The signature proves that Stripe sent the exact bytes. Stripe signs timestamp + "." + raw body with a secret that is unique to each endpoint.
• Raw body. If express.json() parses the body first, the bytes change (spaces, key order) and the check fails. Use express.raw({ type: 'application/json' }) on this route only, and mount it before the global JSON parser. In Next.js Route Handlers, call await request.text(), not request.json().
• Tolerance. The SDK rejects an event whose timestamp is more than 300 seconds old (5 minutes). This stops someone from replaying a captured request later. In SDK 23 there is a gotcha: passing 0 as the tolerance now skips the time check completely, which is not what you want in production.
• One secret for each endpoint and each mode. The test endpoint and the live endpoint have different whsec_ secrets. "Works in test, fails in live" is usually the wrong secret.
• Retries by Stripe. If you do not answer with a 2xx in time, Stripe tries again for up to about three days in live mode, with growing waits (per its docs). A failing endpoint can be disabled after a long time of failing. So answer fast, and monitor the failures.
• Thin and snapshot events. The classic event carries a full copy of the object at that moment (a snapshot). Newer Stripe APIs also have "thin" events that carry only ids, so you fetch the object yourself. Both use the same ideas below: verify, dedupe, and prefer to read the current state.

Subscriptions, proration and the events that matter

A subscription is a promise to charge a customer every period. In Stripe each period makes an invoice, and the invoice makes a payment. The subscription status can be active, trialing, past_due, unpaid, canceled, incomplete, incomplete_expired or paused.

Proration means charging or crediting only for the part of the period that was actually used when a plan changes in the middle of the period. Example: a customer pays 30 USD per month on the 1st and upgrades to a 60 USD plan on day 16. They get a credit of about 15 USD for the unused half of the old plan and a charge of about 30 USD for the second half of the new plan.

The proration_behavior option on a subscription update decides what happens:

const sub = await stripe.subscriptions.retrieve(subId)await stripe.subscriptions.update(subId, {  items: [{ id: sub.items.data[0].id, price: newPriceId }], // change the item, do not add a second one  proration_behavior: 'always_invoice', // upgrade: charge the difference now})

The events a real app handles: checkout.session.completed (start), invoice.paid (give or extend access), invoice.payment_failed (tell the user, show a banner), invoice.payment_action_required (3DS needed), customer.subscription.updated (plan or status changed), customer.subscription.deleted (remove access) and customer.subscription.trial_will_end. For money problems also watch charge.refunded and charge.dispute.created (a chargeback, which is a buyer asking their bank to take the money back).

Dunning means the automatic process of retrying a failed renewal and emailing the customer. Stripe can retry failed payments on a schedule (a setting called Smart Retries or the retry rules). Do not build this yourself first.

Let the customer manage their own plan in the Customer Portal (a Stripe-hosted page) instead of building cancel and card-update screens.

S3 file uploads

The full upload design is in Design Problems, Lesson 04. Here are the questions around it.

Presigned URL or presigned POST?

Both let the browser upload straight to S3, so large files never pass through your server. Your server uses its own credentials to sign a short-lived permission.

I built both with dummy keys. The PUT URL has X-Amz-Expires=300 and X-Amz-SignedHeaders=host, and a PUT with a signed ContentLength adds content-length to the signed headers. The POST policy had ["content-length-range", 0, 5242880] and a starts-with rule on the content type, which S3 enforces itself. So if size limits matter, presigned POST is the stronger tool.

The maximum lifetime of a SigV4 presigned URL is 7 days (604800 seconds); the SDK throws an error for 604801. If you sign with temporary credentials (an IAM role), the URL can stop working earlier, when those credentials expire. Use short lifetimes (minutes) for uploads.

The checksum trap in the AWS SDK

Newer versions of AWS SDK v3 add a checksum to many requests by default. For a presigned upload this matters: when I signed a PutObjectCommand with the default client, the URL contained x-amz-checksum-crc32=AAAAAA== and x-amz-sdk-checksum-algorithm=CRC32. That value is the checksum of an empty body, calculated when the URL was made, long before any file exists. S3 can reject a real upload that does not match it. With requestChecksumCalculation: 'WHEN_REQUIRED' on the client, those two parameters were gone from the URL.

const s3 = new S3Client({ region: 'eu-west-1', requestChecksumCalculation: 'WHEN_REQUIRED' })const url = await getSignedUrl(  s3,  new PutObjectCommand({ Bucket, Key: `uploads/${userId}/${crypto.randomUUID()}`, ContentType: type, ContentLength: size }),  { expiresIn: 300 },)

Many tutorials from before this change do not show it. If someone says "my presigned PUT works with curl but fails with the SDK URL", look here first.

CORS: why the browser blocks the upload

CORS (cross-origin resource sharing) is a browser rule: a page from app.example.com may call another origin (bucket.s3.amazonaws.com) only if that server sends headers that allow it. A PUT with a Content-Type header triggers a preflight: the browser first sends an OPTIONS request to ask for permission. S3 answers it from the bucket's CORS configuration, which you must set:

{  "CORSRules": [{    "AllowedOrigins": ["https://app.example.com"],    "AllowedMethods": ["PUT", "GET"],    "AllowedHeaders": ["content-type"],    "ExposeHeaders": ["ETag"],    "MaxAgeSeconds": 3000  }]}

AllowedHeaders must list every header the browser sends. ExposeHeaders: ["ETag"] matters for multipart uploads, because JavaScript cannot read the ETag of each part unless the server exposes it. Do not use * as the origin in production. CORS only protects browsers. It does not stop curl, so it is not security by itself.

Multipart upload

A multipart upload splits one big file into parts that are uploaded separately (and in parallel), then joined. The S3 rules (per the AWS docs): each part is 5 MiB to 5 GiB (the last part may be smaller), up to 10,000 parts, and the whole object up to 5 TiB. A single PUT is limited to 5 GiB. The AWS SDK helper (@aws-sdk/lib-storage) has these defaults in its source: parts of at least 5 MB, 4 parts at the same time, a hard stop above 10,000 parts, and an automatic abort of the upload if it fails.

The browser flow:

1. Server: CreateMultipartUpload returns an UploadId.
2. Server: for each part, create a presigned UploadPart URL (it includes partNumber and uploadId). I generated these and checked both appear in the URL.
3. Browser: uploads each part (retry only that part), and collects the ETag of each.
4. Server: CompleteMultipartUpload with the list of part numbers and ETags.

For a 5 TiB file the part size must be at least about 525 MiB, because of the 10,000-part limit. Pick a part size such as 8 to 16 MiB for normal large files.

Virus scan, content checks, and the CDN

• Never trust the file name, the extension or the Content-Type header. The browser or attacker sets them. Check the first bytes of the file (the "magic bytes": a PNG starts with 89 50 4E 47 0D 0A 1A 0A). A Windows program starts with MZ. I wrote a ten-line sniffer and it told a PNG from a program.
• Scan with an antivirus engine (ClamAV is the common open-source choice). The pattern: the browser uploads into a private incoming prefix. A storage event triggers a worker that downloads, scans, and then moves the file to a clean prefix or deletes it. The database row stays pending until the scan passes. Nobody can download a pending file.
• Serve user files safely. An uploaded HTML or SVG file can run script in your site. Serve downloads from a separate domain, set the correct Content-Type, add X-Content-Type-Options: nosniff, and use Content-Disposition: attachment for anything that is not an image you have re-processed.
• CDN (content delivery network) is a set of servers close to users that cache your files. Put it in front of the bucket (for example CloudFront with an Origin Access Control, so the bucket itself stays private). Use file names that change when the content changes (a hash in the name) with a long Cache-Control, instead of paying for slow, partial cache invalidation. For private files use signed URLs or cookies from the CDN.

Transactional email

A transactional email is a message the system sends because of one user's action: a receipt, a password reset, an invitation. (Marketing email is a bulk message to many people. Keep them on separate sender addresses, because complaints about marketing damage the delivery of receipts.)

Which tool?

All of them need you to prove your domain, as below.

SPF, DKIM, DMARC

Anyone can type any "From" address. These three DNS records let the receiving server check.

Facts to know:

• DMARC passes only when SPF or DKIM passes and is aligned: the domain that passed must match the domain in the visible From address. A provider that signs with its own domain does not give you alignment, so you set up a custom DKIM domain.
• A DMARC p= policy is none (just watch and send reports), quarantine (send to spam) or reject (refuse). Start with none, read the rua reports, fix your senders, then move to quarantine and reject.
• SPF allows at most 10 DNS lookups (each include: costs at least one). Too many include: entries make SPF fail with a permanent error.
• Big mailbox providers (Gmail, Yahoo) now require SPF, DKIM and DMARC from senders of large volume (the commonly quoted line is 5,000 messages a day), one-click unsubscribe for marketing mail, and a low spam-complaint rate (they say to stay well under 0.3%). Check their current sender guidelines for exact rules.

I signed a message with Nodemailer's dkim option, published the public key in a fake DNS lookup, and verified it with a DKIM checker: it passed. The signature header is added by the sender, and the check fails if anyone changes the body afterwards.

const mailer = nodemailer.createTransport({  host: 'smtp.example.com', port: 587, secure: false, requireTLS: true, // STARTTLS on port 587  auth: { user: process.env.SMTP_USER, pass: process.env.SMTP_PASS },  pool: true, // reuse connections})await mailer.sendMail({ from: 'App <noreply@example.com>', to, subject, text, html })// Resend: HTTP API, and the second argument supports an idempotency keyawait resend.emails.send(  { from: 'App <noreply@example.com>', to: [to], subject, html },  { idempotencyKey: `welcome/${userId}` },)

Bounces, complaints and suppression

• Hard bounce: a permanent failure, such as "no such mailbox". Never send to that address again.
• Soft bounce: a temporary failure, such as a full mailbox. Retry a few times, then stop.
• Complaint: the user pressed "report spam". Stop sending to that address at once.

Providers tell you about these by webhook (SES uses notifications through other AWS services; Resend has events such as email.bounced, email.complained and email.delivery_delayed, and signs them in the Standard Webhooks style, so you verify them before you trust them). Your job: receive the event, write the address to a suppression list in your own database, and check that list before every send. Repeated sends to dead addresses ruin your reputation, and then even good mail goes to spam.

Send email from a queue, not inside the web request. A slow mail server then cannot slow your checkout, and a retry does not double-send if you use a job id or an idempotency key. See the queue notes in Libraries, Lesson 13.

Integration patterns: timeouts, retries, breakers, limits

Every call to an outside service needs the same small set of protections.

I wrote a small client with all of these and ran it against a fake provider:

async function callWithRetry(url: string, { retries = 3, timeoutMs = 500, baseMs = 20, capMs = 400 } = {}) {  for (let attempt = 0; ; attempt++) {    try {      const res = await fetch(url, { signal: AbortSignal.timeout(timeoutMs) }) // 1. a timeout on every call      if (res.ok) return res.json()      if (!RETRYABLE.has(res.status) || attempt === retries) throw Object.assign(new Error(`HTTP ${res.status}`), { status: res.status })      const ra = Number(res.headers.get('retry-after'))                          // 2. obey the provider's hint      await sleep(res.headers.has('retry-after') && Number.isFinite(ra) ? ra * 1000        : Math.random() * Math.min(capMs, baseMs * 2 ** attempt))                // 3. full jitter    } catch (e: any) {      if (e.status || attempt === retries) throw e      await sleep(Math.random() * Math.min(capMs, baseMs * 2 ** attempt))        // network error or timeout    }  }}

Results from the run: a provider that answered 429 twice and then 200 succeeded on the third call. A provider that never answered ended with a TimeoutError after about 200 ms (two tries of 100 ms). Full jitter means the wait is a random number between zero and the current limit, so many clients do not all retry at the same moment.

For the breaker I used the Opossum library. Its defaults, from its source, are a 10-second call timeout, a 50% error threshold and a 30-second wait before it tries again. I set small values to see it work:

const breaker = new CircuitBreaker(() => callWithRetry(url, { retries: 0 }),  { timeout: 300, errorThresholdPercentage: 50, volumeThreshold: 3, resetTimeout: 200 })breaker.fallback(() => ({ degraded: true }))

A provider that always answered 503: the first three calls reached it, the breaker opened, and calls 4 to 6 returned the fallback without touching the provider (the hit counter stayed at 3). After the reset time it went half-open, one trial call succeeded, and it closed. The states are closed (normal), open (blocking) and half-open (testing with one call).

Sandbox versus live, and secrets

• Use the provider's test or sandbox mode in development and in CI. It has its own keys, its own data and its own webhook endpoints and secrets. Stripe also offers separate sandboxes (full test copies of an account) besides test mode.
• Keep the mode in config, not in code. One setting (STRIPE_SECRET_KEY) chooses it. Fail at start-up if a production build has a sk_test_ key, or if a development build has a sk_live_ key.
• Secret keys stay on the server. Stripe's publishable key (pk_...) is meant for the browser. The secret key (sk_...) and the webhook secret (whsec_...) are not. In Next.js any variable that starts with NEXT_PUBLIC_ is sent to the browser.
• Use restricted keys (keys with only the permissions one service needs) where the provider offers them. Give each environment and each service its own key so you can rotate one without breaking the others.
• Store secrets in the platform's secret store or environment settings, never in Git. Turn on secret scanning for the repository. If a key leaks, rotate first, then investigate.
• Test webhooks locally with the provider's tool (the Stripe CLI forwards events to your machine and gives a local whsec_ secret).

The design: duplicate and out-of-order webhooks

The problem: the provider sends each event at least once and does not promise the order (per Stripe's docs). Also, when your endpoint is slow or down, it retries. So your handler will see duplicates and old events after new ones. The design has three layers.

1. Verify the signature on the raw body.
2. Deduplicate by event id, in the same database transaction as the business change. Then a crash rolls back both, and the retry starts clean.
3. Order safely. Choose one of three strategies:

"Fetch the truth" is the safest, because the result no longer depends on the order of events at all. Many teams combine it with dedupe. Here is the compare-timestamps version. I ran it against signed requests:

// One transaction: claim the event and change the data together.function handle(event: Stripe.Event) {  db.exec('BEGIN')  try {    const claim = db.prepare('INSERT OR IGNORE INTO processed_events (event_id, type) VALUES (?, ?)')      .run(event.id, event.type)    if (claim.changes === 0) { db.exec('ROLLBACK'); return 'duplicate' }    if (event.type.startsWith('customer.subscription.')) {      const sub = event.data.object as Stripe.Subscription      db.prepare(`        INSERT INTO subscriptions (id, status, event_created) VALUES (?, ?, ?)        ON CONFLICT(id) DO UPDATE SET status = excluded.status, event_created = excluded.event_created        WHERE excluded.event_created > subscriptions.event_created      `).run(sub.id, sub.status, event.created)   // an older event changes nothing    }    db.exec('COMMIT')    return 'processed'  } catch (e) { db.exec('ROLLBACK'); throw e }}

Test sequence and results: event 1 (created, time 100) gave processed. Event 3 (active, time 300) arrived early and gave processed. Event 2 (past_due, time 200) arrived late and gave processed, but the row stayed active with time 300, because the older event changed nothing. Event 3 sent again gave duplicate. A request with a bad signature got 400. The table ended with one row (active) and 3 processed event ids.

In Postgres the same idea is INSERT ... ON CONFLICT DO NOTHING and checking the row count. A second request with the same id waits for the first transaction to finish, so two parallel copies of one event cannot both pass.

Side effects that cannot be rolled back, such as sending an email or calling another API, do not belong inside the transaction. Write a row to an outbox table (a table of "things to do") in the same transaction, and let a worker do it afterwards with its own idempotency key. If the work is slow, store the verified raw event in an inbox table with status received, answer 200 at once, and process it in a worker. Reply to the provider in well under a few seconds either way.

Finally, run a reconciliation job (compare your records with the provider's list of payments or subscriptions every night). It repairs events that were lost for any reason, including the long outage that exceeded the retry window.

Common mistakes

• Marking an order paid on the success page, or from client input, instead of the verified webhook.
• Parsing the webhook body as JSON before verifying it.
• Using the same webhook secret (or the same keys) for test and live.
• Letting the client choose the S3 key or the price. The client sends an id, the server looks up the price.
• Retrying a charge after a timeout without an idempotency key.
• Presigned URLs that live for days, or are logged.
• Forgetting to abort unfinished multipart uploads.
• Sending email in the request path, and never handling bounces.
• Calling a provider with no timeout.
• Putting a secret key in NEXT_PUBLIC_ or in a mobile app.
• Floats for money.

Interview questions

Key takeaways

• The webhook decides, the browser only displays. Verify on the raw body, fulfil from the event.
• Every step must be safe to repeat. Business-based idempotency keys, an event-id table in the same transaction, and "fetch the current state" when order matters.
• Checkout first, PaymentIntents when you need control. Keep card data in Stripe's iframe to keep PCI scope small. Plan for 3DS on renewals.
• Subscriptions: change the item, choose proration_behavior on purpose, handle invoice.* and customer.subscription.*, and reconcile every night.
• Uploads: presigned POST when limits matter, short expiry, server-made keys, correct CORS (with ETag exposed), requestChecksumCalculation: 'WHEN_REQUIRED' for presigned PUT, abort old multipart uploads, scan before serving.
• Email: SPF, DKIM and DMARC aligned to your From domain; split marketing from transactional; suppress hard bounces and complaints; send from a queue.
• Outside calls: timeout, jittered retry (one layer), circuit breaker, bulkheads, obey Retry-After.
• Secrets: one set per environment, restricted keys, server only, rotate first when leaked.

What's next

To practise, re-read the two design lessons linked at the top (file uploads and idempotent payments). Then explain out loud, without notes, what happens to an order when the same webhook arrives three times in the wrong order.