Testing PrestaShop 9.2 One Page Checkout: A Practical QA Plan

Checkout testing should prove that the final order matches the customer’s latest valid choices. A green confirmation screen is insufficient if the wrong carrier, address, tax amount or payment state reaches the Back Office.

This plan is for PrestaShop 9.2 RC1 on an isolated test installation. Record the exact checkout-module, theme and payment-module versions alongside the core version. The official checkout documentation makes module compatibility a specific concern; its implementation can evolve independently of assumptions in a store’s custom scripts. Module integration reference.

The cases below are proposed tests. They are not claims that these combinations have already passed.

Start by understanding how native One Page Checkout changes buying; the acceptance plan should cover the checkout you intend to use, including its payment and delivery integrations.

Build fixtures that make incorrect results obvious

Use a small, deliberately varied catalog: a normal physical item, a restricted-delivery item, a product with combinations and, if sold by the shop, a virtual item. Set stock and prices to known values. Avoid a large random catalog that makes every failure difficult to explain.

Create a guest, a registered customer with one address and a registered customer with multiple addresses. Use synthetic details. Define at least two destinations with different delivery eligibility. If tax treatment differs between them, have the merchant’s configured expected calculation available before running the test.

Create a shipping threshold and vouchers that exercise the rules your store actually uses. Do not assume the order in which discounts and thresholds should apply; write down the intended configuration and expected total for each fixture.

For every test, retain:

• Core, theme and module versions, plus shop and language context.
• Starting cart, customer state and relevant configuration.
• Exact actions, expected results and actual results.
• Cart and order identifiers, payment sandbox reference and timestamps.
• Redacted screenshots or request traces when needed to explain a failure.

A screenshot is useful evidence of what the customer saw. The order record and payment result establish what the store committed. Capture both.

Test customer identity as a state transition

Guest completion

Start in a clean browser session. Add a product, enter valid contact and address information, choose delivery and complete a sandbox payment. Assert that one intended order is created, the customer details are correct and the recorded amount matches the final summary.

Repeat with one required field missing. The checkout should identify the problem without discarding unrelated valid input. Correct the field and submit again. A validation failure must not leave a hidden partial order that later creates a duplicate.

Returning customer

Sign in with an account containing two addresses. Select the non-default address and complete the order. Verify the destination in the saved order, not just the selected radio button.

Then begin another cart, change identity through the supported login or logout flow and return to checkout. Check that customer-specific addresses, prices and delivery choices belong to the current identity. Do not accept a previous customer’s visible address as a harmless display issue.

Refresh and navigation

Refresh after entering an address, after choosing delivery and after returning from a cancelled payment. Use the browser’s back action where the flow permits it. The expected persistence policy should be documented, and the customer should be able to recover without unknowingly paying twice.

Make address changes invalidate dependent choices correctly

The important scenario is not simply entering two addresses. It is changing the address after the checkout has already derived other state.

Run one rapid-edit case as well: change a relevant field twice before the first update completes. The final displayed and persisted state should correspond to the last accepted input. Browser network throttling can help expose an ordering problem without requiring access to module internals.

If a failure occurs, retain the sequence and timing. “Shipping is wrong” gives a developer little to reproduce; “country changed after pickup selection, then the old option remained in the order” is actionable.

Exercise shipping, vouchers and taxes together

Shipping and promotions often fail at boundaries. Put the cart just below the configured free-shipping threshold, reach the threshold, then move below it again. Apply and remove the relevant voucher at each meaningful point.

Do not merely assert that the total changes. Check the amount against your independently prepared fixture calculation and inspect the shipping line in the resulting order. A visually plausible total can still be wrong.

For carrier modules, select a pickup location or delivery date if those features are used. Change carrier, then change back. Verify that any restored selection remains valid for the current address and cart. Complete the order and inspect the data consumed by fulfillment.

For taxes, use the shop’s known configurations and expected results. Include a destination change and a customer-group case if those affect your store. This is software QA against configured rules, not advice about which tax treatment is legally correct.

Test an ineligible combination deliberately. A restricted product and unsupported destination should produce an understandable blocked state, rather than an apparently available payment button that only fails at the end.

Treat failed payments as normal acceptance cases

Use each provider’s documented sandbox outcomes. Cover success, rejection, cancellation and an interrupted browser return where the integration supports those simulations.

A reliable case compares three observations: what the provider reports, what the payment module records and what the customer sees. These may become consistent asynchronously, so define a reasonable observation window for the module rather than assuming every result is immediate.

Include these checks:

1. Submit once and verify the intended order and payment relationship.
2. Double-click or repeat the supported submit action and check for duplicate business effects.
3. Cancel externally and confirm that recovery does not falsely mark the order as paid.
4. Return after success and refresh the confirmation page without creating another order.
5. Change the cart after a failed attempt, then retry and verify the new amount.
6. Where the provider’s sandbox permits it, replay a notification and check duplicate handling.

Do not fabricate callbacks or bypass provider verification to make a test appear successful. Use the integration’s supported sandbox tools and involve its maintainer when a failure mode cannot be safely simulated.

A failure to recover is a distinct issue from a failure to initiate payment. Report them separately so the affected contract is clear.

Check mobile interaction and shop isolation

Choose real device sizes representative of customers. Test with the on-screen keyboard open, with autofill, with a long address and with a validation error above the current viewport. Check that the final action remains discoverable and that totals can be inspected before submission.

Use keyboard-only navigation on desktop. When a section updates, verify that focus remains sensible and an error can be found. A successful mouse-driven test does not establish that the flow is operable for all customers.

For multistore, create deliberately different configurations in two shops: a carrier available in one, a voucher applicable only where intended, and a distinct payment configuration if supported. Repeat the relevant checkout in each shop with separate sessions. Verify the order’s shop association and the integration account receiving the test event.

The goal is not to test every possible combination. Prioritize combinations that can move money, change delivery eligibility or leak one shop’s configuration into another. Add lower-risk presentation cases after those invariants are covered.

Before rerunning a case, restore or recreate its starting state. A voucher already consumed by an earlier order, a reduced stock quantity or a customer account created during the previous attempt can change the outcome. Give fixtures predictable identifiers and document which objects are reusable. This prevents test contamination from being reported as a checkout regression and makes another tester’s reproduction substantially more reliable.

Keep the expected result independent of the observed screen. Copying the displayed total into the test report as the expected total would make an incorrect calculation validate itself.

Turn results into a useful acceptance decision

Classify failures by business effect. Incorrect payment or order duplication blocks acceptance. An invalid carrier choice is also a correctness failure. A cosmetic alignment issue has a different severity unless it prevents the customer from understanding or completing the purchase.

Retest the exact failing sequence after a fix, then rerun adjacent cases that share the same dependency. A payment refresh fix, for example, warrants checking both address-driven and carrier-driven refreshes. Repeating unrelated cases without a reason adds time without explaining the fix’s impact.

Keep unresolved limitations visible in the sign-off record. A case marked “not exercised” is not a pass. A module vendor’s confirmation is useful supporting evidence, but it does not replace testing the store’s own configuration.

The final result should identify the tested version combination, passed critical scenarios, remaining failures and the person responsible for the next decision. While 9.2 remains RC software, that decision is readiness for further evaluation, not permission to install the candidate on a live store.

For the underlying platform context, see our safe PrestaShop 8-to-9 upgrade guide and apply the version-specific checks above to the installation you are evaluating.