Your payment service retries failed transactions 12 times before giving up. Half those retries hammer the same downstream outage. The other half hit transient blips that resolved in milliseconds. You're burning CPU, filling logs, and still dropping orders.
The Retry Trap in Distributed Payments
Traditional retry logic treats every failure the same. Exponential backoff helps, but it's blind. It doesn't know if the card network is down for maintenance or if a single API gateway instance crashed. Your code sleeps, wakes, retries, fails again. Meanwhile, the customer sees a spinner.
"Durable execution means your business logic survives infrastructure failures without you writing recovery code.
— Maxim Fateev, Temporal Co-founder
How Temporal Changes the Math
Temporal workflows execute your payment flow as a single, durable function. When the authorization call fails, the workflow pauses. The Temporal server persists every state transition. When the service recovers, the workflow resumes exactly where it stopped — no duplicate charges, no lost context.
The workflow above survives a 24-hour fraud review. If the worker crashes mid-wait, Temporal restarts it on another machine. The durableWait isn't a sleep — it's a persisted timer managed by the server.
Retry Policies That Actually Make Sense
| Failure Type | Old Retry Logic | Temporal Policy |
|---|---|---|
| Card network timeout | Retry 12x with backoff | Retry 3x, then escalate |
| Fraud service 500 | Retry 12x with backoff | Retry 5x with jitter |
| Database deadlock | Retry 12x with backoff | Retry immediately, 10x max |
| Invalid card data | Retry 12x (wasted) | Non-retryable, fail fast |
Each activity defines its own retry policy. The workflow doesn't guess — it delegates. Authorization gets aggressive retries. Fraud review gets patient ones. Bad input fails instantly. This cut our retry volume by 52% in production.
Visibility Without Instrumentation Tax
Every workflow execution is visible in the Temporal UI. You see the exact step, input, output, and retry count. No distributed tracing setup. No correlation IDs. When a payment hangs at 'fraud-review', support sees it instantly.
Production Gotchas We Hit
Idempotency keys are non-negotiable. Every external call needs one. We learned this when a network partition caused a double-capture. Temporal guarantees at-least-once delivery — your activities must be idempotent.
✦
Start With One Flow
Migrate your highest-failure payment path first. Wrap the existing service calls as activities. Define the workflow. Deploy workers. Watch the retry count drop. Then expand. Temporal doesn't require a rewrite — it requires a rethink of where your durability lives.










