The same order appears twice in the ERP. Your team checks the items, works out which record should move to fulfillment, and investigates whether inventory has also been affected twice. Before correcting the records, establish whether the customer placed two purchases or one purchase was processed more than once.
Integration failures are not limited to requests that never reach their destination. A response can be delayed, a notification can be delivered again, or a background job can retry after losing its connection. Duplication occurs when every delivery is treated as a new business operation. Preventing it requires a stable purchase identity and control over the effects of processing.
1. Distinguish a repeat purchase from a duplicate record
A customer can legitimately place two orders with identical products, addresses, and totals. Rejecting orders simply because their contents match can block a real sale. Identify the purchase using its reference in the source system, together with the relevant sales channel and merchant account.
For example, external order 7842 belongs to account LOJA-01 on CANAL-A. Another merchant account could use the same order number. A second purchase by the same customer should have its own identity even when the basket is unchanged. These identifiers are illustrative; the actual structure depends on the connected systems.
Both staff and software need this distinction. A customer name helps a person investigate, but it is not an order key. A SKU is not a purchase identity either: the same product can appear in many unrelated orders. Establish the business identity before deciding what should be considered a duplicate.
2. Understand how a retry becomes a second order
Consider this illustrative sequence. At 10:00:01, the integration asks the ERP to create an order. The ERP saves it, but the connection fails before the response reaches the sender. At 10:00:02, the integration still does not know whether the operation succeeded and submits another attempt.
If the destination interprets that second request as a new purchase, two records result. If it recognizes the original operation, it can return the order reference already created. A communication error observed by the sender therefore does not prove that nothing happened at the destination.
Notifications and scheduled jobs can also repeat. Determine whether the repeated attempt came from the channel, a queue, a manual retry, or two jobs handling the same workflow. Disabling retries altogether may exchange duplicate orders for missing orders rather than solve the underlying reliability problem.
3. Separate the order, the event, and the business action
Three distinct references help explain what happened:
- Order identity: the purchase in its original channel and merchant account.
- Event identity: a specific incoming notification, when the provider supplies an event identifier.
- Action identity: the effect being applied, such as creating the destination order or recording a state transition.
Receiving the same event twice differs from receiving two different events about one order. Your integration needs to recognize both situations while allowing legitimate changes, such as a pending payment becoming confirmed.
An event-ID check alone may miss two separate notifications that trigger the same order creation. Conversely, ignoring everything associated with an order already known to the system prevents its lifecycle from progressing. Define which action must happen once and which subsequent changes remain valid. The identity should reflect the business operation, not merely the arrival of another message.
4. Make repeated processing safe
Idempotency allows an operation to be repeated without incorrectly repeating its effect. For order creation, that generally means a stable operation reference, a mapping between external and internal order records, and protection against concurrent execution.
Checking whether an order exists before inserting it is not always sufficient. Two workers can perform that check simultaneously and both conclude that no record exists. The implementation must enforce uniqueness where data is written and coordinate the processing marker with the data change, using an approach appropriate to its architecture.
A local database transaction cannot make communication between two independent systems atomic. When an ERP call loses its response, the integration needs a trustworthy way to look up the outcome or use the destination's idempotency mechanism, where supported. Generating a fresh operation reference for every retry removes the relationship that would let the destination recognize a repeated request.
5. Reconcile inventory and fulfillment effects
Cleaning up the order list does not necessarily repair every consequence. Check what each record caused: a reservation, inventory deduction, document generation, release to picking, or an update in another system.
Define the inventory system of record and the stage at which each movement occurs. If the ERP owns the authoritative balance, the other components must follow that design. Reservations, deductions, and releases need explicit rules so that a repeated message cannot apply the same transition again.
An existing duplication needs reconciliation, not a blind deletion. Before canceling a record, identify the valid purchase and the actions already taken. Deleting an order or manually changing inventory without checking those effects can obscure the cause and create a new mismatch. Keep an understandable audit trail of the correction and account for work already performed by the fulfillment team.
6. Investigate using comparable references
Collect the source channel and account, the external order reference, destination record IDs, attempt times, responses, and actions performed. Include the time zone used by each log. Timestamps displayed in different zones can make the sequence appear misleading.
Compare evidence from both sides. A single error message cannot establish whether the ERP created the order, and an ERP record alone cannot explain why another attempt occurred. Record whether someone manually retried the operation while an automatic job was still trying to complete it.
Share only the information needed for the investigation. Support generally needs identifiers and context, not passwords, API keys, or unrestricted copies of customer data. An organized incident record is more useful than a collection of screenshots that cannot be correlated to the same purchase.
7. Test repeated requests and failure paths
A successful purchase through the normal path does not validate duplicate protection. In a test environment, include at least the following cases:
| Scenario | Outcome to verify |
|---|---|
| The same request is submitted again | Only one destination order exists |
| Two attempts run concurrently | No second order is created |
| The destination saves the order but its response is lost | The next attempt recognizes the previous outcome |
| Related events arrive out of order | The resulting business state remains consistent |
| The same operation reference carries incompatible data | The conflict is surfaced without a silent overwrite |
| The customer makes another legitimate purchase | The new order is accepted normally |
Also confirm that an authorized retry repeats only the unfinished step. A retry button should not indiscriminately perform every action that has already succeeded. Verify the destination record and inventory effects, rather than checking only that the job reports success.
8. Make recovery a controlled operational process
After implementing a correction, keep pending failures and retries visible. Staff should be able to distinguish orders awaiting submission, currently processing, completed, or requiring investigation. They also need to know who can authorize another attempt when the outcome remains uncertain.
Document how the purchase is identified, which system owns inventory, and how reconciliation works. Reliable integrations let an operation continue through communication failures with traceability, rather than depending on someone discovering duplicates after fulfillment has started.
If duplicate orders are creating manual work in your business, AGTI can assess the workflow between your systems and help identify missing controls. Explore AGTI's services.
Technical references
- Making retries safe with idempotent APIs — AWS Builders' Library.
- Webhook delivery behavior and duplicate events — Stripe documentation.
- Idempotent requests — Stripe API reference.
Sources checked on October 19, 2026. Order identifiers and operational scenarios are illustrative. Implementation depends on the API contracts and business rules of the systems involved.