Agentic Commerce Needs a Replay-Safe Event Workflow

A payment notification arrives, an order workflow starts and a confirmation is prepared. Then the same notification arrives again. Does the system recognize work already completed, or does it create another action for the customer?

This is an operating question for agentic commerce teams. Adding an assistant to a purchase journey does not remove the need to handle repeated, delayed or unexpectedly ordered events. A polished conversation can sit on top of a workflow that has no reliable answer to a retry.

Separate a notification from a business action

Stripe's webhook documentation provides a concrete example of the underlying problem. It says events may be delivered more than once and are not guaranteed to arrive in generation order. Its guidance includes tracking processed event identifiers and handling incoming work asynchronously. The details are specific to Stripe's integration; other providers must be checked against their own documentation. Stripe documentation

The broader workflow below is our operational interpretation. It is not a claim that every payment or commerce platform has identical delivery behavior, and it does not promise exactly-once delivery across distributed systems.

Name the action that must not repeat

Start with customer consequences. Creating an order, releasing a shipment, applying a credit and sending a confirmation are separate actions. Each needs a clear definition of when it is allowed and how completion is recorded. Receiving a notification is only one piece of evidence.

In a hypothetical workflow, a repeated payment event should not create a second shipment instruction for the same fulfilled order. However, a legitimate later refund event must not be discarded merely because the order was seen before. The team needs business rules that distinguish repetition from a new authorized transition.

Preserve identity through the workflow

Give operations a way to connect the provider's event, the relevant business object and the action attempted by the system. A timestamp alone is a weak explanation of what happened. People investigating an exception need to know which message was received and which consequence followed.

Avoid putting unnecessary personal information into troubleshooting records. The useful objective is traceability of the process, with access appropriate to the data. A support operator should be able to identify an unresolved transition without copying a customer's payment or identity details into an unrelated tool.

Design for the uncertain middle

One difficult case occurs when a request may have succeeded but the response was lost. Repeating the entire workflow immediately can make the uncertainty worse. Define how the system checks authoritative state before deciding what to repeat, reconcile or escalate.

Record meaningful stages such as received, validated, awaiting processing and completed. These are illustrative business states, not a prescribed provider API. The important distinction is between accepting work and finishing its effects. A queue acknowledgment should not automatically become a customer-facing statement that an order is complete.

Test the exception paths deliberately

Run controlled tests for duplicate delivery, delayed delivery, changed event order and interruption during processing. Include a case where an external action succeeds but the local completion record is unavailable. Ask the team to explain how it will recover without guessing.

Agree on the expected customer experience for each case. The assistant may need to say that confirmation is still being checked. A truthful pending state is more useful than a confident completion message that operations must later retract. Keep the language tied to observable evidence.

Give unresolved events an owner

A reliable process includes a place for exceptions that cannot be resolved automatically. Define who reviews them, what evidence they receive and when escalation occurs. Replaying a failed event should be a controlled operation whose effects can be inspected, rather than a button pressed until the dashboard turns green.

Review recurring causes as product work. If the same uncertainty repeatedly reaches support, repair the underlying transition or missing evidence. Do not make the assistant responsible for explaining away a workflow the team has not defined.

Before expanding an agentic commerce pilot, follow one order through its event lifecycle and replay the relevant test cases. The practical standard is that repeated delivery does not accidentally multiply the intended business effect, while legitimate new changes still receive the right response.

Source reviewed September 19, 2026. Examples and workflow recommendations are Aeris editorial analysis.