Stop One Payment Notice From Creating Two Orders
Payment and delivery services sometimes repeat the same notice. Teach your app to recognize copies so one customer action produces only one safe result.
before you start
A repeated notice should not create a repeated charge, order, refund, email, or account change.
Understand why the same notice can arrive twice
in plain words
An outside service may repeat a notice when it is unsure that your app received the first copy.
Imagine that a customer pays once, renews a plan, books a room, or requests a refund. The company handling that action sends an automatic notice to your app. A short connection problem may prevent the company from receiving your app's confirmation. To avoid losing an important update, it sends the same notice again. This is a normal safety behavior used by many online services. It does not automatically mean that somebody is attacking your app, but your app must still treat the repeated copy carefully.
Developers call this automatic notice a webhook. If every arrival is treated as a new customer action, one payment could create two orders, two account credits, two shipments, or several confirmation emails. The plain goal is simple: let the first valid notice produce the result, then recognize later copies without producing that result again. The technical name for protection against an old or copied notice being used again is replay protection. It is useful for accidental retries as well as deliberately repeated messages.
- ▸Expect copies after slow replies, temporary failures, and automatic retries.
- ▸Map each incoming notice to the real action it can cause.
- ▸Do not assume that a second arrival represents a second customer decision.
common risk
A customer pays for one item. The payment company does not receive a quick confirmation, so it repeats its notice. An unprotected app creates two orders and asks the warehouse to send two items.
what to do now
Write down every outside service that sends notices to your app and the orders, money, stock, messages, customer information, or account access each notice can change.
ask your AI
Review my app for automatic notices from payment, subscription, booking, order, refund, and delivery services. Developers call these notices webhooks. List where each one is received, which files handle it, what real-world change it can cause, and whether a repeated copy could cause that change twice. Do not reveal payment keys, passwords, access codes, or customer information. Make no changes yet; return a prioritized review.
Give every notice its own receipt number
in plain words
A unique receipt number lets the app recognize a notice that it has already handled.
A reliable service normally includes a unique receipt number with each notice. Before changing an order, balance, subscription, booking, or account, your app should look for that number in its own saved records. If the number is new, the app can reserve it and continue. If the same number from the same service is already present, the app should return a normal confirmation without repeating the customer-facing result. Save the service name too, because two different services could happen to use the same number.
Developers often call that receipt number an event ID. The technical name for making repeated requests leave the same final result as one request is idempotency. Do not identify copies only by customer name, payment amount, product, or arrival time. Two real customers can buy the same product for the same price within one minute. Use the event ID supplied by the service. For actions started by your own app, create a unique request number and store it with the result so a retry can safely find the original outcome.
- ▸Save the service name, event ID, arrival time, status, and final result.
- ▸Require the combination of service name and event ID to be unique.
- ▸Return the earlier safe result when a completed notice arrives again.
common risk
Two customers buy the same plan for the same price at nearly the same time. A rule based on price and time incorrectly discards one real purchase, while unique receipt numbers correctly preserve both.
what to do now
Find the unique receipt number provided by each service and confirm that your saved records have a dedicated, uniqueness-protected place for it.
ask your AI
Add safe duplicate handling for every automatic outside notice in my app. Developers call this idempotency for webhooks. Use the provider name and provider event ID as one unique database key. Check and reserve that key before changing orders, balances, subscriptions, bookings, stock, refunds, customer information, account access, or outgoing messages. A completed duplicate must receive a normal success response without repeating the change. Show every changed file, database rule, and test.
Do not leave a gap between checking and acting
in plain words
Two copies arriving together must not both decide that they are the first copy.
A simple check followed by a separate save can still fail. Two copies may arrive almost together. Both can look for the receipt number before either has saved it, so both believe they are first and both continue. This timing problem may not appear during a quiet manual test. Your app needs one protected saved-record operation that allows only one copy to reserve the receipt number. Only the copy that wins that reservation may begin the related order, refund, balance, stock, message, or account change.
The technical name for a step that succeeds as one protected unit is an atomic operation. When possible, reserve the receipt number and make the related saved-data change in one database transaction, which means the database completes all included changes together or keeps none of them. Longer work, such as asking another company to ship an item, needs clear states such as received, working, completed, failed, and needs review. A retry should examine that state instead of blindly starting everything again. Staff also need enough history to resolve an unfinished case without creating another payment or shipment.
- ▸Allow only one copy to reserve a receipt number.
- ▸Keep the reservation and important saved-data change together when possible.
- ▸Send uncertain or partly completed work for review instead of repeating it blindly.
common risk
Two identical notices arrive milliseconds apart. Both pass a separate check, and each grants a month of paid access. A uniqueness rule and protected reservation allow only one copy to proceed.
what to do now
Ask your AI builder to identify the exact reservation step and prove with a test that two simultaneous copies cannot both win.
ask your AI
Change my automatic-notice processing so reserving the provider name and event ID is one atomic database operation. Only the request that successfully creates the unique record may change money, orders, refunds, balances, subscriptions, bookings, stock, customer information, account access, or outgoing messages. Record received, working, completed, failed, and needs-review states. Add a concurrency test that sends two identical test notices at nearly the same time and proves that only one real-world result is created.
Check the sender, test copies, and keep watching
in plain words
Confirm who sent each notice, test repeated copies safely, and review the protection after important changes.
Recognizing a receipt number is only part of the job. Your app must first confirm that the notice really came from the company it names and that it is recent enough to trust. The company usually supplies signed proof that your app checks with a payment key or access code stored where visitors cannot download it. Developers call this proof a webhook signature. Many services also include a sent time. Follow that service's instructions for checking the signature and accepting only a reasonable time window. Perform these checks on the original message exactly as received, before trusting its contents or reserving its receipt number.
Use the service's test mode, not real customer information or real charges. Send one valid test notice and confirm one result. Send the exact notice again, then send two copies nearly together. Confirm there is still one order, one balance change, one shipment request, one access change, and only the intended customer messages. Also simulate a failure after the receipt number is reserved, and confirm the record clearly says what needs review. VibeCodeWall checks the public app from the outside and watches for important changes over time. It does not see private code or replace these internal tests, but a public change can remind you to review this protection again.
- ▸Verify the signed proof and allowed age before trusting a notice.
- ▸Test ordinary copies, simultaneous copies, and an interrupted attempt.
- ▸Repeat the review whenever payment, order, subscription, or delivery handling changes.
common risk
A team tests only one successful payment notice. A later retry sends another welcome email and another shipment request because nobody tested repeated or interrupted delivery.
what to do now
Create safe repeat tests for every notice that can affect money, customer information, orders, stock, messages, bookings, or account access, then run them after each related change.
ask your AI
Create and run safe automated tests for every automatic outside notice in my app. Developers call these webhooks. Follow each provider's official method to verify its webhook signature using test payment keys or test access codes, enforce the provider's documented timestamp window, and reject invalid or stale notices before any saved-data change. Test the same valid event twice, two identical events arriving nearly together, and a failure after reservation. Prove that each case creates exactly one intended result and leaves a clear status. Never use real charges, real customer information, real payment keys, or real access codes.
Quick checklist
- 01List every outside service that sends your app payment, order, subscription, booking, or delivery notices.
- 02Identify the unique receipt number included with each notice.
- 03Confirm the notice really came from the named service before trusting it.
- 04Reject notices that are older than the service's documented safe time window.
- 05Save each receipt number before changing money, orders, stock, customer information, or account access.
- 06Make saving the receipt number and starting the change one protected operation.
- 07Record whether each notice was received, completed, failed, or sent for review.
- 08Test one repeated notice and two copies arriving almost together.
- 09Keep payment keys, passwords, and access codes away from files visitors can download.
- 10Continue reviewing this protection whenever payment or order handling changes.
FAQ
Does a repeated notice always mean someone attacked my app?
No. It commonly happens when an outside service does not receive a timely confirmation. The same protections also help when somebody deliberately repeats a copied notice.
Can I compare the customer name and payment amount instead?
No. Separate legitimate purchases can have identical details. Use the service name and its unique receipt number for the notice.
How long should the app keep receipt records?
Keep them long enough to cover the service's documented retry period, possible disputes, and your support needs. Choose and document the period before deleting records.
What if processing stops after the receipt number is saved?
Keep a clear unfinished or needs-review status. The next attempt should inspect that status and follow a deliberate recovery rule instead of repeating every action.
Does this matter when my app does not accept payments?
Yes. Repeated notices can duplicate bookings, deliveries, account access, credits, stock changes, emails, and other saved customer actions.