# Payment or checkout problem on PrestaShop

> A customer who can't pay is a lost sale, and often a silently abandoned cart: they don't necessarily write in to complain. I diagnose the checkout step by step to find where it's actually blocking.

- Source canonique : [https://allaux.fr/en/prestashop/probleme-paiement](https://allaux.fr/en/prestashop/probleme-paiement)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Open Advanced Parameters > Logs and place a test order: the timestamped line shows whether the core or the payment module is failing. If no payment method appears at all, check the country, currency and customer-group restrictions in the module configuration. An order paid but left pending points to a server-to-server notification that never reaches the shop.

## What brings me onto this kind of case

- The payment button doesn't respond or returns a blank page
- A payment module (card, PayPal, bank transfer) has disappeared from checkout
- The customer is charged but the order stays "pending" in PrestaShop
- Error on return from the bank after 3D Secure authentication
- A carrier or payment method blocks another due to a misconfigured restriction
- Payment works in test but not in production, or the other way round

## Where it breaks most often

The PrestaShop checkout runs through several checks before showing payment methods: carrier, customer group, currency and delivery country restrictions. If one of these filters is misconfigured, the payment module disappears silently with no explicit error for the customer.

On the confirmation side, an order confirmation goes through the actionPaymentConfirmation hook and a call to validateOrder() on the payment module. When an order stays stuck as pending despite the bank accepting payment, the cause is almost always a webhook or server-to-server notification (IPN) that never reaches PrestaShop: a firewall at the host, a callback URL misconfigured in the payment provider's dashboard, or an invalid SSL certificate causing the call to fail.

Another classic case: a payment module update changes the API version used (for example a forced move to the latest Stripe SDK) without the configuration being revisited, which silently breaks card payments while leaving other methods active.

## How I diagnose

1. **Reproducing the customer journey** — I place a test order end to end, under the same conditions as the blocked customer (country, currency, cart, carrier).
2. **Checking the restrictions** — I check the payment module's restriction rules (groups, carriers, countries), which can hide a method without warning.
3. **Checking the webhooks** — I verify the payment provider's notifications actually reach the server, checking the module's logs and, if needed, the provider's dashboard.
4. **Testing under real conditions** — I check behaviour in production mode, not just the sandbox, since some blockers only appear with real API keys.

## FAQ

### Will an order that's paid but stuck as pending be charged twice to the customer?

No, the bank has already taken the money once. The problem is that PrestaShop never received confirmation, so the transaction needs to be manually matched and the order validated.

### Do I need to switch payment modules to fix this?

Rarely as a first move. In most cases the cause is a configuration or webhook issue, not the module itself. I only recommend switching if the module is genuinely abandoned.

### What access do I need to give you?

Back office access, FTP or SSH access, and if possible access to the payment provider's dashboard (Stripe, PayPal, etc.) to check the notifications sent.

### Do I risk losing orders during the work?

No, I work without interrupting the shop. Orders already recorded aren't touched, and checkout stays accessible during diagnosis except in exceptional cases, which I flag in advance.

### How long does it take to fix broken payments?

A restriction issue is the kind of problem that gets sorted the same day once back-office and server access are available. A webhook or SSL certificate problem depends on a third party, though: the timeline is the host's or the payment provider's response time, not mine.