[Blog]()Commerce # Repeated payment or duplicate notice: test order confirmation Two notices can describe one payment; two payments can affect one order. Verify references, money and one delivery without hiding excess charges. **[Jonathan Perez]()**Co-founder · Design, product and sales October 8, 2026 · 7 min read **Short answer** To test order confirmation, distinguish the notice reference, payment reference and order reference. A repeated notice retains the earlier allocation; an actual second charge is recorded and reviewed even at the same amount. Confirm amount, currency and account before preparation and verify that retries do not create another handover or conceal received money. ## Duplicate notice and double-charge tests Ten synthetic notice, payment and order cases covering excess payments, pending refunds and currency verification. [Download CSV worksheet]() In this guide - [Distinguish the notice from the movement of money]() - [Worked example: a 750 order and repeated notices]() - [A success screen cannot decide handover by itself]() - [Define complete order confirmation]() - [Test repeated notices and double charges separately]() ## 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. | Situation |Evidence |Expected test response | | --- | --- | --- | | Same notice again |Same notice and payment references |Retain the previous result | | Another notice for the same payment |Different notice; same payment and fact |Do not apply money or prepare goods again | | Actual second payment |Different payment reference and confirmed charge |Record both; review excess before another handover | ## Worked example: a 750 order and repeated notices **Synthetic acceptance scenario** Order OP-62 totals 750 MXN without tax or additional charges. Proposed policy: one commercial order retains one delivery; unexpected extra charges go to review with an owner. References are fictional and do not describe a Nightly project or real account. | Step |Fact |Verifiable outcome | | --- | --- | --- | | 1 |PAY-A confirms 750; NOTICE-1 arrives |OP-62 paid; one 750 allocation; one preparation | | 2 |NOTICE-1 arrives again |Same allocation; no new order | | 3 |NOTICE-2 describes the same confirmed PAY-A |Retain 750 allocated; no additional dispatch | | 4 |PAY-B also confirms 750 |Two actual charges = 1500; 750 excess under review | | 5 |Another PAY-B notice arrives |Still two charges, not three; one excess review | 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. ## Follow references for an uncertain payment In a free consultation we can review whether the process repeated a notice, received another charge or lost confirmation. - An anonymized order and associated payment references. - Provider notices and states with time, amount and currency. - Who checks payments and authorizes excess-payment or refund decisions. [Book a free consultation]()[Ask on WhatsApp]() Related - [Retail software]() - [Websites and online stores]() ## Frequently asked questions ### Do two notices mean two charges? No. They can describe the same payment. Check payment and notice references rather than only counting messages. ### Should I ignore another charge of the same amount? When it has a different reference and is confirmed as received money, record it and review the excess. Ignoring it can hide an unresolved obligation. ### Is a success screen enough for handover? Verify the authorized result, amount, currency and order. When evidence is missing, show review status and an owner. ### Does a requested refund mean returned money? No. Retain its reference and state until the result is verified. An additional payment remains recorded while its refund is pending. ## Sources 1. [Receive and handle Stripe events]()Stripe 2. [Refund and cancel payments]()Stripe Last updated: October 8, 2026 ## Keep reading [CommerceOct 8, 2026 ### Matching payments to orders: references, differences and review]()[Integration eventsOct 8, 2026 ### Failing webhooks: retrying without duplicate work or lost events]()[CommerceOct 8, 2026 ### Cancel an order: fulfillment, payment and confirmed refund]() --- Canonical: https://nightlysoftware.com/en/blog/duplicate-payment-events Updated: 2026-10-08 Description: Distinguish another notice from an actual second charge. Test confirmation, single handover and excess payments with ten downloadable cases.