PTS Stripe
Complete documentation to install, configure and use the PTS Stripe module in your PrestaShop store.
What is PTS Stripe?
PTS Stripe connects your store to Stripe so you can take card payments, digital wallets such as Apple Pay, Google Pay, Link, PayPal or Amazon Pay, the usual bank methods of each European country, and the voucher methods used in Brazil, Mexico or Portugal. Each one is enabled separately and can be limited to the countries and customer groups you choose.
Besides taking payments inside the checkout, it adds express purchase buttons on the product page, the cart and the payment page, and its own tab on every back office order where you can review the payment and issue refunds without opening the Stripe dashboard.
Main Features
Every Stripe method
Card, Apple Pay, Google Pay, Link, PayPal, Amazon Pay, Klarna, iDEAL, Bancontact, EPS, Przelewy24, BLIK, TWINT, Afterpay/Clearpay, Affirm, SEPA direct debit, Multibanco, OXXO, Boleto and Pix. Each with its own switch, or all together in a single form if you prefer to let Stripe choose.
Express purchase with digital wallets
Payment buttons on the product page, the cart, the payment page and the One Page Checkout PS side cart. The customer picks address and shipping inside their own wallet window, with shipping costs and taxes already calculated.
Country and group restrictions
Each method in the payment list can be shown only to the delivery countries and customer groups you choose, so every market gets what is actually used there instead of a checkout full of options nobody will pick.
Refunds from the back office
Full or partial, from the Stripe tab of the order itself and with the refundable amount always in sight. They can also be issued on their own when a credit slip is created in PrestaShop.
System Requirements
| Requirement |
Minimum |
Recommended |
| PrestaShop |
1.7.6 |
9.x |
| PHP |
7.2.5 |
8.3+ |
| Stripe account |
Required |
— |
| SSL certificate |
Required |
— |
Your store has to be reachable over HTTPS before you take real payments: Stripe does not accept card payments over unencrypted connections, and digital wallets do not appear without it either.
Installation
There are two methods to install the module in your PrestaShop store, depending on your server characteristics.
Method 1: Installation from Back Office
1
Access the Back Office
Log in to your PrestaShop store administration panel.
2
Navigate to Modules
Go to Modules → Module Manager in the sidebar menu.
3
Upload the module
Click "Upload a module" and select the downloaded ZIP file.
4
Install and activate
Once uploaded, the module will install automatically. Click "Configure" to begin.
Method 2: Installation via FTP
Use this method if the ZIP file is very large and your server does not allow uploading it from the Back Office due to upload size limitations.
1
Extract the ZIP file
Extract the contents of the ZIP file on your local computer.
2
Connect via FTP
Use an FTP client (such as FileZilla) to connect to your server.
3
Upload the module folder
Upload the module folder to /modules/ in your PrestaShop installation.
4
Install from Back Office
Go to Modules → Module Manager, find the module and click "Install".
Possible Installation Issues
Override Conflicts: During module installation or activation, issues related to override files may arise. This happens when another module has already modified the same PrestaShop core files.
If you experience override errors when installing or activating the module, do not attempt to resolve it yourself if you lack technical experience. Contact our support team to receive personalized help and resolve the conflict safely.
Contact Support
Settings
The module settings are split across tabs. The first three are explained here: General holds the diagnostics, Stripe stores your account credentials, and Payments decides which methods the customer sees and how. Express purchase has its own section, right after this one.
The recommended order the first time is: paste your keys in the Stripe tab with sandbox mode on, register the webhook URL in your Stripe dashboard, enable the methods you want to offer and place a test order. Once everything works, turn sandbox mode off and paste the live keys.
General
Holds the module's diagnostic options and the behaviour of automatic refunds.
Debug mode
When you enable this option, the module's payment methods are only shown to the IP addresses you list in the "IP" field. That way you can test payments in your own store while the rest of your customers keep buying with the payment methods you already had.
It is recommended to enable this option to test the module in your store before enabling it for customers.
IP
Lists the addresses the module will be visible from while debug mode is active. The button next to the field adds the address you are browsing from at that moment, which is the easiest way not to get it wrong.
If you leave this field empty with debug mode enabled, nobody will see the module's payment methods, yourself included. Add at least your own IP before enabling it. Bear in mind too that many home connections change address every so often: if one day the module disappears for you, check whether your IP is still the same.
Enable debug logs
Stores in the back office logs the detail of every payment: when the payment attempt is created, how express purchase shipping costs are calculated, and which notifications Stripe sends. It is meant for diagnosing a specific incident together with support, not for leaving it on day to day.
The module's warnings and errors are always stored, whether this option is enabled or not. What it adds is the detail of what did work, which is what you need to reconstruct a payment that behaved oddly.
Auto-refund on credit slip
When someone creates a credit slip in PrestaShop, the module issues the refund in Stripe for that same amount, without having to repeat the operation by hand on the order tab. It is disabled by default: enable it only if your way of working is to always issue the credit slip first.
Stripe
This is where the credentials that connect the store to your Stripe account live, along with the secret used to verify the notifications Stripe sends. All of them are copied from your Stripe dashboard.
Sandbox mode (test)
Switches between Stripe's test environment and the real one. With the mode enabled, the module works with your test keys and no charge is real, so you can place complete orders with Stripe's test cards. When you disable it, it starts using the live keys and payments are charged for real.
The fields shown below change depending on the switch: with the mode enabled you are asked for the Public test key and the Secret test key; with the mode disabled, the Public live key and the Secret live key. All four are in your Stripe dashboard, under Developers → API keys.
Test keys and live keys are not interchangeable: a test key in live mode (or the other way round) leaves payments not working. If the module does not connect to Stripe, this is the first thing to check.
Webhook secret
This is the signature the module uses to verify that a notification really comes from Stripe and not from a third party. Without this value, or with one that does not match the registered endpoint, notifications are rejected and the module never learns about payments that are confirmed later.
You will find it in your Stripe dashboard, under Webhooks, on the endpoint you created for your store. On this same screen the module shows your store's
webhook URL with a button to copy it: that is the address you have to register in Stripe. The detail is in
Webhooks.
Payments
This tab decides how payment methods are presented to the customer: all together inside a single form, or each one as an independent option in the payment list. It is an either/or choice, and the form itself changes depending on what you pick.
Enable integrated payment form
Shows every available method inside a single form instead of splitting them into separate options. Stripe then decides which methods to offer, based on the customer's country, the currency and the order amount, so you do not need to enable them one by one.
When you enable it, the switches of the individual methods no longer apply and the integrated form's design, theme and restrictions appear instead. If you would rather control exactly what each customer sees, leave it disabled and configure the methods one by one.
Stripe choosing does not mean it offers everything listed in this guide: it only proposes the methods your account has enabled and approved, and that also match the merchant country, the currency and the order amount. If one is missing, check your Stripe dashboard first.
Integrated form design
Choose how methods are grouped inside the form: Tabs, Accordion (with radio buttons) or Accordion (without radio buttons). With few options tabs read better; with many, the accordion takes up less room.
Integrated form theme
Visual appearance of the form: Stripe, Flat, Night or None. The first three are the styles Stripe ships. With "None" the form gets none of them and is drawn with the browser's minimal appearance, which is the most neutral starting point if your checkout has a very distinctive design. Bear in mind that Stripe draws the form inside an isolated frame: it does not pick up your theme's styles, so "None" does not blend it into your design on its own.
Restrict by countries
Limits which delivery countries the method is offered in. If you leave it empty, it is shown in all of them. This is how you offer each market what is actually used there, instead of showing everyone a long list of local methods from other countries.
Restrict by customer groups
Limits which customer groups the method is offered to. If you leave it empty, it is shown to all of them. It is useful, for example, to reserve deferred payment for wholesale customers, or to keep a method for a single group while you test it.
These two restrictions appear inside each method, not once for all of them: each one carries its own, and the integrated form has them too. On the integrated form they apply to the whole block, so restricting it hides every method it contains at once.
Restrictions act on the checkout payment list, not on the express purchase buttons. The module needs to know which country the order ships to and which group the customer belongs to, and that is only known once they have chosen their address. When an Express Checkout button is pressed, the address is chosen afterwards, inside the wallet window, so there is nothing to compare against and the button is shown anyway. If you need a wallet not to be offered in a market, disable it on the relevant pages instead of relying on the restriction.
Payment methods
With the integrated form disabled, each method is enabled separately and appears as its own option in the checkout payment list. All of them accept the same delivery country and customer group restrictions explained above.
| Method |
How the customer pays |
Where it is used |
| Credit/Debit Card |
In the checkout itself |
All markets |
| BLIK |
Six-digit code from their banking app |
Poland |
| SEPA Direct Debit |
Authorises the charge with their IBAN |
SEPA area |
| iDEAL |
Finishes on their bank's website |
Netherlands |
| Bancontact |
Finishes on their bank's website |
Belgium |
| EPS |
Finishes on their bank's website |
Austria |
| Przelewy24 (P24) |
Finishes on their bank's website |
Poland |
| TWINT |
Finishes in their app |
Switzerland |
| Klarna |
Finishes on Klarna (deferred payment) |
Europe and United States |
| Afterpay / Clearpay |
Finishes on Afterpay (deferred payment) |
United Kingdom, United States and Oceania |
| Affirm |
Finishes on Affirm (deferred payment) |
United States and Canada |
| PayPal |
Finishes on PayPal |
International |
| Multibanco |
Gets a reference and pays later |
Portugal |
| OXXO |
Gets a voucher and pays in a shop |
Mexico |
| Boleto |
Gets a document and pays at the bank |
Brazil |
| Pix |
Pays from their bank with the code |
Brazil |
Credit/Debit Card
Takes payment with the usual credit and debit cards inside the checkout itself, without the customer leaving your store. When the bank requires strong authentication, the 3D Secure screen appears on its own and the customer returns to the same place afterwards.
Show postal code in card form
Adds the postal code field to the card form. In some countries the bank uses it as an extra check on the cardholder, so it can reduce declines; in others it is just one more field to fill in. It only appears when card is enabled.
iDEAL
The most used method in the Netherlands. On confirming, the customer goes to their bank's page, authorises the transfer and returns to the store with the order already placed.
Bancontact
The Belgian equivalent: the customer authorises the payment at their bank or with their app and returns to the store.
Klarna
Lets the customer pay later or in instalments, depending on what Klarna offers them in their country. The customer completes the process on Klarna and you get the full amount all the same.
EPS
The usual online bank transfer in Austria. The customer picks their bank and confirms the payment there.
Przelewy24 (P24)
A Polish gateway that brings together most banks in the country. The customer chooses theirs and authorises the transfer.
BLIK
Polish as well, but without leaving the store: the customer opens their banking app, generates a six-digit code and types it into the checkout.
TWINT
The most widespread mobile payment app in Switzerland. The customer confirms the purchase from their phone.
Afterpay / Clearpay
Deferred payment in several instalments, interest-free for the customer. It is called Clearpay in the United Kingdom and Afterpay in the other markets where it operates.
PayPal
Takes PayPal payments through your own Stripe account, without installing the separate PayPal module. The customer authorises the payment on PayPal and returns to the store.
SEPA Direct Debit
The customer types their IBAN and authorises the charge on their account. Bear in mind that a direct debit takes days to confirm: the order is not paid at that moment, but when Stripe reports that the bank has accepted the charge.
Pix
Brazilian instant payment. The customer gets a code, pays it from their banking app and the order is confirmed as soon as Stripe receives the money.
Requires a Stripe account registered in Brazil. If yours is from another country, the back office itself warns you next to the method name.
OXXO
The customer gets a voucher with a number and pays in cash at any OXXO shop in Mexico. The order stays on hold until Stripe confirms the deposit.
Requires a Stripe account registered in Mexico.
Boleto
The usual payment document in Brazil: the customer downloads a PDF and pays it at their bank or through the app. The order is confirmed when the deposit arrives.
Requires a Stripe account registered in Brazil.
Multibanco
In Portugal, the customer gets an entity and a reference to pay with from their bank or at an ATM. The order stays on hold until the payment is received.
Affirm
Instalment payment in the United States and Canada. The customer takes out the financing with Affirm and you get the full amount.
Requires a Stripe account registered in the United States or Canada.
Enabling a method here is not enough: it also has to be enabled in your Stripe dashboard, in your account's payment methods section. If a method does not show up in the checkout even though its switch is on, that is the first thing worth checking, along with the order's country and currency.
Express Checkout
The express purchase buttons let customers pay with a digital wallet without going through the whole checkout: the customer presses the button, picks address and shipping inside their own wallet window, and the order is created on confirmation. Shipping costs and taxes are calculated with your store's rules while that window is open, with the rates and carriers matching the address they pick.
When the cart does not need shipping, because it only holds downloadable products or services, the window does not ask for a delivery address and the customer simply confirms the payment.
Each wallet only appears where it is available to the customer. Apple Pay needs an Apple device with Safari, and Google Pay, Chrome or a compatible browser. Not seeing a button on your own computer does not mean your customers are not seeing it on theirs.
The customer's phone number and these wallets do not fit together. Apple Pay, Google Pay and Amazon Pay return the phone number; Link, PayPal and Klarna cannot, and Stripe hides them from the button while it is requested. You decide with the
Request phone number option, instead of the module settling it on its own.
Where the buttons appear
On the cart, the payment page and the side cart, the position is fixed. On the product page you can choose it, because that is where themes vary the most.
Product Page — Button Position
Choose at which point of the product page the buttons are drawn:
- Additional product information (displayProductAdditionalInfo): below the product details. This is the factory value and the one most themes support.
- After Add to Cart button (displayAfterProductAddCartBtn): right under the purchase button.
- Product actions area (displayProductActions): inside the actions block, next to the add to cart button.
- Custom CSS selector (advanced): anywhere on the page, with you pointing at the reference element.
The first three positions depend on your theme providing them. If you choose one your theme does not draw, the buttons do not appear anywhere: in that case, use the custom CSS selector.
CSS selector
Points at the element the buttons will be placed next to, for example the add to cart button. It only appears when you have chosen the "Custom CSS selector" position.
Test it first in your browser's developer tools, on a product page of your store, and check that it matches a single element. A selector that matches several places the buttons on the first one it finds, which is not always the one you had in mind.
Position relative to the element
Decides where the buttons are placed with respect to the element matching the selector: Before the element (beforebegin), Inside, at the start (afterbegin), Inside, at the end (beforeend) or After the element (afterend, default). It also only appears in CSS selector mode.
How the buttons look
These options apply to every express purchase button at once, on all the pages where they appear.
Button Height (px)
Height shared by every button. Stripe accepts values between 40 and 55 pixels; the factory value is 48. It is worth bringing it close to the height of your theme's purchase button so they do not clash.
Max Columns
Maximum number of buttons per row. With Unlimited (default) Stripe distributes them according to the available width, which is usually the most sensible choice if you have several wallets enabled.
Max Rows
Maximum number of button rows. Those that do not fit go into the overflow menu, so a customer with many wallets available does not end up with half a screen of buttons.
Overflow Menu
Decides what happens to the buttons that do not fit in the grid. With Auto (default) Stripe sorts it out; with Never none of them are grouped.
"Never" is only valid if max rows is set to unlimited. If you limit the rows and disable the menu at the same time, the leftover buttons would have nowhere to go.
Request phone number
Asks the wallet for the customer's phone number, which is the one the carrier needs to arrange delivery. It is enabled by default, and it is worth leaving it that way if you sell products that get shipped: without it the order reaches the carrier with no contact number.
It has a trade-off worth knowing before you decide: Apple Pay, Google Pay and Amazon Pay return the phone number, but Link, PayPal and Klarna cannot, so Stripe hides them from the express purchase button while this option is enabled. If those three wallets matter more to you than the phone number, disable it.
On carts holding only digital products the phone number is not requested, even with the option enabled: there is no delivery to arrange, and asking for it would cost those three wallets in exchange for a detail nobody is going to use. That is decided by the module, not by this option.
Hide carriers
The carriers you tick here are not offered inside the wallet window. This is the option that solves pickup points: they require the customer to choose a physical location on a map, and that screen does not exist in Apple Pay or Google Pay, so an order with such a carrier would end up without a delivery point. If you leave it empty, all of them are offered.
Hiding them here does not disable them in the store: customers buying through the normal checkout still see them, with their pickup point selector.
Which wallets are offered
Each wallet is enabled separately and carries the same sub-options: which pages it appears on and, where the wallet allows it, the text and colour of its button.
Turning the switch on is what allows the button to be shown, not what guarantees it will be. For it to appear, the wallet also has to be enabled in your Stripe account and available to that specific customer: their browser, their device, their country and the order currency. That is why the same button can show up on a phone and not on the computer next to it, and it is not a configuration fault.
Apple Pay
Shows the Apple Pay button. It only appears on Apple devices with Safari, which is where the customer keeps their saved cards.
Google Pay
Shows the Google Pay button. It only appears on Chrome and compatible browsers.
Link by Stripe
Shows the Link button, Stripe's own wallet: customers who have already saved their details on any store using Stripe pay without typing them again.
PayPal
Shows the PayPal button for customers who have their account linked in the browser.
Amazon Pay
Shows the Amazon Pay button, with which the customer pays using the address and method saved in their Amazon account.
Requires Amazon Pay to be enabled and connected in your Stripe dashboard.
Klarna
Shows the Klarna button to buy now and pay later, without going through the whole checkout.
Requires Klarna to be enabled in your Stripe dashboard.
Show as a payment option
Available on Apple Pay and Google Pay. On top of the express purchase button, it offers the wallet as one more option inside the checkout payment list: since the customer has already identified themselves and chosen their address, a single tap is enough to finish. It is the only flow of these wallets where the customer's address and group are known, and that is why it is the only one that accepts Restrict by countries and Restrict by customer groups.
Show on Product Page
Draws that wallet's button on the product page, in the position you chose above. The customer buys that product directly, without going through the cart.
Show on Cart Page
Draws that wallet's button on the cart page, next to the button that leads to the checkout.
Show on Checkout
Draws that wallet's button on the payment page, as a shortcut for anyone who would rather finish with their wallet than fill in the form.
Show in side cart (One Page Checkout PS)
Draws the button inside the One Page Checkout PS sliding cart panel, so the customer can pay from any page of the store without opening the checkout.
Requires One Page Checkout PS 5.3.1 or higher. Without that module installed, the option has no effect.
Button Text
The text shown on that wallet's button. Each one accepts its own: Apple Pay and PayPal offer the longest list, Google Pay a handful, and Klarna only "Pay" or "Continue". It is worth choosing it based on where the button is: on a product page "Buy" fits better, and on the cart, "Pay".
Button Theme
The colour of that wallet's button. Apple Pay accepts black, white and white with outline; Google Pay, black and white; PayPal, gold, blue, silver, white and black; and Klarna, dark, light and outlined. Choose the one that contrasts with your theme's background, especially if it is a light one.
Orders and refunds
The module adds the payment information and the tools to refund it to the orders it has charged, so you do not have to open the Stripe dashboard for day-to-day operations.
Stripe tab on the order
On orders paid with this module (Orders → Orders → the order you want) there is a tab called "Stripe" with everything known about the payment. On an order paid by other means the tab is not shown:
- Charge identifier, with a direct link to that operation in your Stripe dashboard.
- Payment method the customer paid with, showing the wallet name when they paid with one.
- Amount charged, amount already refunded and amount still refundable.
- Mode: whether the payment was made in test or for real.
While there is a refundable amount left, a form appears below to return the amount you enter. Type the amount, confirm, and the refund is issued in Stripe: if you return only part of it, the order moves to the partial refund status and still accepts further refunds until the total is used up.
On voucher payments (Multibanco, OXXO, Boleto and Pix) this same tab shows the details the customer needs: the entity and reference, the voucher number, the downloadable PDF, the link to the original document and the expiry date. They are handy for resending to anyone who says they never got them.
Order statuses
On installation, the module creates three statuses of its own in PrestaShop so you can tell these situations apart at a glance:
| Status |
When it is assigned |
| Waiting for Stripe payment |
The order is placed and waiting for the customer to pay their voucher outside the store (Multibanco, OXXO, Boleto or Pix). |
| Stripe partial refund |
Part of the amount has been returned and there is still an amount left to refund. |
| Stripe disputed payment |
The customer has disputed the charge with their bank and Stripe has reported it. |
The names of these three statuses are shown in English in every language. You can change them, like any other status, in Shop Parameters → Statuses.
Webhooks
Webhooks are the notifications Stripe sends your store when something changes on a payment. They are essential: some payments are confirmed hours or days later (a voucher, a SEPA direct debit) and in others the customer pays but never makes it back to the store. Without webhooks, those orders would never find out.
1
Copy your store's URL
It is in the module's Stripe tab, with a button to copy it to the clipboard.
2
Register the endpoint in Stripe
In your Stripe dashboard, under Developers → Webhooks, add that address as a destination and tick the six events in the table below. If you leave one out, your store will not find out what that event reports.
3
Paste the secret into the module
Stripe gives you a signing secret for that endpoint: copy it into "Webhook secret".
The module handles these events:
| Event |
What the module does |
charge.succeeded |
Accepts the payment and marks the order as paid. |
charge.failed |
Marks the payment as failed and moves the order to error. |
charge.expired |
Cancels the payment when the charge expires without completing. |
charge.dispute.created |
Moves the order to the disputed payment status. |
payment_intent.succeeded |
Confirms voucher payments when the customer pays them. |
payment_intent.payment_failed |
Marks the payment as failed when the voucher expires or the charge is declined. |
A charged payment never ends up without an order. If the customer pays and does not return to the store —because they closed the PayPal window after authorising the payment, for example—, the module creates the order anyway when Stripe's notification arrives, checking first that it does not already exist so it is not duplicated.
Every notification is validated against the webhook secret signature: if it does not match, it is rejected. And the module only handles the ones carrying its own mark, so notifications from other Stripe integrations on the same account are ignored without touching anything.
Payment flows
Not all methods behave the same way, and knowing which group each one belongs to explains why some orders are born paid and others are not.
Payment on the page itself
Card, Apple Pay, Google Pay, Link, BLIK and the integrated form. The customer pays without leaving the checkout: the module prepares the payment while they fill in their details and, on confirmation, the order is created already paid with Stripe's response.
Authorised on the page, charged later
SEPA direct debit. The customer gives their IBAN and authorises the charge without leaving the checkout, just like the previous group, but the bank takes days to execute it: the order is created straight away and is not paid until Stripe reports that the money has arrived. Treat it as a pending payment, not a completed one.
Payment with redirection
iDEAL, Bancontact, Klarna, PayPal, EPS, Przelewy24, TWINT, Afterpay/Clearpay and Affirm. The customer goes out to the provider's page, pays there and returns to the store with the result. If for whatever reason they do not return, the order is created anyway when Stripe reports the payment.
Payment with voucher
Multibanco, OXXO, Boleto and Pix. The order is created in the waiting status and the customer gets the details to pay outside the store. When Stripe confirms the deposit, the order moves to paid on its own.
In the last two groups the order can take a while to be confirmed, so it is best not to prepare the shipment until it leaves the waiting status.
Zero-decimal currencies
Some currencies do not use cents, and Stripe treats them differently from the rest. The module applies this on its own, without you having to configure anything, for these: BIF, CLP, DJF, GNF, JPY, KMF, KRW, MGA, PYG, RWF, UGX, VND, VUV, XAF, XOF and XPF.
If your store sells in any of them, check on a test order that the amount reaching Stripe matches the order amount: that is where you notice whether the currency is properly configured in PrestaShop.
Translations
This section allows you to edit and customize all labels, messages and texts of the module in the different languages available in your store. It is useful to adapt the module to specific terminology of your business or apply translations according to your needs.
Warning: Some expressions use the %s syntax that you should not replace or modify, as they are placeholders for variables that are completed dynamically.
Edit Translations
The module includes a translations editor that allows you to customize all texts in any language installed in your store.
- Access the "Translations" section in the module configuration
- Select the language you want to edit
- Modify text strings as needed
- Click "Save" to apply changes
If you empty a box and save, that translation is deleted and the text goes back to being shown in English. To leave a text as it was, type it again instead of emptying it.
Available Actions
The translations editor includes several actions to manage your translations:
- Save: Saves changes made to translations.
- Save and download: Saves changes and downloads the translations file for backup.
- Share with us: Sends your translations to our PresTeamShop team to include them in future module versions.
- Expand all: Shows all translation sections expanded.
- Collapse all: Hides the content of all sections.
Code Editors
Allows adding custom CSS and JavaScript code directly from the configuration panel, without needing to access server files.
Available editors:
- Custom CSS: Add styles to customize the appearance.
- Custom JavaScript: Add scripts to customize behavior.
Caution: Use this section only if you have technical knowledge. Incorrect code can affect the functioning of the module or the store.
Backups
The backup system allows you to protect the module configuration and restore it when needed.
Generate backup
To create a new backup, click the "Generate new backup" button. The system will create a backup of the module's current configuration: the Stripe keys, the enabled methods with their country and group restrictions, and the express purchase button settings.
Upload backup
If you have a previously downloaded backup, you can upload it by clicking the "Upload backup" button. A dialog will open where you can select the backup ZIP file.
Available backups
The list shows all created backups. You can filter by date using the date selector and refresh the list with the "Refresh list" button.
List actions
Each backup in the list has the following available actions:
Restore backup
Restores module configuration
Download backup
Downloads the ZIP file
Delete backup
Deletes the backup
Caution: Restoring a backup will overwrite the current module configuration. This action cannot be undone.
To restore, click the "Restore backup" button of the backup you want to recover and confirm the action in the dialog.
Compatibility
Where the module works and what is needed in each case.
PrestaShop and PHP
| Environment |
Compatibility |
| PrestaShop |
1.7.6 or higher, including the 8.x and 9.x series |
| PHP |
7.2.5 or higher |
| Multistore |
Yes, the module works on a multistore installation. The configuration is shared: it does not support different keys or methods per store |
| Multi-language |
Yes, with the texts editable from the translations editor |
Devices and wallets
Digital wallets are not decided by the module: they appear if the customer can use them at that moment, and if not, the option is simply not shown.
| Wallet |
Where it appears |
| Apple Pay |
Safari on macOS and iOS, with a card saved on the device |
| Google Pay |
Chrome and compatible browsers, with a card saved in the account |
| Link, PayPal, Amazon Pay and Klarna |
Any modern browser, depending on what Stripe offers for that customer and that order |
Without HTTPS no wallet appears, not even in testing. That is the most common reason for the buttons not showing up in a development environment.
Other modules
| Module |
Tested version |
Notes |
| One Page Checkout PS v5 |
5.3.2 |
Payment form inside the checkout, wallets in the payment list and express purchase buttons in the side cart (from 5.3.1). |
These are the checkouts we test every version against. With another module replacing the purchase process, payment methods should appear as long as it uses PrestaShop's standard integration points, but we cannot claim it as tested: the express purchase buttons and the wallets inside the payment list depend on how that checkout is built. If you use one that is not listed here, test it before opening it to your customers and write to us with the module and its version if something does not fit.