Choose and operate PrestaShop payment methods

What we would do

We would keep a working payment integration unless it fails a requirement you actually need: a method your customers ask for, a market the connector cannot serve or a fault you can reproduce. Replacing a connector changes order creation, notifications, refunds and reconciliation, not only the button in the checkout. Check first whether the current integration can already do it: one module can return several methods, and a missing option can be an account, eligibility, currency or restriction setting.

When a change is justified, make it on a staging copy of the live shop: the same theme, modules, carriers and custom code, isolated from live payments, customer emails and fulfillment exports, and connected to the provider’s test account. Rehearse the purchase, interruption and refund tests until they pass, then switch the live shop in an agreed window, with the previous configuration ready to restore and one named person reconciling payments and orders.

Which route fits the problem?

The native PrestaShop checkout shows whatever the installed gateway modules return. Express Checkout uses Stripe and brings address, delivery, payment and confirmation into one window on product pages, listings or the cart. Its product description includes required address fields, payment eligibility by audience, country and currency, live delivery prices, rejection of excluded payment-and-carrier combinations, order creation after a completed payment even if the browser closes, and full or partial refunds from the order screen. Checkout Revolution puts contact, address, delivery, payment, vouchers and the order summary on one page with your existing carriers and payments, and also offers an express purchase window. Express Checkout has an optional single-page checkout too, so compare the overlap before buying both; neither description establishes that the two should run together on your shop.

If you are choosing between candidates, the PrestaShop Module Selection & Fit Assessment tests the routes against your requirement on a controlled shop copy. If the module is already chosen, the PrestaShop Module Installation & Configuration Service installs one existing module, configures the agreed settings and verifies the relevant journey; licenses, additional modules and development are separate.

Choose methods for the markets you serve

Use your customers’ countries, currencies, devices, support requests and completed/failed checkouts to form a shortlist. Missing a preferred method can be a reason to leave, but neither that observation nor a country stereotype proves which method your store needs.

This is a research checklist, not a ranking or mandatory list. Do not infer that cards are rare, foreign or unusable in an entire country, or that one BNPL provider is the default across all Nordic markets.

Cartes Bancaires is France’s domestic card network. Many cards are co-badged with an international network. Check the integration’s cardholder network-choice requirements, rather than forcing a preferred route and promising lower decline rates.

For cash on delivery, verify carrier collection, fees, settlement, refusal and return handling. A payment option alone does not arrange cash collection.

Understand modules, methods and native restrictions

A payment module can return several PaymentOption objects through paymentOptions. PrestaShop 1.7.8 and 9.1 collect checkout options by module. One provider integration can therefore expose cards, wallets and local methods without being one module per method.

Payment > Preferences restricts payment modules by currency, country, customer group and carrier. Those restrictions are associated with the module, not every individual method that an aggregator returns. Disallowing Mollie or Stripe for a country also hides the card options supplied by that module for that country.

1. Check that the module is active for the intended shop.
2. Check native module restrictions for the actual cart context.
3. Check the provider account’s enabled methods, merchant eligibility and supported currencies.
4. Check any method-specific controls implemented by that module release, including amount limits and order.
5. Test the resulting list with representative countries, currencies, groups and carriers.

Native hook positions under Design > Positions order modules on paymentOptions; methods within an aggregator need that integration’s own ordering controls. The native restriction grid has no general order-amount rule. Do not assume every aggregator offers the same billing-country, currency or amount controls.

Checkout Revolution provides additional payment-option presentation controls, with embedded payment where supported and redirects where required; see its module help for setup.

Decide whether another method earns its cost

Start with methods supported by demand and operational capability. Adding an option can serve a new segment, shift existing buyers between processors or add maintenance without producing extra orders. There is no fixed correct number of methods or modules.

Consider an illustrative checkout example. There are 1,000 attempts, 800 original completed orders and a EUR 60 average order value. Recovering 8% of the 200 lost attempts adds 16 orders, yielding 816 completed orders.

