Do not accept an event-driven integration solely because one notification creates one record in a demonstration. Ask what happens when the notification arrives twice, an older update arrives after a newer one, or an expected notification never arrives. The goal is controlled business outcomes with evidence and recovery ownership, not an unqualified promise that nothing can ever be lost.
This guide addresses delivery and recovery after the interface fields are agreed. API Integration & Development includes error handling, but the provider’s delivery behavior and retry limits must be verified against current documentation and the actual account configuration.
Three failure classes require different decisions
Duplication can mean receiving the same notification again or receiving a different notification that causes the same business effect. A delayed event arrives after the underlying work has moved on. An operationally missing outcome occurs when the destination has not produced a result that the source says is due; the cause may be delivery, processing or invalid data.
Stripe’s webhook documentation states that events may repeat and arrive out of order. That demonstrates why provider behavior matters; it does not establish that every interface follows Stripe’s policies. Do not copy another platform’s retry periods or guarantees into the contract.
Before taking business action, verify the event source using the provider’s documented mechanism, including signature checks where required. The linked Stripe guidance requires source verification for its events; select each integration’s mechanism from its own provider documentation.
Identify the event and the business operation separately. Deduplicating one event identifier may not prevent two jobs if distinct events describe the same action. Conversely, ignoring every later event carrying one order identifier may discard a legitimate update.
Worked hypothetical: a paid order and a late update
Imagine test order O-71 becomes ready for fulfillment after payment confirmation. Event E-100 arrives and creates one preparation task. The sender repeats the same event because it did not receive the acknowledgement. The required outcome remains one task, while the repeated receipt is recorded without repeating its effect.
An older update then arrives describing the order as awaiting payment. Arrival time alone should not send the order back to an earlier business state. The team agrees how to establish the authoritative state, perhaps by checking the current source record or using a reliable version value if the actual interface provides one.
Finally, the source shows another ready order, O-72, with no corresponding destination task. Counting received messages cannot detect it by itself. A reconciliation between eligible source orders and created tasks reveals the gap. An authorized owner investigates and initiates the agreed recovery action.
This is an illustrative workflow, not a claim about an available payment integration or a recommendation of a particular provider.
Receipt is not the same as completed work
An integration may receive and store a message, then fail when creating the downstream task. Processing records should distinguish received, processing, completed, intervention required and intentionally excluded states. A successful acknowledgement to the sender must not be interpreted automatically as completion of the final business action.
The design needs to establish when acknowledgement is safe, how required work is retained before acknowledgement and how processing resumes after interruption. The mechanism depends on the provider and architecture. A buyer should ask for demonstrated behavior, not only a list of technology names.
With Observability & Reliability Engineering, connect alerts to the age of unfinished operations and unresolved exceptions, not just raw error counts. A service can appear available while work accumulates without completion. Name the recipient and escalation route; do not assume continuous coverage unless it is agreed.
Keep enough evidence to identify the failing step without indiscriminately recording sensitive payloads. A useful operational reference should allow authorized investigation while respecting the project’s information-handling boundaries.
Retrying requires limits and controlled effects
Separate temporary failures from invalid data, missing permissions and cases needing human review. Repeating incorrect input indefinitely does not repair it. Define when an operation enters an exception queue, who may correct and replay it, and how they establish whether the effect already occurred.
If the outcome is unknown, investigate before repeating it. The downstream system may have completed the action and lost the response. An internal operations system can show the reference, state and permitted next action to the authorized owner without exposing secrets or encouraging blind replay.
Do not promise end-to-end “exactly once” execution across several systems merely because one deduplication check exists. Explain tested boundaries, situations requiring verification or intervention and conditions outside the test scope.
The retention period for duplicate-detection records also needs a decision. It should match the relevant replay and operating requirements rather than an arbitrary value copied from another project. Replaying old events after those records expire may need a separate controlled process.
Build a failure-based acceptance pack
Ask Software Quality Assurance to demonstrate repeated delivery, out-of-order updates, an unavailable destination, invalid input, failed source or signature verification under the agreed mechanism, and a worker restart after partial progress. Include a missing-event case and verify that reconciliation detects the absent business outcome.
For each test, count resulting business effects as well as messages. Record the final state, timing and trace reference. Test recovery using the account and permissions that the receiving operational owner will actually have.
Acceptance should include the replay procedure, deduplication retention assumptions and exception-decision owner. A green happy-path test does not establish those operating arrangements. Nor does an alert establish who will act on it when the supplier is no longer present.
Frequently asked questions
Is deduplication by order number sufficient?
It may block valid updates when an order generates several events. Distinguish event identity from the intended business effect, then test both creation and amendment.
Should every error trigger another attempt?
No. Some errors require data correction or authorization changes. Classify them and define the next action rather than using unlimited retries as a substitute for resolution.
How can we detect an event that never arrived?
Compare an authoritative list of due operations with expected outcomes, within available capabilities and permissions. Observing only received messages cannot reveal every missing message.
Does monitoring include continuous support?
Monitoring provides signals and evidence. Response requires an owner, coverage hours and authority. Installing an alert does not create an uncontracted response commitment.
Before acceptance, ask the team to run one failure scenario from its beginning to a reconciled outcome. That exercise reveals more about recovery than another demonstration of the successful path.
Technical source
- Stripe: webhook ordering, duplicate events and processing, reviewed 26 October 2026. The scenario and acceptance criteria are independent planning illustrations, not a completed implementation.
