PayPal Software Engineer Case Interview: Design a Multi‑Currency, Risk‑Aware Payments Service

This case mirrors PayPal’s real-world product and engineering challenges and is used to assess system design depth, practical coding judgment, and payments domain fluency. You will design a backend service that powers a core PayPal/Venmo money movement flow (e.g., creating and executing an Order/Payment Intent with authorization, capture, settlement, refund, and dispute handling) across multiple regions and currencies. Focus areas PayPal interviewers typically probe: - Requirements and scope: Clarify user journeys (consumer checkout vs. P2P), merchant needs, and compliance constraints (PCI DSS scope reduction via tokenization, KYC/AML considerations, data retention). Define success metrics (auth approval rate, p95/p99 latency, fraud loss bps, availability SLOs like 99.95%). - API and contract design: Propose external and internal APIs consistent with PayPal’s style (e.g., Orders/Payment Intent model). Include Idempotency-Key, OAuth 2.0 access tokens, HMAC request signing, versioning strategy, and error taxonomy. Provide sample request/response for POST /payments and GET /payments/{id} with state transitions (CREATED → AUTHORIZED → CAPTURED → SETTLED → REFUNDED/REVERSED). - Data and consistency model: Double-entry ledgering for funds with strong consistency at balance boundaries, eventual consistency for downstream analytics. Sharding strategy (e.g., by account or ledger key), optimistic locking, and handling cross-shard transfers (saga/2PC trade-offs). Currency handling (FX rates, rounding rules, hold amounts, partial captures) aligned to ~200 markets and ~100 currencies. Auditability and immutability requirements. - Risk and fraud: Real-time risk scoring in the authorization path (feature extraction like device fingerprint, velocity, chargeback history), decisions (approve/decline/review), async queues for manual review, and feedback loops. Discuss latency budgets and safe fallbacks when the risk service degrades. - Scalability and reliability: High-throughput, low-latency design using event-driven patterns (e.g., Kafka) with exactly-once or effectively-once guarantees via idempotency keys, deduping, and the transactional outbox. Back-pressure, rate limiting, retries with exponential backoff and jitter, circuit breakers, bulkheads, and graceful degradation of non-critical paths (e.g., deferred receipts). Multi-region active-active, data residency, failover, and blast-radius reduction. - Security and privacy: Tokenization of payment instruments (via Braintree/Vault concepts), encryption in transit/at rest, secrets management, PII minimization, and access controls. Threat modeling common payment attacks (replay, tampering) and mitigations. - Operability and culture: Define SLOs/error budgets, dashboards, distributed tracing with correlation/trace IDs, structured logging, and on-call readiness (runbooks, alarms). PayPal interviewers value pragmatic trade-offs, clear communication, and customer-first thinking—expect “why this over that?” follow-ups and requests for production-ready details. - Testing and rollout: Contract tests for partner integrations, canary/blue-green, schema evolution without downtime, migration/backfill strategies, and recovery from partial failures (e.g., auth success but capture failure). What to deliver during the session: a concise architecture (services, data stores, queues), key API shapes and state machine, data model for core entities (User/Account, Instrument, PaymentIntent/Order, Authorization, Capture, Refund, Dispute, LedgerEntry), SLIs/SLOs, and a failure-mode walkthrough. Interviewers often ask for a brief deep dive (e.g., idempotency, ledger correctness, or FX handling) and may request pseudocode for a critical path (e.g., CreatePayment with idempotency and outbox).