These are receipts after one assumed fee, not profit or a predicted conversion result. Subtract product, fulfillment, shipping, returns, fraud, support and integration costs. Include the effect of existing buyers choosing a more expensive method. A recovered order is not automatically pure upside.

Show only methods actually available in the checkout. Put useful logos and clear names where shoppers need them, and explain any redirect. Embedded fields and bank/app redirects each need testing; neither universally converts better.

Understand BLIK, iDEAL | Wero and Bancontact

BLIK, iDEAL and Bancontact have different customer and technical flows. They are not controlled by a shared “3-D Secure” switch. 3-D Secure is a card-authentication protocol; a bank/app method uses its own authentication process.

• BLIK: a customer can obtain a six-digit code from their banking app and authorize the payment there. Stripe’s BLIK API documentation requires PLN presentment. Merchant payout currency is a separate account/settlement question.
• iDEAL | Wero: follow the provider’s current hosted bank-selection flow. Merchants were instructed to remove their own bank-selection lists by 31 March 2025.
• Bancontact: assess the provider’s supported card/app flow for Belgian shoppers. Do not infer the prevalence of Bancontact-only cards from the existence of the scheme.

The iDEAL | Wero co-branding phase began in 2026. Technical migration is phased and separate from a logo change. Do not describe iDEAL as already discontinued. Use the branding and integration instructions applicable to your gateway.

Check the exact plugin release. Check that your PrestaShop connector release supports BLIK even when the provider API supports it. Mollie’s current method list identifies BLIK and Przelewy24 separately. Do not publish an untested support matrix or label P24’s iDEAL/Bancontact coverage “limited” without an identified integration.

If a local method is missing, check merchant activation, country/currency eligibility, cart amount, native module restrictions, integration support and storefront errors.

Compare integrations rather than provider brand names

Compare exact module names and versions, declared PrestaShop/PHP support, release activity, security fixes, licenses and support terms. Test your theme and checkout. “Official,” “paid” and “separate modules” do not prove compatibility or complete functionality.

Inventory hosted versus embedded checkout, local methods, wallets, authorization/capture, partial refunds, saved payment details, subscriptions, disputes and multistore. A provider’s platform capability can exceed its connector’s capability. Saved details and wallets are not inherently premium-only features.

Confirm merchant-country support, business category, identification requirements, bank/payout eligibility and approval for each method. Distinguish charge currency from settlement currency and conversion. A single integration does not guarantee one balance, one payout currency or one settlement account.

Compare Stripe and PayPal for your actual account

Stripe can use an embedded payment form or hosted Checkout, depending on the integration. Local methods and authentication can redirect. PayPal integrations can also offer different button, wallet and card flows. Test the actual configuration instead of assuming one provider always keeps the customer on your domain.

In a PayPal flow, approval, authorization and capture are distinct. The PrestaShop module decides when the local order is created. A buyer’s approval is not proof of captured funds, and you should retrieve the transaction status if the browser return is missing.

Compare acceptance, customer demand, payment success, seller-protection eligibility, refund operations and total cost. Do not choose based on an unsupported claim that one processor favors buyers or that a new store always needs one particular logo.

If you run independent Stripe and PayPal accounts, reconcile their balances, fees, refunds and settlements separately. An aggregate financial report is not automatic bank-settlement matching or payment/country/device profitability attribution.

Distinguish PayPal Resolution Center claims from card-issuer chargebacks. A cardholder can dispute through the issuer; the Resolution Center is not a mandatory first stage for every card dispute.

Use dated, market-specific fees and complete cost calculations

These published fee examples are dated 27 October 2026. They are different merchant markets/products and must not be used as equivalent quotes for a single merchant.

Get an actual quote for your merchant country and product. Include fixed charges, card mix, cross-border fees, conversion, tax treatment, payout/activation charges, refunds, disputes and any module subscription or integration cost. Local methods are not universally flat-fee or cheaper.

