# My customers can no longer pay or finish their order > A blocked payment is measured in hours, not days. The good news is the chain is short and each link fails with its own signature — including the checkout steps before payment, where plenty of orders actually stop. The bad news is that the first reflex — calling the bank — is almost always the wrong entry point, because the failure is rarely there. - Source canonique : [https://allaux.fr/en/problemes/mes-clients-ne-peuvent-plus-payer](https://allaux.fr/en/problemes/mes-clients-ne-peuvent-plus-payer) - Langue : EN - Dernière mise à jour : 2026-09-30 ## Direct answer > Place a one-euro test order to see which link breaks. If the payment method no longer appears at checkout, the cause is a restriction rather than the module: Payment > Preferences on PrestaShop filters by currency, country and customer group. If payment goes through but the order never comes back, it is the callback URL: read WooCommerce > Status > Logs or var/logs/ for the raw gateway response. ## The five links in the chain An online payment goes through five distinct stages. The payment module must appear among the offered methods. It must then build the request and redirect the customer, or display the entry form. The payment provider processes the transaction with the bank. It returns the customer to the shop. Finally it notifies the site through a technical call independent of the browser, and that call is what triggers recording the order. Each stage has its symptom. A payment method that no longer appears: the module has deactivated, or a display condition is no longer met. A redirected customer coming back with nothing: the return is misconfigured. A payment taken with no order recorded: the technical notification is not arriving. That last one is the costliest, because it stays invisible until a customer complains. ## What your customer describes - "There is no payment method at the final step": the module is not displaying — deactivated, incompatible after an update, or restricted by country, currency or amount. - "It spins and then goes back to the basket": the redirect to the provider fails, often because an identification key has expired. - "My card is refused": the transaction does reach the bank, the failure is downstream of the site. - "I was charged but got no confirmation": the return notification was not processed, the order stays pending. ## When the block sits before payment Before blaming payment, check that customers actually reach it. A checkout blocking at the address or delivery step produces exactly the same complaint — "I can't place an order" — with no payment module involved. The step where the stops concentrate almost always names the cause. At the basket: contents do not update, or disappear — a session or cookie problem, or a page cached when it must never be. At account creation: over-strict field validation, a confirmation email that never arrives, or an anti-robot check refusing everyone. At the address: format checks unsuited to some countries, or a required field made invisible by the theme. At delivery: no method offered for the weight, country or basket total — that is a carrier rule, not a failure. At the summary: a badly placed terms checkbox, or a validation button that only reacts on the second click. One last distinction avoids hunting a failure that does not exist. A decision not to buy spreads out: of a hundred visitors reaching the delivery step, some continue and some leave, which is worked on through price, lead times or clarity. A technical block does not spread: nobody gets through, or only visitors with a specific profile — a country, a browser, a delivery method, an amount. If the progression rate from one step to the next fell sharply on an identifiable date, it is technical; if it erodes slowly, it is commercial. ## A badly set consent banner blocks entire checkouts > When a banner delays loading of every script, including those the checkout and the payment module depend on, buttons stay inert until the visitor clicks. Behaviour then depends on the visitor's choice, producing an apparently random block that cannot be reproduced from a logged-in admin account. ## Isolating it in five checks 1. **Place a test order as a customer** — All the way through, logged out, in private browsing, on mobile and desktop, using the provider's test mode if available. A logged-in admin account bypasses rules that block everyone else, and the exact point where it stops is worth every report. 2. **Open the browser console** — A script error disables a button without showing any message on screen. It is the most frequent cause of an unresponsive validation button, and it leaves no trace on the server side. 3. **Open the provider dashboard** — It lists received transactions, including failed ones and why. If a transaction is there but not in the shop, the failure is in the notification. 4. **Check the keys and the mode** — A shop left in test mode takes no money. Test keys in production, or the reverse, cause systematic rejection. 5. **Check display restrictions** — Delivery country, currency, customer group, minimum amount, chosen carrier: each can hide a payment method with no error message at all. ## Payments taken with no order are invisible > When the return notification fails, money is taken and the order stays invisible in the shop. Comparing the provider’s transaction count with the shop’s order count for the same day is the only quick way to spot this. That gap should be checked as soon as any doubt arises about payment. ## Carry on with the right page - **Payment problems on PrestaShop** — PrestaShop-specific causes, module by module. ([/prestashop/probleme-paiement](/prestashop/probleme-paiement)) - **Payment problems on WooCommerce** — The WordPress equivalent, with its own specifics. ([/wordpress-woocommerce/probleme-paiement](/wordpress-woocommerce/probleme-paiement)) - **Configuring a payment webhook** — If the technical return notification is at fault. ([/guides/configurer-webhook-paiement](/guides/configurer-webhook-paiement)) - **The payment gateway explained** — The exact role of each party in a transaction. ([/glossaire/passerelle-de-paiement](/glossaire/passerelle-de-paiement)) - **The checkout explained** — The standard steps, and what each one actually verifies before letting a customer through. ([/glossaire/tunnel-de-commande](/glossaire/tunnel-de-commande)) ## FAQ ### My provider says everything works on their side. What should I check? Ask whether the attempted transactions appear in their log. If they do not, the request is not leaving the shop. If they do, the problem is in the return to your site. ### The payment method vanished after an update. Related? Very likely. A payment module hooks into precise points of the checkout; a core update can remove or rename those points, and the module then stops displaying with no visible error. ### Can I just uninstall and reinstall the module? Risky without precautions: some modules lose their configuration on uninstall, keys included. Note the settings first, and have a backup. ### Does fixing a blocked payment need development? Rarely. Most cases are configuration: keys, mode, restrictions, notification address. Development comes in when the module was edited directly in its code. ### How do I know whether orders were lost? By reconciling the provider’s transactions with the orders recorded over the same period. Any transaction with no matching order is a customer who paid and was not served. ### Customers say the button does nothing, but it works for me. Why? Because your browser has already loaded the files, and because a logged-in admin account does not apply the same display rules or restrictions. The block only reappears in the real conditions of an unknown visitor, often on mobile alone: a button covered by a floating element, a field unreachable on a touch keyboard, a heavy script that has not finished loading.