A serious payment-processing issue reported in PrestaShop 9.2.1 can cause successfully paid orders to be incorrectly marked as “Payment error.” The problem occurs when a product price changes while a customer is completing a transaction on an external payment provider’s website.
In the documented case, the customer paid the exact amount displayed at checkout, and the payment provider successfully processed the transaction. However, when PrestaShop created the order, it recalculated the shopping cart using updated product prices. Because the new total no longer matched the amount already paid, the system assigned the order an error status and sent the customer a payment failure notification.
The issue was reported to the PrestaShop project on November 12, 2026. It was observed in a production store using PrestaShop 9.2.1 and the Viva.com Smart Checkout payment module. The merchant reported approximately one affected order per 5,000 payments processed through this integration.
This creates a particularly dangerous situation for online retailers: a customer may receive an email indicating a failed payment even though the money has already been collected. Meanwhile, the order may require manual intervention before it can be processed correctly.
What Is the PrestaShop 9.2.1 Payment Error Bug?
The problem is documented in PrestaShop GitHub issue #43521 – Order goes to “Payment error” if a product price changes while the customer is paying on an external payment page.
The reported behaviour involves a payment gateway that redirects customers to an external payment page and creates the PrestaShop order only after the payment has been confirmed.
This type of integration generally follows several steps:
- The customer adds products to the shopping cart.
- PrestaShop calculates the total amount payable.
- The payment module sends that amount to an external payment provider.
- The customer completes the payment on the provider’s website.
- The payment provider confirms the transaction.
- The payment module calls PrestaShop to create the order.
The problem occurs between steps three and six.
While the customer is completing the payment, the prices stored in the PrestaShop product catalogue may change.
When the customer returns to the store, or when a payment notification is processed, PrestaShop calculates the shopping cart total again using the prices currently stored in the system.
If the recalculated value differs from the amount that the customer actually paid, PrestaShop can create the order with the status:
Payment errorInternally, this corresponds to the order state configured as:
PS_OS_ERRORThe payment provider may have processed the transaction successfully. The problem is that PrestaShop no longer agrees with the amount that was originally presented to the customer.
Exact Error Message in PrestaShop Logs
The original report identifies the following log entry:
PaymentModule::validateOrder - Total paid amount does not match cart totalThis message is generated during the order validation process when the amount passed to the payment module does not match the cart total recalculated by PrestaShop.
It is important to distinguish this condition from a payment provider rejecting a transaction.
The message does not necessarily indicate that the customer’s card was declined, that the payment gateway failed or that the money was never transferred.
In the documented case, the external payment was successful. The mismatch was created by a product price change during the payment process.
Confirmed Case: Customer Paid €20.24 but PrestaShop Recorded €21.22
The merchant who reported the issue provided a real example involving Viva.com Smart Checkout.
At the moment the customer started the payment, the total amount payable was €20.24.
The payment provider received this amount, displayed it to the customer and processed the transaction successfully.
However, before PrestaShop completed the order validation process, one of the product prices changed.
When the payment module called PaymentModule::validateOrder(), PrestaShop recalculated the shopping cart and obtained a new total of €21.22.
| Payment information | Amount |
|---|---|
| Amount displayed to the customer | €20.24 |
| Amount successfully paid | €20.24 |
| Recalculated PrestaShop order total | €21.22 |
| Difference | €0.98 |
| Resulting order status | Payment error |
PrestaShop saved the two different amounts in separate order fields.
total_paid = 21.22
total_paid_real = 20.24The first value represented the recalculated order total, while the second represented the payment amount reported by the payment integration.
Because the values were different, PrestaShop flagged the order as a payment error.
The customer received an error email despite having successfully paid the amount shown at the beginning of the payment process.
The merchant then had to correct the affected order manually.
Why Can Product Prices Change During Checkout?
Product prices in an e-commerce store are not always static.
Many stores regularly update prices through integrations with inventory management systems, ERP software, supplier feeds or automated pricing tools.
A price may change while a customer is on an external payment page for several reasons.
Automatic ERP Price Synchronisation
Some retailers synchronise product prices with their ERP systems several times per day.
If an external system updates a product price while a customer is completing payment, the amount stored in PrestaShop may no longer match the amount already sent to the payment provider.
This was particularly relevant in the reported production environment, where prices were updated automatically through the PrestaShop webservice.
Manual Price Changes in the Back Office
An administrator may edit a product price while another customer is completing a purchase.
The administrator does not necessarily know that a customer has already started an external payment using the previous price.
If the order has not yet been created, the price change may affect the subsequent cart calculation.
Scheduled Promotions
Catalogue price rules and specific prices may become active or expire at predetermined times.
For example, a promotion could end while a customer is completing a payment that began before the promotion expired.
If the shopping cart is recalculated after the discount expires, the new total may differ from the amount already paid.
Supplier Imports and Automated Price Updates
Stores with large catalogues frequently import updated prices from suppliers.
When such imports run during normal trading hours, there may be a short interval in which customers are completing payments based on prices that have just changed in the catalogue.
The risk is particularly relevant when the payment process involves redirecting the customer to another website.
The Technical Cause: PaymentModule::validateOrder() Recalculates the Shopping Cart
The reported issue is associated with the way PrestaShop stores shopping cart information and validates payments.
A PrestaShop cart contains references to products and quantities. It does not necessarily preserve an immutable snapshot of every product price from the moment the customer starts paying.
When the payment module begins the transaction, it calculates the total using:
Cart::getOrderTotal(true, Cart::BOTH)The resulting amount is passed to the external payment provider.
After successful payment, the module calls:
PaymentModule::validateOrder()The payment module supplies the amount associated with the completed transaction.
However, PrestaShop calculates the current cart total again and compares that result against the amount supplied by the payment module.
If the two values are different, the order validation process can assign the Payment error state.
How the Amount Comparison Works
The relevant validation logic compares two values:
$cart_total_paid– the total recalculated from the shopping cart.$amount_paid– the amount passed to the validation method by the payment module.
The comparison takes the configured calculation precision into account.
If the values do not match and the initial order state is loggable, PrestaShop records the amount mismatch and selects:
Configuration::get('PS_OS_ERROR')as the resulting order status.
This mechanism is intended to identify transactions where the payment amount does not match the order total.
Such validation is an important protection against incorrect amounts being accepted.
The problem arises when the comparison is performed against a newly calculated total rather than the amount originally agreed upon by the customer.
In this situation, a legitimate payment can appear inconsistent because the underlying product prices changed during the transaction.
Why This Is More Than a Viva.com Payment Module Issue
The confirmed report concerns Viva.com Smart Checkout version 2.0.1.
However, the reporter identified the suspected cause in PrestaShop’s core order validation logic rather than in the actual payment processing performed by Viva.com.
The behaviour could potentially affect other payment integrations that follow the same sequence:
- Calculate the cart amount.
- Send the customer to an external payment provider.
- Wait for successful payment confirmation.
- Create the order only after that confirmation.
Other redirect-based payment systems, including some PayPal integrations, may use comparable processing models.
However, this does not establish that all PayPal modules or all external payment gateways are affected.
The exact outcome depends on the module’s implementation, the timing of order creation and how payment amounts are preserved.
PrestaShop’s official documentation for payment modules describes different payment integration models, including external payment providers that redirect customers away from the store.
It also explains that modules creating an order after payment confirmation should use the amount supplied by the payment provider when calling validateOrder(), rather than recalculating the payment amount from the current cart.
This distinction matters because the transaction amount must represent the payment that actually occurred.
Why Bank Transfer and Cheque Payments May Not Show the Same Problem
The original report also explains why the behaviour is less likely to occur with certain offline payment methods.
Bank transfer and cheque payment modules commonly create the order immediately during the checkout request.
The cart amount is calculated and the order is created during the same operation.
There is no extended period in which the customer is redirected to an external payment page before order creation.
Consequently, the specific timing problem described in the report is less likely to occur.
This does not mean that offline payment methods are immune to all pricing or order validation problems. It means that their typical processing sequence does not expose the same interval between the original amount calculation and order creation.
How Can This Bug Affect Online Sales?
The immediate issue is an incorrect order status, but the operational consequences can extend beyond the payment confirmation screen.
Customers Receive Incorrect Payment Failure Emails
In the reported case, customers received an email indicating that their payment had failed.
However, the payment provider had already collected the agreed amount.
This can create confusion and unnecessary customer support requests.
A customer may contact the merchant, check their bank account or assume that another payment is required.
Risk of Unnecessary Payment Attempts
When customers receive a payment failure notification, they may attempt to pay again.
If the first transaction actually succeeded, another payment attempt could create an additional charge.
The original report does not demonstrate that PrestaShop automatically charges customers twice because of this bug.
The additional-payment risk arises primarily when the customer or store operator incorrectly interprets the Payment error status as proof that no payment was collected.
Orders May Require Manual Intervention
The affected merchant reported that incorrectly flagged orders had to be corrected manually.
Before an order can be processed normally, staff may need to confirm the payment with the provider and reconcile the amount recorded in PrestaShop.
For stores with high order volumes, even a relatively infrequent problem can generate additional administrative work.
Fulfilment Automation May Be Interrupted
Some stores use order status changes to trigger fulfilment, warehouse operations, customer notifications or ERP synchronisation.
An order incorrectly marked as Payment error may not enter the expected processing workflow.
The actual impact depends on the integrations and order status rules configured in each store.
Payment and Order Totals May No Longer Agree
The documented case contained different values in total_paid and total_paid_real.
These discrepancies may complicate payment reconciliation and require investigation before the order can be treated as correctly settled.
How Common Is the PrestaShop Payment Error Bug?
The merchant who submitted the report stated that approximately one order in every 5,000 payments was affected in their store using the Viva.com Smart Checkout integration.
The issue was associated with a catalogue that receives several automated price updates per day.
This figure is specific to the reporting merchant.
It is not an official PrestaShop-wide incident rate and does not establish how frequently the problem occurs in other stores.
The frequency may vary depending on:
- How often product prices change.
- How long customers remain on external payment pages.
- The payment module’s order creation workflow.
- Whether promotions start or expire during checkout.
- How frequently ERP systems synchronise prices.
- Whether the integration preserves a fixed transaction amount.
As of November 13, 2026, no independently verified data establishes the overall number of affected PrestaShop stores.
How to Diagnose Incorrect Payment Error Orders in PrestaShop
Store administrators should investigate suspicious Payment error orders by comparing PrestaShop’s recorded order amounts with the actual transaction data held by the payment provider.
1. Check the Order Status in the Back Office
Open the PrestaShop administration panel and navigate to the orders section.
Look for orders marked:
Payment errorPay particular attention to orders where the customer claims that payment succeeded or where the payment provider shows a completed transaction.
Record the order reference, cart ID, transaction date, payment method, currency and amounts.
2. Search PrestaShop Logs for the Exact Error
Look for the following message:
PaymentModule::validateOrder - Total paid amount does not match cart totalThe message indicates that PrestaShop detected a mismatch during order validation.
It does not, by itself, establish that the payment provider failed.
The next step is to determine why the amounts differ.
3. Compare total_paid and total_paid_real
Administrators with database access can perform a read-only inspection of orders where the recorded totals differ.
For example:
SELECT
id_order,
reference,
id_cart,
payment,
total_paid,
total_paid_real,
current_state,
date_add
FROM ps_orders
WHERE ABS(total_paid - total_paid_real) >= 0.01
ORDER BY date_add DESC;The query does not modify database records.
If the installation uses a custom table prefix, replace ps_ with the configured prefix.
Differences between these amounts are useful diagnostic indicators, but they are not exclusive to the issue described here.
Unpaid orders, partially processed payments and certain custom payment workflows can also produce differing totals.
Each suspicious order must be checked individually.
4. Verify the Payment Provider’s Transaction
Open the transaction in the payment provider’s dashboard.
Check:
- The unique transaction identifier.
- The amount actually charged.
- The payment currency.
- The transaction status.
- The date and time of payment.
- Any refunds or reversals already issued.
Confirm whether the transaction was genuinely successful before changing an order status or asking the customer to make another payment.
5. Check Product Price History
Investigate whether product prices changed between the moment the customer started the external payment and the moment PrestaShop created the order.
Depending on the store’s configuration, useful sources may include ERP synchronization logs, import history, webservice request logs, promotion schedules and administrative change records.
PrestaShop does not necessarily retain a complete historical record of every product price modification by default.
If no price history is available, investigate the timing of scheduled updates and the data recorded by the external integration.
6. Review the Payment Module’s Order Creation Workflow
Determine whether the payment module creates the PrestaShop order before or after the customer completes payment.
Modules that create orders only after successful payment confirmation may be exposed to changes occurring during the external payment process.
Review how the module calculates and preserves the transaction amount.
Do not assume that a module is defective simply because it uses an external payment page. The issue depends on the interaction between the module, PrestaShop’s cart calculations and the timing of price changes.
How to Reproduce the Problem in a Test Environment
The original reporter provided a reproducible scenario using Viva.com Smart Checkout in demo mode.
The test requires a non-production PrestaShop environment and a payment gateway configured for test transactions.
- Install a payment module that redirects customers to an external payment page and creates orders after confirmation.
- Add a product priced at €10.00, including tax, to the shopping cart.
- Proceed to checkout and select the external payment method.
- Open the payment provider’s page but do not complete payment immediately.
- In the PrestaShop back office, change the product price to €11.00.
- Return to the external payment page and complete the transaction using test credentials.
- Inspect the resulting order status and PrestaShop logs.
In the reported test, PrestaShop generated the Payment error state because the previously agreed amount differed from the recalculated cart total.
The same underlying behaviour can also be examined programmatically by calculating a cart amount, changing a product price and subsequently calling the order validation method with the original amount.
Such tests should not be performed with real customer transactions.
How to Prevent Successfully Paid Orders From Being Marked as Failed
As of November 13, 2026, there is no confirmed official PrestaShop core fix for issue #43521.
However, several operational measures may reduce exposure to the reported scenario.
Avoid Price Updates During Active Payment Sessions Where Practical
Stores with frequent automated price updates can review when synchronisation jobs run.
For example, major catalogue updates may be scheduled during periods of lower payment activity.
This is not a guaranteed fix because customers can still be completing payments at any time, especially in stores operating internationally.
It can nevertheless reduce the likelihood of a product price changing during an external payment session.
Review Transaction Amount Preservation
The proposed architectural solution is to preserve the amount agreed upon when the customer starts payment.
This may involve storing an immutable payment amount and appropriate pricing information associated with the cart or payment session.
The preserved data must remain consistent with the actual transaction processed by the payment provider.
Any implementation also needs to consider taxes, discounts, delivery charges, currency conversions, security validation and the possibility of an interrupted payment session.
Simply disabling PrestaShop’s amount comparison is not an appropriate solution.
The validation protects against genuine inconsistencies and should not be removed without an equivalent safeguard.
Improve Payment Reconciliation
Stores using external payment providers should have a process for identifying orders where payment data and order status disagree.
A useful reconciliation process compares:
- PrestaShop order references.
- External transaction identifiers.
- Amounts actually charged.
- Order totals.
- Payment currencies.
- Current order states.
When inconsistencies are detected, the transaction should be reviewed before any additional payment request is issued.
Use Safe Manual Correction Procedures
If payment is confirmed but the order is incorrectly marked as failed, the merchant may need to correct the order manually.
Before changing the status, verify the actual payment and determine whether the recorded order total requires a separate correction.
Changing the order status alone does not necessarily resolve an inconsistency between the amount paid and the total recorded for the order.
Any adjustment should preserve an accurate transaction history and comply with applicable accounting and tax requirements.
Why Automatically Changing Payment Error to Payment Accepted Is Unsafe
A tempting workaround would be to automatically convert every Payment error order into a successful payment state.
This would be dangerous.
The Payment error state can also occur when a customer genuinely pays an incorrect amount or when a payment integration reports inconsistent transaction data.
Automatically accepting all such orders could conceal genuine underpayments or other payment problems.
A safer approach is to verify the amount actually received from the payment provider and compare it with the amount the customer agreed to pay.
Only after that confirmation should the merchant determine the appropriate order state and whether additional reconciliation is required.
Is There an Official Fix for PrestaShop 9.2.1?
The issue was opened on November 12, 2026, and added to PrestaShop’s core bug tracking project.
As of November 13, its status is:
Waiting for QANo official pull request addressing the reported scenario is linked to the issue, and no confirmed stable release containing a fix has been identified.
The report provides a reproducible scenario and a detailed explanation of the suspected core-level cause.
However, it has not yet been independently confirmed by the PrestaShop QA team in the public issue.
Administrators should monitor the original GitHub report for technical confirmation, any proposed code changes and information about a future stable release.
Does the Problem Affect Every PrestaShop Payment Gateway?
No. The confirmed case involves Viva.com Smart Checkout 2.0.1.
Other payment modules may use different approaches to order creation and payment confirmation.
Some integrations create an order before the customer reaches the payment provider, while others create it only after receiving confirmation.
The exact behaviour depends on the module implementation.
The reported bug may affect other redirect-based payment gateways that calculate an amount before redirecting the customer and then create the order after payment using a cart that can be recalculated.
However, the public report does not independently confirm the same failure in every PayPal, Stripe or other payment integration.
Frequently Asked Questions
Why does PrestaShop show Payment error when the customer has already paid?
One possible cause is a product price change during an external payment session. PrestaShop may recalculate the cart after successful payment and mark the order as failed if the new total differs from the amount already paid.
What does PS_OS_ERROR mean?
PS_OS_ERROR is the PrestaShop configuration key identifying the order state used for payment errors. It does not always mean that a payment provider rejected the transaction.
What does “Total paid amount does not match cart total” mean?
The message indicates that the payment amount passed to PrestaShop’s order validation method differs from the cart total calculated by the application.
Which PrestaShop version was affected?
The reported production environment used PrestaShop 9.2.1 with PHP 8.5 and 8.1. The issue was observed with Viva.com Smart Checkout 2.0.1.
Can automatic ERP price updates trigger the error?
Yes. The reporting merchant used frequent webservice-based price synchronisation, and changes to product prices during external payments were identified as the trigger.
Can scheduled promotions cause the same problem?
Potentially. A promotion beginning or ending during a payment session can change the recalculated cart amount. The original report identifies catalogue and specific price rules as possible triggers.
Does Payment error mean the customer must pay again?
No. The actual transaction status must be checked with the payment provider before asking for another payment.
Can the issue cause double charging?
The reported bug does not demonstrate automatic double charging. However, an incorrect payment failure notification could lead a customer to attempt another payment despite already having paid successfully.
Should merchants disable payment amount validation?
No. Payment amount validation is an important safeguard. Removing it could allow genuinely inconsistent transactions to be treated as valid.
Is there a confirmed PrestaShop fix?
As of November 13, 2026, issue #43521 remains at the Waiting for QA stage. No confirmed official fix is available in the public report.
What PrestaShop Store Owners Should Do Now
PrestaShop 9.2.1 store owners using external payment gateways should pay particular attention to orders marked as Payment error when the payment provider reports a successful transaction.
The risk is especially relevant for stores that automatically update prices through ERP integrations, supplier imports, webservices or scheduled promotional rules.
If an affected order is found, the first priority is to verify whether the customer actually paid. The payment provider’s confirmed transaction details should be compared with PrestaShop’s recorded order amounts and any product price changes that occurred during checkout.
Do not automatically request another payment or mark an order as unpaid solely because PrestaShop displays an error status.
Until the underlying issue is resolved, reliable payment reconciliation, careful management of automated price updates and monitoring of order validation errors are important safeguards against unnecessary customer disputes and interrupted order fulfilment.
The incident highlights a broader requirement for reliable e-commerce payment processing: once a customer has accepted a payment amount and the transaction has been processed, subsequent catalogue price changes should not silently invalidate the original commercial agreement.
For stores using asynchronous payment confirmation, protecting the consistency between the agreed transaction amount, the payment provider’s records and the final order is essential.
0 comments