A payment succeeds, but the order status doesn’t change. Someone tries again and two records appear. An integration project needs to account for this kind of failure when connecting two APIs.
When evaluating an integration, test what happens when a message arrives late, repeats or fails. Checking only the case where everything responds immediately is not enough.
Decide who owns each field
List the fields that will move between systems: customer, order, amount, stock and payment status. For each, define which system maintains the main record and who can change it.
If sales changes an address in the CRM while finance holds an older copy, which side updates the other? Without that decision, a two-way synchronisation can keep overwriting changes.
Keep the identifiers used by each system, too. The website’s order number may differ from the ERP code; the integration must recognise that both refer to the same order.
Notifications can arrive again
A webhook tells another system when an event occurs. In Stripe’s documentation, events can arrive more than once and delivery order isn’t guaranteed. Its guidance includes recording processed events and verifying the received signature.
That’s Stripe’s behaviour, not a promise about every provider. Check how each platform delivers notifications. For acceptance, ask for a repeated-message test and an out-of-order test, then observe the business result.
The order should remain identifiable after several attempts. Whoever supports the customer needs to see its current state and whether anything is pending.
Retry without charging twice
Idempotency means an operation can be repeated without duplicating its effect. Stripe’s API accepts idempotency keys to make retries safe for supported operations.
Ask the developer how that applies to the action you care about: creating an order, recording a receipt or sending a charge. Protection must cover business processing; a visual notice saying the button was clicked doesn’t demonstrate that the operation is protected.
Include a test where the destination completes the operation but its response never reaches the source. The retry should reconcile the result before creating another record.
Make limits and failures visible
An API may impose a rate limit. MDN describes HTTP status 429 and the optional Retry-After header, which tells the caller how long to wait. Each provider sets its own rules.
Agree which failures will be retried, how long the wait will be and who gets notified when an action remains pending. A failed operation shouldn’t appear completed in the interface.
Ask for a checking routine
During acceptance, run a normal order, a repeated one, a temporary failure and a rejection that requires corrected data. Check the records in both systems using the agreed identifiers.
Ask for a pending-work list and a procedure to retry entries without duplication. Logs should help locate the failure without exposing passwords or unnecessary personal data. The integration is ready to operate when someone can identify and resolve a stuck order, as well as track successful ones.
Sources
- Receive Stripe events in your webhook endpoint. Stripe. accessed October 2026.
- Idempotent requests. Stripe. accessed October 2026.
- 429 Too Many Requests. MDN Web Docs. accessed October 2026.