Payment Webhook System

Stripe's "Payment Webhook System" interview question focuses on designing a scalable, secure system to handle real-time payment event notifications, often tagged with data engineering, distributed systems, webhooks, security, backend reliability, and infrastructure challenges.

Problem Statement

Candidates must architect a webhook system like Stripe's that reliably delivers payment events (e.g., payment_intent.succeeded, invoice.payment_failed) from Stripe's backend to merchant servers. Key requirements include handling retries for failed deliveries, signature verification for security, idempotency to avoid duplicate processing, scalability for millions of events daily, and fault tolerance across distributed failures. The system processes asynchronous events from external payment networks while ensuring PCI compliance, auditability, and no data loss.[1][2][4]

Core Components

• Event Generation: Stripe triggers events on payment state changes (e.g., authorized, captured, failed).
• Delivery Layer: HTTP POST to merchant endpoints with JSON payloads; retries on 5xx errors or timeouts (up to 3 attempts over days).[1]
• Security: HMAC signatures in Stripe-Signature header; merchants verify using shared secret.[1]
• Idempotency: Events include unique IDs; merchants deduplicate via database checks.[5]
• Queueing: Kafka or similar for buffering high-volume events (10k+ TPS); sharding by merchant ID.[2]

Input/Output Examples

No official full examples exist publicly, but Stripe docs provide standard formats:

Input Payload Example (payment_intent.succeeded): { "id": "evt_1ABC123...", "object": "event", "type": "payment_intent.succeeded", "data": { "object": { "id": "pi_123...", "amount": 2000, "status": "succeeded" } } } Header: Stripe-Signature: <sig1>,<sig2> v1,...[1]

Expected Output: HTTP 200 OK from endpoint; Stripe marks as delivered. Failures trigger retries.[9][1]

Constraints

• Scale: 10,000+ TPS; horizontal scaling with read replicas and edge caching.[10][2]
• Reliability: At-least-once delivery; handle duplicates, network partitions, TLS errors.[9][1]
• Latency: <5s end-to-end; async processing for ML fraud checks.[10]
• Security/Compliance: Never store card data on merchant servers; immutable audit logs; PCI-DSS.[6][2]
• Edge Cases: Out-of-order events (e.g., payment_failed before invoice.created); zombie retries.[5]