For the Stripe Ireland standard-card example, EUR 20, EUR 50 and EUR 150 transactions produce EUR 0.55, EUR 1.00 and EUR 2.50 processing fees before other applicable charges. Recalculate each provider with the same merchant assumptions rather than comparing unrelated European baselines.

The Stripe Ireland schedule also lists EUR 20 for a received dispute and a separate EUR 20 for manually countering it, with the countering fee returned for a win. PayPal also publishes dispute/chargeback fees with regional rules and exceptions. Do not assume a dispute is free or that every fee is refunded when you win.

Record the setup and prepare a reversible change

A payment change touches more than the provider: the checkout, carriers, order states, emails, stock and anything that reads paid orders. Record the setup before you change it, so you can test the same combination on staging and restore it if the launch goes wrong.

• Record the exact PrestaShop, PHP, theme and connector versions, and ask the connector supplier to confirm that combination. A declared version range is not a test of your shop.
• List the other checkout and payment modules, carrier integrations, multistore requirements and custom code that changes the cart, totals or order creation. Include any ERP, accounting or fulfillment tool that consumes paid orders.
• Record the current connector settings, account, mode and notification configuration securely, without copying secret credentials into tickets or screenshots.
• Take a recoverable backup of the database, files and configuration, and prepare a staging copy of the live shop. Isolate staging from live payments, customer messages and fulfillment exports.
• Agree the launch window, the rollback steps and the person who will reconcile payments and orders if you revert. Provider records do not roll back when you restore the shop database, so a restore must protect the orders and payments received since the backup.

Connect staging in test mode and prove reconciliation

1. Connect staging to the intended test account using the module’s supported connection method. Keep test and live credentials separate.
2. Configure any required notification endpoint and its authentication from the installed release’s instructions. If staging sits behind a login, give the provider controlled access to that endpoint only, as described in the tracing section below.
3. Make a documented test purchase, then compare the provider’s delivery evidence with the connector’s processing and the resulting order.
4. Repeat with the browser return interrupted. Keep the cart reference, payment reference and expected order outcome together for support.

For each test, compare the payment reference, amount and currency with the cart and the resulting order. Confirm the expected order state, emails, stock movement and downstream export, including their timing. One successful card payment does not prove the whole route.

Check Mollie methods, compatibility and status mapping

Mollie’s compatibility table separates module generations: Mollie 6 for PrestaShop 1.7.6 and later, Mollie 5 for earlier 1.7 releases, and older branches for legacy shops. Verify the exact release’s PrestaShop 9/PHP declaration rather than treating all versions as one tested package.

Use the official integration documentation for the module’s own installation and account connection.

Check account/profile approval, test/live separation, enabled methods and the checkout’s actual eligible list. The current documentation lists cards, bank methods, wallets and pay-later options, including BLIK and Przelewy24 as separate methods. A provider listing does not mean every older installed module exposes them.

Confirm the actual notification URL generated for the integration. Avoid guessing it from another release’s example. An endpoint may behave differently for browser GET and provider POST. A browser timeout can come from a different route or network path and is not proof that Mollie cannot reach the endpoint.

Map statuses using Mollie’s definitions: open/pending are not paid; authorized is not captured. Inspect the actual payment before deciding why a local order is awaiting payment. Then check notification delivery, validation and local processing.

For multistore, verify credential/profile scope and notification routing per shop. Test each currency, including a scenario where a currency-bound method is unavailable. Do not let an ineligible local method leave the shopper without a usable alternative.

Check Przelewy24 account, credentials and verification

Use P24’s official package and instructions for its own module setup. The download page separates legacy 1.5/1.6 and 1.7.0-1.7.5.2 packages from the current 1.7.6/8/9 package. A module originally supporting 1.7 is not automatically incompatible with later majors.

