A repeated payment notification should not create another order or run its fulfilment twice. Integrations need to tell the business operation apart from the notifications they receive. Before adding retries, check what identifies each payment, how the work already done is recorded and what happens when the same notification arrives again.
A label comes out of the printer. Then an identical one comes out. The team looks for two orders but finds a single purchase. You do not yet know whether there were two charges, two notifications or a duplicated action. Separating those facts is the first step to investigating without blaming the buyer or repeating a delicate operation.
Why can a notification arrive more than once?
A webhook is a message one service sends to another when something happens. It can report a confirmed payment, a subscription change or another modification. The notification and the operation are not the same thing: receiving two messages does not prove there were two purchases, and it does not tell you automatically what to prepare.
Stripe warns that an endpoint may receive the same event more than once and that events are not guaranteed to arrive in order. Its documentation recommends recording the events you have already processed, and it allows for duplicates that carry different event objects. Stripe, webhooks documentation, accessed on 12 October 2026.
Imagine a workshop that sells sewing kits. A confirmed purchase creates a fulfilment order and a shipping label. If the integration treats every notification as a new purchase, the team could pack two kits. This is a hypothetical design example, not an incident observed at a meiika client and not a claim about how often the problem happens.
The mistake would be to demand that a message never repeats and leave the rest of the journey unprotected. A robust process has to know what to do when it receives information it already holds. That has to be designed into a visual automation as well: changing the tool does not remove the need to define the identity and the effects of each operation.
What identifies the operation you do not want to repeat?
Decide first what "the same job" means. You may want to avoid packing an order twice, granting access to a course twice or sending a confirmation again. Those actions can depend on the same payment but still need a consistent record. The identity must match the effect you are protecting, not just the last screen the user opened.
In the workshop, it would help to link the commercial order with the payment operation and with the fulfilment order. Whoever reviews an incident should be able to find that link without going through several inboxes. A stable reference makes it easier to tell a repeated notification from a second, legitimate purchase of similar products.
Whoever builds the integration must decide where the state is stored and how to stop two simultaneous runs from doing the same work. A box that says "processed" may not be enough if both runs read it before either has updated it. Concurrency deserves a technical review, even when your usual volume is small.
Do not use the customer's name, the amount or an isolated date as the only proof of identity. Two legitimate operations can share those values. Instead of an improvised deduction, ask for an explanation of the references available and of the matching rule. The business team has to understand the rule, even if it does not implement the technical details.
Record intermediate states too. Received, awaiting fulfilment, completed and failed describe different situations. A system that stores only success or error can lose track of a partly finished job. That difference decides what can be retried and what must be checked first.
How do you separate the charge from the work it triggers?
The payment is a financial operation; preparing an order is a logistics operation. You should not repeat the charge to recover a missing label. Review which system confirms the payment status and which later actions run, each with its own records. This separation makes the diagnosis more precise and reduces decisions taken on incomplete information.
Stripe documents the use of idempotency keys for certain API requests. A key lets the provider recognise a retry of the same request under the conditions it describes. That feature does not automatically make your whole fulfilment flow idempotent, and it does not replace handling incoming notifications. Stripe, idempotent requests, accessed on 12 October 2026.
So there are two directions to review: what your system asks the provider to do, and what it does when it receives information from the provider. Protecting a request does not prove that its consequences are protected. Ask for the project documentation to describe both, and avoid a generic "no duplicates" label that nobody has tested.
For the workshop, a test could confirm a dummy purchase and observe the order, the label and the internal notice. If the last step is missing, recovery should focus on it, after checking its status. The aim is not to add unlimited resends. It is to find which effect is missing and run only the matching recovery.
Information about charges, refunds and accounting obligations needs appropriate handling. This text is general information, not legal or professional advice. It does not suggest running real payments or refunds during a test, and it does not say how a specific transaction should be recorded for tax purposes.
Which tests catch duplicates before production?
Prepare scenarios with the person responsible for the integration and use the test environment available. The goal is to observe the commercial result, not to pile up green runs. A test is defined by what should remain afterwards, for example a single fulfilment order linked to one test purchase.
These scenarios help frame the review:
- The same notification is delivered twice, with the same reference.
- Two related notifications arrive in a different order.
- Fulfilment finishes, but its internal notice fails.
- Two runs try to act on the same purchase.
- The team asks to recover only the pending step.
Each rehearsal needs an expected result and observable evidence. State which record should exist, which message is received and which item must not repeat. If a scenario cannot be simulated safely, mark it as untested. Do not present one simple test as coverage of every situation an integration can face.
Do not use real buyers' orders as test material without an agreed procedure. You can prepare dummy data and internal recipients clearly labelled as tests. Also avoid publishing keys, private identifiers or payment information in shared screenshots. Useful evidence can describe the outcome without exposing the contents of the order.
How do you recover an operation without running it again?
When someone sees two labels, they need a way to stop fulfilment and check the references. Define who makes that decision and which records they consult. The manual procedure is part of the design, even when the integration automates most of the journey. An exception should not force anyone to guess what the system did.
Keep minimal traces of the operation and its effects. If fulfilment already exists, receiving a notification again should lead to a status check, not necessarily to repeating it. The exact recovery depends on your platform and on how the flow was built; there is no universal button that can be recommended without reviewing that setup.
Ask for a retry limit and a destination for cases that do not recover on their own. The team must be able to see how many operations are still pending and why. A notification repeated for days can create noise without solving anything. Notifying and recovering are different responsibilities, and it is best to assign them explicitly.
Before calling the review finished, observe the original case again plus a controlled repeat. Document what was checked, what is pending and who maintains the circuit. You do not need to promise there will never be errors; you need a verifiable way to tell them apart and handle them without repeating work by default.
How have we approached it at meiika?
At meiika we present bespoke systems that connect tools and business decisions. To study duplicates, the starting point would be to map the operations and their references: where a purchase is confirmed, what work it triggers and how its result is stored. We are not describing here an integration deployed for a client.
You can describe your case by saying what appears duplicated and which service sends the notification. Please do not send provider keys or card data. Any later technical review would have to agree limited access, tests and scope. Understanding the commercial effect is more useful than starting by adding another node to the flow.