The success screen is only one view

A customer can complete a payment and close the browser before returning to your site. A browser redirect is useful feedback, but it should not be the sole authority for deciding whether an order can move forward.

A webhook is a server-to-server notification about an event. Stripe documents delivery retries, duplicate events and delivery that may arrive out of order. Its documentation also describes signature verification. Those properties mean the receiver must be designed for more than one ideal request.

Define what payment means for this workflow

Before choosing event handlers, agree on the business states. Does the next step require a completed payment, an authorized amount, a deposit or a separate review? Map the provider’s relevant states to the business decision explicitly.

Keep the order identity distinct from the provider’s payment identity. One order may involve a failed attempt followed by another attempt. A new attempt should not accidentally become a second order, and a refund should not be confused with an ordinary fulfilment update.

Separate accepting the event from doing the work

A useful receiving path verifies the sender, records the event durably, then lets background work process the relevant transition. Acknowledge only after the work is safely retained under your chosen design. If it cannot be retained, expose a recoverable failure rather than silently discarding it.

Keep receipt, processing and side-effect status separate. “The endpoint returned success” is different from “the order was updated” and “the customer received a notification.” That distinction gives both engineers and operators a place to investigate.

  • Validate the event with the provider’s supported verification mechanism.
  • Connect it to the expected business and provider records.
  • Retain a durable processing result and useful diagnostic context.
  • Only allow transitions consistent with the business rule.
  • Schedule communication separately from the authoritative payment state.

Make repeated delivery safe

Idempotency means that repeating an operation does not repeat its intended effect. Design both the event receipt and the business action around that property. An event record alone is not enough if a worker crashes after creating a fulfilment task but before marking the event processed.

Use a stable identity and an appropriate database constraint or transactional boundary for the action that must happen once. Two workers should not both decide they are the first. For external side effects, use the provider’s idempotency facilities where supported or a recorded delivery task with a deliberate retry policy.

For an illustrative order flow, create one fulfilment instruction for the relevant confirmed transition. A retry can recover an interrupted attempt without issuing the same instruction twice.

Give operators a reconciliation path

An exception view should identify records whose payment and business states need checking. It should show what was received, what the system attempted and why work stopped. Restrict corrective actions to appropriate roles and record the reason for an override.

Test duplicates, reversed arrival order, unavailable storage, interrupted workers and notification failures. Include a scenario where payment is confirmed but fulfilment must remain on hold. A payment integration is useful when its failure behavior is as understandable as its success path.