Repeated payment or duplicate notice: test order confirmation

Distinguish the notice from the movement of money

A payment notice, also called a webhook, is a provider’s message to the store. Its arrival is not a new charge. To decide what happened, retain three separate references: order, provider payment and received notice. Two messages can describe one payment; two confirmed payments can mistakenly belong to one order. Each situation needs a different response.

Stripe warns that a notice may arrive repeatedly, separate events may describe the same object and type, and delivery is not guaranteed in generation order. Its documentation recommends distinguishing processed references. These are Stripe conditions rather than proof of your store’s behavior. Ask to verify that repeated notices retain one order and that an actual second charge remains visible.

Worked example: a 750 order and repeated notices

Ignoring step 4 as a “duplicate” would hide 750 overcharged. Creating another order and delivery would also be wrong when the buyer only accepted OP-62. Retain both movements, their order relationship and the authorized person’s decision. If the buyer actually made two separate purchases, each needs its own acceptance and reference; equal amounts do not determine intent.

When a PAY-B refund is authorized, record the refund request and await evidence of its outcome. Stripe documents that some refunds can remain pending and others fail depending on method and conditions; a request is different from returned money. While the refund remains pending, PAY-B stays recorded and the excess retains follow-up.

A success screen cannot decide handover by itself

A buyer can close the window after paying or lose connectivity before seeing the result. The store should check authorized provider evidence and relate it to OP-62. “Did not return to the page” does not mean “did not pay”; a success screen also does not replace verifying amount, currency and receiving account. Show payment under review while this information remains uncertain.

Test a failed-payment notice arriving late after a confirmed result. Before changing a paid order to failed, check which attempt it describes and its current authorized status. Retain history rather than treating the last received message as the latest reality. Payment reconciliation reconstructs events when notices alone are insufficient.

Define complete order confirmation

• Link order, purchase attempt and payment so another purchase’s payment cannot confirm OP-62.
• Validate provider, account, currency, amount and outcome; an unrelated message or discrepancy does not automatically confirm an order.
• Retain each notice and effect, distinguishing receipt of a message from an order update.
• Separate confirming payment, preparation and handover; demonstrate each once even when several notices arrive.
• Assign excess and uncertain outcomes to an owner with a next action and review deadline.

Test repeated notices and double charges separately

1. Normal: one correct payment confirms one allocation and permits one preparation.
2. Repeated notice: send the same message several times; the order and quantities remain unchanged.
3. Different notices: two messages for the same payment do not allocate 750 twice.
4. Additional charge: record and review another successful payment without losing it or duplicating goods.
5. Lost response: repeating a lookup or confirmation retrieves OP-62; the buyer is not forced to pay again because a response is missing.
6. Exception:749 amount, different currency or an unverifiable notice stays under review without confirmed handover.

The downloadable worksheet provides ten synthetic tests with expected evidence and blank observations. The cross-system notice and retry guide develops the general process; this article focuses on preserving money and purchase intent. Also review cancellation and refunds to follow a pending refund.

When assessing retail software, bring an anonymized order and references for the messages and payments affecting it. Identify who can consult the provider and authorize returning an excess. Without those access rights and decisions, another integration may receive more notices without resolving what your team should deliver.