It’s one of the messages online store owners dread most: “The money left my card but I can’t see my order.” In the admin, the order is either missing or stuck on “awaiting payment”, while the payment provider’s panel shows the transaction as successful.
We’ve dealt with this a lot. The good news is the cause is almost always one of a few known things. The bad news is that until someone notices, it can cost you a few orders every day.
First: how does the payment result reach your site?
In most payment flows the result reaches your site in two ways. First, after the payment and 3D Secure screens, the customer’s browser is redirected back to your site. Second, the payment provider sends a separate notification to your server (a callback, webhook or notification URL).
Most problems come from one of these two paths not working, or from the site relying on only one of them.
1. The order depends only on the browser coming back
If the site confirms the order only when the customer returns after paying, every customer who doesn’t return is a lost order. They may close the tab after 3D Secure, their phone may lock, their connection may drop. The money is taken but the site never hears about it.
The fix: confirm the order based on the server-to-server notification from the provider. Use the browser return only to show the customer a thank-you page.
2. The notification URL is wrong or unreachable
The notification URL in the provider’s panel may point to an old address. If the site moved from HTTP to HTTPS, the domain changed, or the test environment’s URL was left in place for production, notifications go nowhere.
Even with the right URL, your server may be rejecting the request. Security plugins, bot protection in services like Cloudflare or a server firewall can mistake the provider’s requests for suspicious traffic and block them. Checking which response the notifications got in the provider’s panel usually gives you the first clue.
3. Verification fails
A well-built integration checks that each notification really comes from the provider, using a signature or hash. If the API key was changed, or a test key was left in production, this check fails and the site rejects the notification. The result: payment successful, order in limbo.
If you’ve changed keys, check the settings on your site and in the provider’s panel together.
4. Caching and session problems
On sites that use page caching, odd things happen if the payment return page or the cart gets cached: the customer sees someone else’s empty cart, or the return request never reaches the application. Checkout, cart and account pages, as well as the notification URL, must always be excluded from the cache.
Similarly, some browsers may not send the session cookie when returning from an external site, so the customer looks logged out on return. Tying the order to the order number rather than the session removes this problem.
5. Timeouts and stock checks
Some systems cancel the cart after a set time or re-check stock when the payment returns. If the customer spent a long time on the 3D Secure screen, the order may have been cancelled and the item sold to someone else. The money is taken but the order couldn’t be created.
Two things help here: reserving stock for a short time while payment is in progress, and triggering an automatic refund, or at least an alert, when a successful payment arrives but no order can be created.
If it’s happening right now
- List the transactions that are successful in the provider’s panel but have no matching order on your site.
- Contact those customers right away and either create the order manually or refund them.
- Check what responses the notifications got in the provider’s panel (error codes, timeouts, 403s).
- Think back to recent changes: a plugin update, a domain or SSL change, a new security setting.
If you can’t find the cause yourself, reach us through emergency support or our contact page. We explain how we set up payment integrations properly on our payment gateway and virtual POS page.