Confirm onboarding and document requirements for your legal entity and country directly with P24. Do not promise foreign-merchant approval, a review duration or a particular currency-conversion/payout arrangement without the contract.

Distinguish merchant/POS or shop identifiers, API credentials and CRC/signing credentials according to the selected package. Match sandbox and production mode throughout. A signing error requires checking the exact credential, signature fields/serialization and transaction data, rather than assuming a trailing space is always the cause.

The official changelog includes support for payments outside PLN. Restrict a method according to that method, the merchant account and module; do not globally hide P24 for EUR. Keep cart, submitted payment amount and currency consistent.

A valid P24 notification requires the documented signature and transaction checks plus server-side transaction verification through the P24 API. Test a payment where the customer does not return. An order becoming paid on the summary page alone does not prove the callback fired, because an integration can also check status during the return.

Offer the supported language and methods your audience can use. Choose card and bank methods from your customers’ needs. Confirm module and account support separately for saved-BLIK and instalment features.

Check Stripe integration, wallets and recurring requirements

Use Stripe’s PrestaShop module documentation for that connector’s own setup and supported methods.

Verify account approval, test/live account identity, keys and object ownership. “No such payment intent” can result from mixing environments or accounts, or using a stale payment object; check the actual object and selected mode before retrying checkout.

• Publishable credential: where manual keys are used, the value intended for the storefront payment interface.
• Secret credential: the server-side authority to call the payment account. Keep it out of the theme, browser code, screenshots and support messages.
• Notification signing secret: where required, the value used to validate incoming notifications. It is not interchangeable with an API secret.

These are roles, not a rule that every connector asks for all three values on one screen. Express Checkout, for example, is set up with two keys from the payment account. Match the account, environment and notification settings to the installed module’s instructions.

Webhook registration can be automatic or manual depending on the module. Use the integration’s actual endpoint, signing secret, event list and handler coverage. A generic list of payment, refund and dispute events is not a valid subscription recipe for every module. The list must match implemented handlers and reconciliation.

Stripe’s connector support page states that its connector supports standalone payments rather than Stripe Billing. Provider subscription capability, saved details and a complete PrestaShop renewal integration are separate capabilities.

For off-session payments, obtain appropriate consent and set up the payment method for that use. Provide a recovery route that brings the customer back to authenticate when required. Stored-card renewals are not guaranteed to avoid future challenges.

Register all applicable domains and subdomains for supported wallets according to Stripe’s payment-method domain requirements. Google Pay can require domain registration too. Distinguish domain registration from Apple’s file verification. Test eligible devices, browsers and configured wallet accounts; merely enabling a button does not make it appear everywhere.

If a wallet button is missing, first reproduce the problem on a device and account that the connector supplier says are eligible. Then check the selected country, currency and the module’s eligibility settings, and only then the domain and wallet configuration. A product description that lists wallets does not say which ones the installed release supports: confirm Apple Pay, Google Pay or any local method against the release, account, country, currency and device. Distinguish an unavailable method from a broken checkout; an ineligible shopper still needs a usable alternative.

Verify status and process each payment once

Separate provider payment creation, browser approval/return, notification handling, local order creation and later status transitions. Depending on the integration, a server-side status lookup can happen on the browser return, a webhook or a reconciliation job. Confirm payment through the provider’s authenticated status or notification mechanism.

1. Authenticate the notification using that provider’s documented signature or verification mechanism. Retrieve authoritative status where required.
2. Verify the merchant account, test/live mode, provider payment ID, cart/order association, expected amount and currency. Use the provider’s currency-unit conventions.
3. Distinguish pending, authorized, captured/paid, failed, cancelled, expired, partially refunded and refunded states.
4. Claim the event/transaction durably so concurrent handlers and later retries cannot apply it twice. Event deduplication alone is insufficient when several event types describe the same payment.
5. Create an order only if the validated workflow calls for creation and the cart is not already ordered. Update an existing pending order through the appropriate payment/history workflow.
6. Record the outcome and any retryable failure. Acknowledge only after processing or safe durable queuing according to the integration’s design.

