Before approving a connection between your order, warehouse or accounting systems, ask what happens when the same update arrives twice. The delivery may need repeating. The invoice, dispatch request or customer message may already exist.
A missing reply leaves a question open
Imagine one system sends an update and the receiving system finishes its work. The reply confirming success gets lost on the way back. The sender waits, reaches its time limit and tries again.
That timeout explains why another delivery happened. It does not tell you whether the first attempt completed. Turning retries off can leave work unfinished; repeating every business action can create extra work instead.
Malcolm Featonby describes this uncertainty in the Amazon Builders’ Library account of making retries safe. Stripe and Shopify also document repeated webhook deliveries. A webhook is an automatic update sent from one system to another. This is a behavior worth discussing before the connection goes into use.
Which action should happen once?
Take a hypothetical shop where a paid-order update should create one fulfilment request. These three situations need different treatment:
The same update arrives again
The fulfilment request may already exist. Another delivery should not create another request for the same intended action within the agreed limits.
Another update concerns that order
An address change or cancellation could need different work. Sharing an order number does not make every update redundant.
The customer places a second order
A new order must still proceed, even if the customer, items and total look identical. Similar details do not establish that it is a repeat.
Ask the supplier what identifies the intended action and how that identity survives another delivery. You do not need to choose the technical mechanism. You do need an explanation of why it recognizes a repeat while allowing genuinely new work.
Provider details differ. Stripe’s documentation discusses repeated events and separate events about the same object. Shopify distinguishes an individual delivery from the merchant action behind it. An identifier useful for one purpose is not automatically the right rule for every business action.
The relevant examples are in Stripe’s webhook documentation and Shopify’s delivery verification guide. The supplier should check the current behavior of the systems you are actually connecting.
Find out what happens after only part of the work succeeds
Suppose the fulfilment request is created, but the connection stops before recording that it finished. On the next attempt, how does it find the existing request? What if two copies arrive together? A list of previously seen updates does not, by itself, answer either question.
Ask to see three things separately: evidence that the update arrived, the connection’s processing status, and evidence of the resulting action in the receiving system. A delivery acknowledgement alone may not establish that the parcel request or invoice exists.
Where the result remains uncertain, agree who investigates and what they check before allowing another attempt. Give staff clear limits: which actions they may resume, which need the supplier’s help, and when they should stop rather than risk creating another business action. Some problems will require comparing records across systems and a person deciding what to do next.
“Try again” is useful only when you know what another attempt is allowed to do, and who takes over when the result is unclear.
Ask for a safe demonstration
Use a supported test environment with invented records and external business actions suppressed. The demonstration should cover the same delivery twice, a genuine second order, and a failure after one step has succeeded. Check the resulting records as well as the delivery log. Never replay a live payment or order just to discover what happens.
Request a short written account of the trigger, the intended action, how a repeat is recognized, and where staff can see the result. Include how long the connection remembers earlier work, what happens to a late delivery, and who handles an uncertain or partly finished action.
If the systems do not support a safe demonstration of a particular failure, record that gap and agree a narrower review with the supplier. A successful test supports the behavior under those conditions. It does not guarantee exactly-once behavior across every connected service, or prove that a whole sequence will complete as one indivisible operation.
We build integrations and custom business software. If you are planning a connection, bring the systems involved, the action you want to trigger and the repeat behavior you still need explained. We can discuss the work needed for that connection.
Questions before you approve the connection
Does a timeout mean the first attempt failed?
No. The work may have finished while the reply was lost. Check the processing result and the receiving system before deciding what another attempt should do.
Can two identical-looking orders both be valid?
Yes. A customer can intentionally place a second order with the same items and total. The connection needs to distinguish new intent from repeated delivery; matching details alone cannot settle it.
How can we test repeat behavior safely?
Ask for a supported test environment with invented records and external business actions suppressed. Include a repeat, a genuinely new action and a failure after some work succeeds. Record any testing gaps instead of experimenting on live orders or payments.
Who should resolve a partly completed action?
Agree a named person or responsible team before launch. Staff need to know what they can check or resume themselves and when the supplier must investigate before another action is allowed.
