One payment caused fulfillment to run twice

Count payment, fulfillment and shipment records separately

Begin with the provider payment associated with the affected order. Establish whether there is one payment or whether the initial report has confused several attempts or charges. This investigation starts from one payment with repeated downstream work. If the provider instead confirms multiple payments, preserve that finding and use a payment reconciliation process for that separate question.

Next identify the two reported fulfillment actions from the store or fulfillment system. Record each action’s own reference, creation time, item quantities, status and trigger if shown. Two messages about one action are different from two distinct requests. A fulfillment request, an inventory adjustment and a dispatched parcel are also separate facts: count each from its own record.

Check whether the two actions were intentional, such as documented work for different parts of the order. Compare items and quantities against the authorized fulfillment plan before describing them as duplicates. Where the same order work appears twice, retain both original records so the investigation can distinguish duplicate requests from goods actually sent twice.

Compare event identity and delivery attempts

Stripe’s webhook documentation says an endpoint can receive the same event more than once. It recommends recording processed event IDs to identify repeated deliveries. Compare the event ID across delivery attempts rather than counting attempts as separate payment events. A repeated delivery may have been rejected or ignored by the application and may have caused no second action.

The documentation also describes cases where separate Event objects are generated and sent. For that duplicate check, it points to the underlying object ID in data.object together with event.type. Different event IDs therefore do not, on their own, rule out equivalent notifications. Keep the event identity, object identity and type as separate fields in the private trace.

The same payment context can also produce events of different types. Do not collapse those into a single event merely because they concern one order. Ask which types the actual integration treats as fulfillment triggers, and compare each resulting action. This page does not supply a universal rule to suppress every later event for a payment.

Locate the point where one signal became two actions

For each fulfillment action, work backward through the application’s task or handler record to the event identity and delivery attempt, where those are available. A useful trace links the payment to the event, the event to the application work and that work to a distinct fulfillment action. If a log only shows that a request reached the endpoint, the chain is incomplete.

Stripe documents quick acknowledgment before complex downstream work and supports asynchronous processing. A successful endpoint response therefore cannot establish that fulfillment finished once, twice or at all. If there are two fulfillment actions but only one recorded handler invocation, investigate the downstream job and fulfillment records. If two deliveries both map to their own action for the same intended work, duplicate handling is the narrower question.

Other triggers may appear in the records, including an administrator action or a separate store automation. Preserve any such finding rather than attributing everything near the payment time to webhooks. When the action has no recorded trigger, state that the cause is unconfirmed. The provider’s documented ability to repeat delivery establishes a possibility, not this store’s cause.

Reconcile the effects before authorizing recovery

List the actual effects of each action: fulfillment work requested, inventory movements recorded, shipment status and any customer notification. Do not use a second label or task record as proof of a second physical shipment. Likewise, do not restore stock simply because one request was duplicated if goods have actually left inventory. Give the operations owner the discrepancy and the current status of both actions.

Ask the implementer to identify where the integration records that the intended work has already been performed, and whether repeated delivery, equivalent events or downstream retries can bypass that protection. The requested outcome should be stated in operational terms: one intended fulfillment action for the already-paid work, with legitimate later order actions still possible. The appropriate implementation depends on the installed software and the trace.

Do not create another payment to verify a fulfillment repair. Do not manually resend notifications as a diagnostic shortcut: Stripe says a manual resend does not cancel automatic retries. Any recovery needs a deliberate scope that accounts for actions already completed and messages still capable of arriving.

For a Prism checkout consultation, summarize whether one payment and two distinct actions are confirmed, whether the event-to-action links exist and what remains unresolved. Confirm investigation and implementation responsibilities, fees and terms before work. Keep the full trace in authorized systems; the public form needs no customer record, payment secret or full event payload.

Duplicate-action trace

Use one set for the affected payment and compare both actions inside your authorized incident record. Enter anonymized reference labels, counts and match results here. Repeated messages establish duplication of delivery; only action records and their trigger links can establish duplication of fulfillment and its cause.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.