Core PaymentModule::validateOrder() rejects a cart that already has an order. Do not use it as a universal “advance pending order” function.

Make returns, notifications and scheduled reconciliation use the same validated transition rules. Duplicate or out-of-order events must not create extra orders, payments, stock changes or emails. Existing order status changes need appropriate history/payment APIs, rather than direct SQL on the displayed state.

Order creation can affect stock before payment is confirmed, depending on the integration and order state. Do not infer stock reservation or decrement solely from the payment status label.

Trace a paid provider payment with a pending or missing order

1. Record the payment reference, account, test or live mode, amount, currency and time. Check the provider dashboard/API for the actual transaction state. Confirm capture rather than approval or authorization, and check the account/mode. Compare that state with the one agreed for fulfillment.
2. Match the transaction to the shop, cart/order, amount and currency. Search carts, orders and connector logs by the payment reference, not by customer name alone. Inspect possible split orders or another payment attempt.
3. Check notification delivery logs: destination, method, response, retries and timestamps.
4. Inspect reverse-proxy, WAF, certificate and application logs for that endpoint. Login pages, basic authentication, maintenance behavior and browser challenges can block a provider request.
5. Check signature verification, handler exceptions, missing mappings, locks and database writes after delivery. Custom order code or an ERP integration that runs during order validation can fail after a valid notification arrives.
6. Ask the module maintainer to correlate the provider record with the server error and module logs. Redact credentials and unnecessary customer details before sharing evidence.
7. Replay or reconcile through a supported idempotent process. Retrieve current state before creating anything or marking an order paid.

Hold fulfillment while the state is unresolved. Do not ask the customer to pay again, or mark the order paid to clear the support queue, until the original payment is reconciled: another attempt can charge the customer twice.

Use narrowly scoped, documented endpoint rules while retaining notification authentication. A successful GET, an HTTP 200 from an unrelated page or a browser return does not prove successful webhook processing. A reachable endpoint can still reject a signature or fail after accepting a request.

For local development or a private staging copy, use an authorized forwarding/test mechanism if the provider needs public reachability, or give the provider controlled access to the notification endpoint only, without exposing the whole copy or weakening signature checks. Do not assume a provider can call a private localhost URL. Verify each provider’s retry behavior rather than copying a universal 30-second timeout.

Work through a paid order that lost its browser return

A customer buys a personalized mug, completes payment and closes the phone browser before the confirmation page. Staff see the payment at the provider but cannot find the expected order. The acceptance test is that the integration recovers the agreed order contents and records the payment without asking the customer to pay again.

Rehearse this case on staging. Before starting, keep the chosen customization, delivery address, carrier, final total and currency. Afterwards, match the payment reference to the cart and any resulting orders, and check the personalization and delivery instructions as well as the amount. A payment attached to the wrong basket is still a failed purchase journey.

If the notification arrives later, confirm that the order reaches the agreed fulfillment state once. Ask the supplier how its supported reconciliation procedure handles this case. Manually creating an order while recovery is still running can produce a second order, and a manual repair belongs to the connector’s documented recovery route, rehearsed on staging, rather than a direct database edit.

Reconcile refunds, cancellations and settlements

Keep authorization cancellation, payment refund, credit-slip generation, voucher issuance, stock return and order-state change separate. Changing a PrestaShop label to “refunded” is not proof that a gateway returned money.

1. Confirm the original payment and captured/refundable amount.
2. Initiate the full or partial refund through the supported integration/provider workflow.
3. Record its provider reference and watch for pending, succeeded or failed outcomes.
4. Update the local payment/accounting record and stock only according to the actual refund and return policy.
5. Reconcile provider balances and payouts with sales, fees, refunds and disputes.

