A customer pays, the payment service records it, but the order in your application still says “pending”. From the customer’s perspective, your business has one problem. Behind the screen, several systems may disagree about what happened. That gap is where integration work becomes operationally important.
When reviewing an integration proposal, ask the team to explain both the normal path and the uncertain one. The successful demonstration matters. So does the plan for recovering without charging twice, sending duplicate messages or losing a genuine order.
Which record should the team trust?
For each important fact, identify the source the business will trust. The payment provider may hold the authoritative payment status, while your application holds fulfilment progress. A customer-facing screen should not invent certainty merely because a button was clicked or a request was sent.
Define the states in plain language. “Request received”, “payment confirmed” and “order fulfilled” describe different points in a process. When those distinctions are visible, staff can explain what is happening and users have a clearer next step.
Expect repeated and out-of-order messages.
Many integrations use webhooks: one service sends an event to another when something changes. Stripe’s webhook documentation, for example, describes retries, duplicate events and delivery that is not guaranteed to follow the order in which events were generated. It also requires verifying the origin of events before acting on them.
The practical buyer question is simple: if the same event arrives again, will the business action happen again? A robust implementation needs a way to recognise work already handled. It should also be able to recover the current state rather than depending on every message arriving in a perfect sequence.
What should support be able to see?
An integration that silently fails creates avoidable detective work. Agree which events need to be recorded, which failures should alert someone and what information support staff need. Logs should help connect a problem to the relevant transaction without exposing unnecessary sensitive data.
Also decide what staff are allowed to retry. A “resend” control may be convenient, but its effect must be understood. If the original outcome is uncertain, checking the source system before repeating the action can prevent a second mistake. Recovery controls deserve the same care as the happy-path interface.
Test the awkward situations deliberately.
Ask for a demonstration of a delayed response, a duplicate message, an unavailable destination and a recovery after the service returns. Include a reconciliation process for checking whether the systems agree. The right level of automation depends on the consequences and volume of the workflow.
Write the recovery instructions for the employee who will receive the customer’s complaint. They should know where to check the payment, how to find the matching order and which action is safe to take. Where the outcome remains uncertain, the instructions should identify who investigates it. That detail deserves a place in the delivery scope.
Read further
Original sources behind the technical guidance in this article.