Stop One Payment Notice From Creating Two Orders
Payment, booking, and delivery services sometimes send the same notice more than once. Your app should remember completed work so one customer action produces one result.
before you start
The same notice may arrive twice, but the payment, shipment, credit, or account change should happen only once.
Understand why the same notice can arrive twice
in plain words
Another service may repeat an automatic notice when it cannot tell whether your app received the first copy.
Your app may be connected to a payment company, booking system, form provider, subscription company, or delivery service. After a customer pays, cancels, books, or updates an account, that company can send a machine-readable notice directly to your app. The technical name for this automatic notice is a webhook. If the first delivery is slow, the reply is lost, or your app briefly stops responding, the company may send the same notice again. This repeat is usually an attempt to make delivery reliable, not a second customer request.
The danger begins when your app treats every arrival as new work. One payment could create two orders, one refund could return money twice, or one booking could reserve two places. A repeated account notice might also grant or remove access more than once. Write down the real-world result caused by each kind of notice. Decide exactly what is allowed to happen once, including charging money, issuing store credit, sending a package, changing stock, sending an email, or changing what a customer can open.
- ▸Include payments, refunds, subscriptions, bookings, deliveries, and account changes.
- ▸Treat a repeated delivery as expected behavior, not proof that the customer acted again.
common risk
A customer pays once. Because the payment company does not receive a quick reply, it sends the confirmation again, and the app creates two shipments.
what to do now
List every automatic notice your app receives and the single customer, money, stock, or account result each notice may create.
ask your AI
Inspect this app and show me every place that receives an automatic notice from a payment, booking, form, subscription, or delivery service. Developers call this kind of notice a webhook. For each place, list the customer, money, stock, email, shipment, or account action that follows. Identify which actions must happen only once. Do not change the app yet.
Make the app remember completed work
in plain words
Your app needs a lasting receipt that says a particular notice has already produced its allowed result.
Most sending services include a stable reference number for every notice. The technical name is an event ID or delivery ID. Before changing an order, balance, booking, shipment, or account, your app should look for that reference in its saved records. If a completed reference already exists, the app should report successful receipt without repeating the action. Use the sender's reference instead of a customer name or arrival time, because one customer can perform several actions and two deliveries can arrive almost together.
The receipt must survive restarts. A structured, lasting collection of app records has the technical name database. Save the sender, reference number, arrival time, processing state, and related order or customer reference there. The app should reserve the reference before beginning important work so two copies arriving together cannot both proceed. The simple rule is: the same notice must lead to the same final result. The technical name for that rule is idempotency. Visitors must not be able to read, create, or alter these processing receipts.
A notice can stop halfway through, so do not record only “received” or “done.” Use clear states such as waiting, working, completed, and failed before the important action. Also record whether money, stock, email, shipment, or account access actually changed. If an uncertain attempt returns, the app should inspect the saved state instead of blindly starting over. This makes recovery safer and gives you enough information to investigate without placing passwords, payment keys, access codes, or unnecessary customer information in the records.
- ▸Use the stable reference supplied by the sending service.
- ▸Reserve each new reference before the important action begins.
- ▸Record the final result so interrupted work can be reviewed safely.
common risk
The app remembers references only in temporary memory. After it restarts, a delayed copy arrives and adds the same store credit again.
what to do now
Add lasting processing receipts and check them before creating an order, refund, credit, message, shipment, or account change.
ask your AI
Add one-time processing for every automatic outside notice in this app. Use the sender's stable event ID as the unique reference. In a protected database table, reserve that ID before any customer, money, stock, email, shipment, or account action. Store the sender, arrival time, state, related record, and final result. If a completed ID arrives again, return the normal successful response without repeating the action. Handle two copies arriving at the same time, and keep these records unavailable to visitors.
Reject copied notices that should no longer be trusted
in plain words
Remembering completed work is not enough; the app must also confirm who sent a notice and whether it is recent.
A person should not be able to invent a payment or cancellation notice. The sending service normally attaches mathematical proof that only it can create. Developers call this proof a digital signature. Your app must check it using the exact method documented by that service. This check belongs in the protected part of the app that runs away from visitors' devices; the technical name for that protected computer process is a server. It must happen before money, stock, orders, customer information, or account access changes.
The server uses a signing key supplied by the sending service. Treat that key like a payment key or access code. Do not place it in a page, script, settings file, or other file sent to a visitor's device. Check the original, unchanged notice content, because changing its formatting before verification can make a genuine signature fail. Reject missing or invalid proof. Record only a safe reason for rejection, never the signing key, passwords, payment details, access codes, or full customer information.
A genuine notice can still be unsafe when someone saves an old copy and sends it again later. Check the creation time and accept only the short age range recommended by the sending service. The technical name for refusing reused old copies is replay protection. Combine this age check with the saved reference check: the proof confirms the sender, the time check rejects stale copies, and the receipt prevents a recent duplicate from repeating work. All three checks must run before an important change.
- ▸Follow the sending service's official verification instructions exactly.
- ▸Keep signing keys in the protected server process, away from visitor-delivered files.
- ▸Reject invalid or unexpectedly old notices before changing anything important.
common risk
A genuine cancellation notice from months ago is sent again and removes account access from a customer who has since renewed.
what to do now
Confirm that sender proof, notice age, and the saved reference are checked before any payment, order, stock, or account change.
ask your AI
Review every place that receives an automatic outside notice. Before any important action, verify the sender's digital signature on the server using the provider's official method and the original unchanged request content. Reject missing or invalid signatures. Reject notices outside the provider's recommended time window. Then check the saved event ID before acting. Keep signing keys out of every file delivered to visitors, and make rejection records exclude passwords, payment keys, access codes, payment details, and customer information.
Test repeats and keep watching for changes
in plain words
The protection is working only when repeated and interrupted test notices still produce one final result.
Use the sending service's harmless practice mode. Developers often call this a test environment. Send one sample notice twice and confirm there is exactly one order, refund, credit, email, shipment, or account change. Also send two copies at nearly the same time. Then interrupt a practice attempt after its receipt is saved. The app should show whether the work never started, completed, failed, or needs careful review. Do not manually repeat a money action while its result remains uncertain.
Keep a protected history of arrivals, decisions, results, and failures. Developers call these records processing logs. They should contain useful references and states, but not passwords, signing keys, payment keys, access codes, full payment details, or unnecessary customer information. Create a warning for repeated failures, invalid sender proof, unexpectedly old notices, and an unusual rise in rejected repeats. Review the real order, balance, shipment, or account result instead of trusting only a success message.
Repeat these tests whenever you connect another service or change payment, order, stock, email, shipment, or account logic. VibeCodeWall checks the public app from the outside and can watch for important changes over time. It does not see private code and does not replace these protected-process tests. Continuous watching can help you notice that the public app changed, while your duplicate, sender, age, interruption, and record checks confirm that important actions still happen only once.
- ▸Test the same sample twice and two copies arriving together.
- ▸Check one saved receipt and one real final result.
- ▸Retest after every important connection or processing change.
common risk
A later app change moves the duplicate check until after the shipment request, so each repeated notice can send another package.
what to do now
Run the full repeat and interruption test now, then add it to the checks performed after every relevant app change.
ask your AI
Create and run a safe test plan for every place that receives an automatic outside notice. In the provider's test environment, send the same event twice, send two copies at nearly the same time, test an invalid signature, test an expired timestamp, and simulate an interruption after the receipt is reserved. Confirm exactly one final customer result and show the matching protected processing record. Add automated repeat checks where possible and tell me what should be watched after future changes. Do not use real charges or expose passwords, signing keys, payment keys, access codes, payment details, or customer information.
Quick checklist
- 01List the outside services that send automatic notices to your app.
- 02Identify the stable reference number carried by each notice.
- 03Save that reference before starting an important action.
- 04Safely stop when a completed reference arrives again.
- 05Confirm that each notice genuinely came from the expected service.
- 06Reject notices older than the service recommends accepting.
- 07Send the same harmless test notice twice and confirm one result.
- 08Keep watching for repeated failures and important changes.
FAQ
Why would a service send the same notice twice?
It may not have received your app's first reply because of a slow connection, a temporary interruption, or a lost response. Sending another copy helps it avoid losing the update.
Can the order number be the saved receipt?
Sometimes, but the sender's notice reference is usually safer. Several different updates can belong to one order, such as payment, refund, shipment, and cancellation.
Should the app report an error for a completed repeat?
Usually it should confirm successful receipt after verifying the sender, age, and saved reference. It must not repeat the important action.
Is checking who sent the notice enough?
No. A genuine service can send a genuine notice more than once. The app also needs an age check and a lasting record of completed references.