Avoid refunding once in the module and again in the provider dashboard. Record whether staff start refunds in PrestaShop or in the provider dashboard, and who reconciles a refund begun elsewhere. Check each method’s supported refund period, partial-refund capability, nonreturned processing fees and settlement timing. A provider can pay out in a different currency or on a different schedule from the customer’s charge.

Test a partial refund against the intended order lines and delivery charge, then confirm the provider amount, the order record and any required accounting document. Decide restocking separately: sending money back is not evidence that the goods reached the warehouse.

Retain relevant invoices, tracking and proof of delivery, customer communications and original messages under an appropriate retention policy. Core order history stores state history; it does not automatically archive every document needed for a dispute. Keep that evidence accessible to a named staff member, check each case’s response instructions and deadline in the provider account, and do not assume that a module’s refund controls also provide a dispute workflow.

Evaluate BNPL terms, presentation and contribution

Klarna, Clearpay/Afterpay, PayPal Pay Later, Riverty and other products differ by market, merchant eligibility, payment plan and integration. Check the actual offer rather than assuming every shopper gets the same three- or four-instalment contract.

Verify authorization, capture, shipment reporting, partial capture, cancellation, refunds and payout timing. Some integrations capture on shipment. Do not ship based solely on approval or assume the normal fulfillment workflow is untouched.

The lender can assume specified credit risk while the merchant retains contractual duties and exposure to delivery disputes or other recourse. Read the actual protection terms. Recurring use depends on the provider product and a renewal-capable integration; it is not universally impossible or automatically supported.

Compare contracted fees, fixed charges, conversion, tax treatment and refund-fee rules. Do not assume BNPL always has a particular premium over cards or cap its price at 6%. The current PayPal UK page publishes its own Pay Later price, so an old general “no surcharge” statement must not replace that quote.

For an illustrative EUR 10,000 monthly category, a hypothetical three-percentage-point fee premium costs EUR 300 if all those sales shift from the original route, even before any incremental orders. You need the actual shifted volume, new orders and contribution margin to decide whether the change pays.

Show provider-approved instalment messaging near relevant product prices and at checkout when eligible. For example, EUR 99.99 can be described as three payments of EUR 33.33 only when that exact plan and required disclosures apply. Update messaging when price, currency or product selection changes.

If messaging disappears, inspect eligibility, provider/client configuration, scripts, containers and the actual theme hook. A missing hook is one possible cause. Do not assume a fixed basket or age range defines the profitable audience.

Use the rules for the customer’s country. Directive (EU) 2023/2225, Article 48, provides for measures to apply from 20 November 2026, subject to national implementation. The FCA began regulating relevant UK Deferred Payment Credit on 15 July 2026. Lender underwriting does not remove merchant presentation and contractual duties.

Compare eligible randomized groups where feasible. Higher baskets among BNPL users can reflect customer selection rather than a causal increase. Include substitution, returns and fees in the result, and avoid fixed “60 days and 200 orders” rules.

Handle authentication and PCI scope accurately

SCA applies to in-scope electronic payments under the applicable rules, with exclusions and exemptions. EEA and UK rules have their own legal basis. A PSP can request authentication or an exemption, while the issuer determines the outcome. Authentication can use an app, a code or another supported mechanism.

Use maintained EMV 3DS support. A frictionless result and a challenge are both possible; 3DS1 is not a current European alternative to recommend. The FCA’s extended e-commerce implementation deadline was 14 March 2022.

3DS can shift liability for eligible fraudulent-payment disputes subject to scheme/provider conditions and exceptions. It does not insure you against every dispute, delivery failure or exempted transaction. Check the authentication and liability outcome of the actual payment.

The surrounding page’s domain does not determine scope. Ask who supplies the collection fields and where card data passes. Confirm the applicable SAQ and validation obligations with the acquirer/compliance-accepting entity.

