When payments stop working on a PrestaShop store, the risk is not only technical. The immediate risk is lost orders while you test several leads at once.
The most useful approach is to follow a short order: identify the exact symptom, check whether the module is in test or production mode, verify API keys, confirm notifications or webhooks, review compatibility after any update, then consult the logs. By the end of this guide you’ll know what to check without muddying the diagnosis, what to do immediately to limit losses, and when to switch to a PrestaShop payment bug diagnosis.
Start by identifying the type of failure
Before taking any action, separate the failure into families of symptoms. A missing payment method, a click that fails, and a payment accepted without an order follow different technical logic. If you mix these cases you risk fixing the wrong layer.
This step also helps you determine whether you’re facing a display issue for the payment method, a blockage in the checkout flow, or a failure in the return from the payment provider to the shop. If you suspect the whole checkout, also check cart and checkout failures on PrestaShop.
The payment method has disappeared at checkout
Here the customer cannot even reach the payment confirmation step. The symptom is visual: the method no longer appears, or appears only in certain flows. Note immediately whether the disappearance affects all customers, all carriers, all countries, or only a specific case.
In this situation, don’t start with webhooks. First check what controls the display of the payment method: module status, recent configuration changes, and any changes to the shop-side checkout flow.
The button is visible but payment fails on click or redirect
Second case: the payment method is present, but the click returns an error, a loop, a failed redirect or an immediate decline. The first causes to check are test vs production mode, then API credentials.
Don’t conclude too quickly that the module is defective. An incorrect environment or mismatched key can produce exactly this type of symptom.
Payment accepted by the PSP but no order appears in PrestaShop
This is the most sensitive case. The customer has paid and the payment provider reports a successful transaction, yet no order is created, or the order status remains inconsistent. Here you must think about the technical return from the PSP to PrestaShop, not just the payment click.
The right reflex is to set aside the front office and inspect notifications, webhooks and event logs.
Check test or production mode first, then the API keys
This is the first triage to perform. Until you have validated the environment and credentials, it’s too early to blame an update or a deeper bug. This check takes little time and avoids many back-and-forths.
Spotting a mix between test and production
The classic trap is simple: a module set to production with test credentials, or vice versa. PayPal also reports that mixing sandbox and production is a common cause of authentication or configuration errors. Stripe clearly distinguishes test and live keys in its official documentation Authentication | Stripe API Reference (consulted 27/10/2026).
On Stripe, a test secret key begins with sk_test_, a live secret key with sk_live_, and a live restricted key with rk_live_. If these prefixes do not match the mode enabled in the module, you have a solid lead.
Verify keys and credentials without confusing them
Compare what is stored in the module with what is expected in the correct environment of the PSP account. The aim is not to replace values at random, but to ensure each credential matches the active mode.
Work neatly. Record the current settings before any modification so you can return to the last known working state if needed.
Check whether a recent change overwrote the configuration
If the failure appeared immediately after an intervention, update or migration, assume a setting may have been altered. A payment module can remain active yet lose part of its configuration.
Ask yourself a simple question: what changed since the last successful payment? This step prevents launching an overly broad investigation.
If the payment goes through but the order doesn’t arrive, check notifications and webhooks
When the customer pays but PrestaShop doesn’t create the order, the issue is not always at the moment of the click. It can lie in the feedback sent by the payment provider to the shop. This type of incident therefore needs separate handling.
What a missing webhook actually breaks
A webhook that doesn’t arrive, responds badly, or points to the wrong URL can prevent the shop from receiving the information expected after payment. For PayPal, documentation specifies that a webhook URL must be registered, linked to an event subscription, have a Webhook ID, listen on HTTPS port 443 and respond with an HTTP 2xx code. Otherwise PayPal retries up to 25 times over 3 days Integrate webhooks | PayPal Developer (updated 18/06/2026).
In other words, a payment may appear successful on the PSP side while the shop has not received, or has not correctly validated, the event that should create or update the order.
What to check on the PayPal side
First check the URL actually declared, then the subscription to the expected events, then the webhook identifier used by the module. If the module verifies the signature, it must rely on the correct webhook ID and on the raw request body.
Do not limit yourself to the mere existence of the webhook. A webhook present but misattached, or one that does not respond correctly, often produces the same business result: payment received, order missing or incomplete.
Why a simulation is not enough
A simulated test can give false reassurance. It may help validate a listener, but it does not prove that real production events reach the module in your actual chain.
If in doubt, start from a recent transaction, locate the real event on the provider side, then compare it with what the shop recorded. That is the most reliable check.
Then check what changed just before the failure
Payment failures that appear without an obvious cause often follow a recent change: PrestaShop update, module update, reactivation of an old setting, or environment modification. The most profitable step is therefore to review the immediate history.
After a PrestaShop update, recheck the Module Manager
PrestaShop official documentation recommends, after an update, to check the Module Manager, reactivate any disabled modules if necessary, then test the front office with a real checkout flow Post-update checklist | PrestaShop Developer Documentation (consulted 27/10/2026).
On a production shop, check whether the payment module was disabled, whether another checkout module changed state, and whether the issue appeared immediately after that intervention.
Review module compatibility and sensitive settings
If the failure started after a change to the shop, compare your PrestaShop version with the compatibility announced by the module, then reread the sensitive settings. A module declared compatible with a given version should not be considered automatically reliable after every update.
If you want to spot this type of risk before it breaks your checkout, also read signs of a badly coded PrestaShop module.
Test the whole checkout, not just the payment button
A module may appear active yet fail only in the real flow. That’s why a full checkout test remains useful after an update: cart, address, carrier, payment, confirmation return.
Avoid the sweeping statement “the update broke payments”. The right question is more precise: which change made this module, in this checkout, incompatible or misconfigured?
Read useful logs before enabling debug everywhere
When the previous checks yield nothing, move to the logs. This step returns you to facts: error message, exact moment, and the component concerned. PrestaShop provides a Logs page in the back office to view errors and shop actions Logs | PrestaShop 8 documentation (consulted 27/10/2026).
Where to look first
Start by noting the time of a real failure, then search that window in the shop logs and in the module logs if the provider supplies them. The aim is not to read the entire log, but to correlate a specific attempt with a specific message.
If the failure triggers a broader server error, the method is similar to an Internal Server Error 500 diagnosis on PrestaShop: isolate the moment, the component, then the recent change.
When to enable debug mode
Debug mode can help, but it’s not the first lever. Enable it only if the logs are insufficient, and only for the duration of the diagnosis. PrestaShop documentation notes that it has a significant performance impact. Once you have the useful message, switch it off.
This rule is important in production: debug should confirm a lead, not replace a triage method.
What to correlate between shop, module and PSP
A clean diagnosis does not rely on a single source. Check together the time of the customer action, any error on the shop side, the state reported by the module, and the event visible at the PSP. Without this correlation you may confuse a click refusal with a missing webhook.
At this stage, resist the temptation to disable multiple modules in production “to see”. You would muddy the diagnosis and lose the trace of the initial cause.
During the outage, limit losses and decide quickly whether to escalate
During the incident your objective is twofold: avoid making the outage worse and keep an actionable record of pending payments.
- Disable only the faulty payment method if it produces repeated errors. Do not touch several modules at once.
- If another payment method remains available, keep it active to reduce immediate loss.
- Show a short, clear message at checkout to explain that a temporary incident affects a specific payment method.
- Monitor payments captured without an order and prepare a simple list: time, amount, customer, state at the PSP, state in PrestaShop.
- Reconcile pending cases manually until the automatic chain is reliable.
If triage in this order is not sufficient, it’s better to move to a targeted intervention. KLN-WEB offers one-off or monthly PrestaShop support, with a free diagnosis, response within 24 hours and a quote within one working day.
Frequently asked questions
Why has the payment module disappeared at checkout on PrestaShop?
When a payment method disappears, treat the issue first as a display or availability defect in the checkout, not as a webhook problem. Check whether the disappearance affects all customers or only certain flows. Distinguishing this from a payment accepted without an order prevents you searching in the wrong place.
How can I tell if my module stayed in test mode instead of production?
Compare the mode set in the module with the environment used in your PSP account. On Stripe, test secret keys begin with sk_test_ and live keys with sk_live_. If the module is in production with test keys, or vice versa, the payment may fail immediately even though the configuration looks correct.
Where should I check Stripe or PayPal API keys when payment fails?
Check in two places: the payment module configuration in PrestaShop, and the correct environment in your Stripe or PayPal account. The key point is consistency between the active mode and the stored credentials. Before changing anything, record the current settings so you can revert to the last known working state.
Why is payment accepted by the bank or PSP but the order does not appear in PrestaShop?
This case often points to a technical return problem between the payment provider and the shop. You should then check notifications or webhooks, the declared URL, subscription to the expected events, and how the module processes that return. A payment validated by the PSP doesn’t by itself guarantee PrestaShop received the event required to create the order.
What should I check immediately after updating PrestaShop or the payment module?
After an update, first check the module status in the Module Manager, then its declared compatibility with the shop version. Next, run a real checkout flow on the front office. The key is not to jump to the conclusion that the update “broke” payments without identifying the specific setting or incompatibility involved.
Where can I find useful logs in PrestaShop to diagnose a payment failure?
PrestaShop offers a Logs page in the back office. Use a simple method: note the exact time of a failure, then look for corresponding entries in the shop logs, the module logs and the payment provider logs if available. If you enable debug mode, do so only for the duration of the diagnosis and then disable it immediately.