Available for projects & agency overflow · Quick reply, from the person who does the work

Send a message contact@allaux.fr
FR EN TR
allaux.
Emergency Discuss my project

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.

Describe my issue Send a message

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.

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.

Carry on with the right page

Describe your need in one minute

A few targeted questions so I can reply with an estimate rather than another questionnaire.

etat
plateforme
declencheur
acces (facultatif)
url (facultatif)
Please provide an email or a phone number so I can get back to you.

Please provide an email or a phone number so I can get back to you.

Frequently asked questions

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.

Related pages