PCI SSC FAQ 1604 confirms ASV scanning obligations for relevant SAQ A e-commerce pages, including redirects and embedded iframes. Do not describe SAQ A as a trivial annual checkbox or scanning as exclusive to SAQ D; include applicable quarterly scans.

For embedded payment forms, the current SAQ A also has a script-attack eligibility condition described in PCI SSC FAQ 1588. Hosted processing reduces direct card-data handling, while a compromised merchant page can still redirect buyers or inject a fraudulent collection form.

Use fraud signals and keep an incident process

AVS and CVV checks are limited signals. CVV success does not prove physical possession or a legitimate buyer. Checks can be unavailable, and legitimate addresses can mismatch. Review issuer/country behavior and your provider’s verification results.

Assess payment-attempt velocity, repeated failures, unusual shipping changes and relevant account/device signals with proportionate controls. PrestaShop order/cart records can help an investigation but do not supply a universal device-fingerprinting or cross-account fraud engine. Test gateway risk rules for false positives.

Select manual review or additional screening based on order value, product resale risk, attack rate and dispute exposure. There is no universal order-count threshold below which fraud controls are unnecessary.

Keep card numbers and sensitive authentication data out of application logs, debug tools and support tickets. Tokens and transaction references still require access controls; webhook payloads can also contain personal data. Log only the sanitized fields needed for diagnosis.

1. Contain the affected route or compromised component and stop unsafe fulfillment.
2. Preserve relevant logs and evidence without collecting additional card data.
3. Contact the PSP/acquirer and appropriate incident responders, rotate compromised credentials and establish the affected scope.
4. Assess personal-data notification duties and communicate accurately.
5. Repair and validate the integration before resuming normal processing.

Where GDPR applies and you are the controller, Article 33 requires notification to the competent authority without undue delay and, where feasible, within 72 hours of awareness unless risk to individuals is unlikely. Assess communication to affected people separately under Article 34.

Test the complete lifecycle and measure the result

Use provider-supported sandboxes/test credentials and test values. Follow the provider’s rules for any separate production validation. Never put real card details into a test environment because a tutorial asks for them.

Stripe’s test documentation provides these examples for test mode:

Run each scenario on staging and keep the evidence, so you can repeat the check after a theme, connector or integration change.

In every scenario, verify local payment records, stock behavior, order history, emails and eventual provider settlement. Repeat with mobile wallets, local methods, each supported currency, multistore and your actual theme/checkout. A successful test card does not prove that wallets or refunds work, so keep evidence from the relevant device and the resulting PrestaShop order.

Record checkout attempts, payment-step abandonment, provider success/failure, method use, refunds, support cases, checkout speed and contribution. Segment countries/devices only where your reporting actually supplies them. The PrestaShop 9.1 Shopping Carts grid includes ordered, non-ordered and abandoned statuses, without a native country filter. Select the intended status and use a scoped export or appropriate analytics for country segmentation.

A cart record does not say why the shopper left. Compare controlled changes where feasible, account for seasonality and customer mix, and observe enough eligible traffic for the effect you need to detect. Do not promise a conversion uplift or choose a processor from a generic industry average.

Launch the change and hand it over

After staging passes, follow the connector’s live-mode instructions and the provider’s rules for an agreed live verification. Keep the previous configuration and the rollback steps available. Watch actual orders, payments and fulfillment hand-offs after launch, and repeat the relevant tests after changes to the theme, connector or integrations.

What to ask the developer before handover

• Which module release and shop configuration were tested, and where are the results?
• What creates or recovers an order when the browser never returns, and how are repeated notifications handled?
• Which payment states permit fulfillment, and how do refunds, disputes and delayed methods reach staff?
• How does a shopper recover from a failed or cancelled authentication, and which payment-and-carrier combinations are excluded?
• Where can staff find redacted logs, the payment reference, recovery instructions and the person responsible for an unresolved payment?