Dodo Payments builds webhooks that never fail with Restate

Dodo Payments is a global Merchant-of-Record platform that lets AI, SaaS and digital businesses sell in 150+ countries. They use Restate to power their webhook infrastructure, ensuring merchants never miss critical payment notifications.

Before Restate: Architecture & Challenge

At Dodo Payments, webhooks are how merchants know when money moves. A customer pays for a subscription, Dodo fires a payment.succeeded webhook, and the merchant's system provisions access. A missed webhook means a customer paid but got nothing in return.

The team was losing about 0.3% of their webhooks. At 100,000 payments per day, that's 300 customers with failed experiences and 300 support tickets.

The core problem was that in-process webhook delivery has no durability guarantees. The application holds the webhook in memory, and if that process dies for any reason (deployments, OOM events, network partitions,…), the webhook dies with it. No retry, no trace it ever existed.

The failure was invisible by design - there was simply nothing to observe. The payment succeeded, the database committed, but the notification vanished.

-- Ayush Agarwal, Co-founder, Dodo Payments

Technical Challenges:

• Process failures kills in-flight webhook requests during deployments
• Retry queues stored in memory, lost on restarts
• Ordering violations when retries delivered events out of sequence
• No audit trail for lost webhooks

Why Restate?

Dodo Payments needed an architecture that would make processing ephemeral webhook events durable and idempotent across crashes and process failures. They picked Restate to make this possible via the following features:

• Kafka integration: Restate let them subscribe to a Kafka topic where the webhook events end up and process them durably in parallel.
• Durable Execution: Every function invocation is logged to a persistent journal before execution. If a process crashes mid-execution, Restate replays the journal and resumes exactly where it left off.

  We went from losing ~300 webhooks per 100,000 payments and a support nightmare to losing essentially none. The remaining failures are merchant endpoint issues, not ours.

  -- Ayush Agarwal, Co-founder, Dodo Payments

• Durable retries: Unlike in-memory retry queues, Restate's retry schedule is written to the journal immediately.
• Idempotency: Restate’s Durable Execution model makes it easy to generate idempotency keys that are stable across crashes and retries.

The Results

Dodo Payments now uses Restate as part of a five-layer architecture for webhook reliability:

• PostgreSQL Triggers: Atomic event capture
• Sequin: For change data capture from PostgreSQL
• Kafka: Durable messaging with 7-day replay capability
• Restate: Workflows with durable execution
• Svix: Last-mile webhook delivery

After deploying this architecture:

• Reliability: Went from ~300 lost webhooks per 100,000 payments to zero

• Latency: P50 latency dropped to under 500ms from event to delivery

  Restate is optimized for low-latency. The journaling overhead is minimal for simple workflows. And it enables parallel execution. Events flow through the pipeline without blocking on each other.

  For merchants building real-time experiences, like instantly provisioning access after payment, this near-real-time delivery is critical. A webhook that arrives in 500ms feels instantaneous. One that arrives in 2+ seconds creates noticeable lag in the user experience.

  -- Ayush Agarwal, Co-founder, Dodo Payments

• Observability: Complete audit trail through every layer.

  We can now prove webhooks were delivered. Every event has an audit trail through Sequin, Kafka, Restate, and Svix. When a merchant says "I didn’t get the webhook", we can show them exactly what happened.

  -- Ayush Agarwal, Co-founder, Dodo Payments

Read more in their architecture deep dive.