An order should move forward because the server has verified the payment, not because a browser reached a confirmation screen. Build for duplicate notifications, interrupted connections and payment states that need checking.
A customer pays, closes the browser and calls later to ask why the order is still pending. Another customer receives two confirmation emails for one purchase. Neither problem necessarily starts in the checkout design. Both can come from the way payment updates reach the store.
For a UAE eCommerce business, that connection matters well beyond the payment screen. It can affect stock, fulfilment, customer support and finance. Here's what to look at when commissioning a gateway integration or investigating one that isn't behaving reliably.
The customer journey and the payment record are different things
The browser may disappear at any point. The customer could lose connectivity, close a tab or never return from the payment provider. Your application still needs to find out what happened.
Define the states your order system needs: awaiting payment, confirmed, failed, refunded and any other relevant outcomes. Keep the provider's transaction reference linked to the local order. If the final result isn't available yet, show a truthful pending message rather than guessing.
A browser parameter saying “success” should not, by itself, tell the warehouse to ship. Use the provider's supported server-side verification process.
Check the event before acting on it
A webhook is a request sent to your application about an event. Before trusting its contents, verify that it is authentic using the gateway's documented procedure. Familiar-looking JSON isn't proof that the request came from the provider.
Stripe's documentation covers signature verification, duplicate events and delivery behaviour. It is the technical reference used here, not a template for every UAE gateway. Follow your chosen provider's requirements for signatures, request bodies, retry behaviour and test-versus-live configuration.
Assume the same notification may arrive again
If an acknowledgement gets lost, a provider may retry delivery. The second copy shouldn't create another shipment instruction or credit the account twice. Keep a durable record of processed event identifiers and enforce the necessary uniqueness rules.
Also test two copies arriving together. A simple “have we seen this?” check can fail if both requests run before either writes its result. The protection needs to hold under concurrency, not just in a slow demonstration.
Different events can also refer to the same payment. Decide which verified state transition is responsible for fulfilment, so each event doesn't independently trigger it.
| Try this | What should happen? | Where to check |
|---|---|---|
| Deliver one event twice | One business action | Processing record |
| Change the event order | A valid payment state remains | State history |
| Interrupt a background job | The work can be recovered | Queue and retry status |
| Close the customer browser | The server still resolves the payment | Order and transaction records |
A quick response must not mean lost work
Keep the receiving endpoint focused on validation and durable acceptance. If you process events in the background, safely record or queue the work before acknowledging it. Responding quickly is useful only if the event won't vanish afterwards.
Emails, inventory updates and document generation can take longer. Give those jobs controlled retries and a visible failure queue. Someone should own that queue and know how to replay work without repeating an action that already succeeded.
Give operations a way to resolve the uncertain cases
Reconciliation means comparing local records with the provider's supported transaction records. Use it to find orders left pending, mismatched amounts or currencies, and later changes such as refunds.
Staff need readable references, timestamps and a clear next step. They don't need unrestricted copies of sensitive payment data in general application logs. Agree what information finance and customer support actually require.
Ask for more than a successful test payment
Before signing off, ask the developer to demonstrate invalid, delayed, duplicate and interrupted delivery. Involve the people who fulfil orders and answer payment queries; they will have to use the recovery process.
For a Gligx website or checkout project, bring the selected gateway and your order process to the first discussion. Reliability is easier to build into the scope than to add after customers encounter the gaps.
Sources and further reading
References checked on 23 October 2026.
Frequently Asked Questions
Can we fulfil an order when the customer reaches the success page?
Don't use the browser redirect alone. Verify the payment through the gateway's supported server-side process before triggering fulfilment.
Why would a gateway send the same event twice?
It may retry when an acknowledgement fails or times out. Your application needs to accept that possibility without repeating the business action.
What does idempotent processing mean for our store?
Receiving the same event again shouldn't create another shipment, add credit twice or repeat another action that already succeeded.
Can we copy one gateway's webhook handling to another?
Not without checking the differences. Event types, signatures, retries and reconciliation rules vary by provider.