Stripe

What they grade on

• Correctness of money movement — idempotency is non-negotiable
• Distributed-transaction reasoning (Saga, outbox, CDC)
• Handling of external network failures (payment networks, banks)
• Auditability and reconciliation from day one
• API design maturity — versioning, error semantics, retry safety

Deal breakers

• No idempotency-key discussion in a money-movement design
• Skipping the ledger — treating payments as CRUD
• Ignoring how partner outages (Visa, banks) affect availability
• No audit trail — a Stripe design without immutable event log fails

Super helpful signals

• Discussing idempotency keys explicitly + how they persist across retries
• Naming the reconciliation loop — daily settlement, discrepancy detection
• Bringing up the Stripe Sigma / event-log architecture as a real pattern
• Talking about ISO 8583 or bank-message-level details for depth

Delivery advice

• Say 'idempotent' in the first 5 minutes.
• Draw the ledger explicitly, even if simplified — money moves are rows in a ledger.
• Talk about reconciliation and audit trails.
• Discuss handling external partner outages (Visa/Mastercard/banks) explicitly.
• Reason about API versioning + retry semantics — Stripe has famous public API stability.

Red flags to avoid

• No idempotency mention
• No ledger discussion
• Ignoring reconciliation
• Assuming synchronous global-DB write is fine for money