Prestashop

Add Apple Wallet and Google Wallet “Add to Wallet” buttons to a PrestaShop storefront using a module, server-side HMAC signing, and The Wallet Crew cinto SDK.

This integration explains how to add a unique “Add to Wallet” button to the My Account area in PrestaShop. This PrestaShop Apple Wallet / Google Wallet integration helps customers save a loyalty or membership pass (and optionally a wallet gift card) directly in their mobile wallet, using an identifier available in the PrestaShop customer session.

PrestaShop storefront customization is usually done through modules and theme overrides. This guide focuses on a module-based approach to keep secrets server-side and keep the integration maintainable during theme updates.

Real-world examples

• A loyalty program shows “Add to Wallet” on the My Account dashboard for logged-in customers.

• A gift card program renders one button per active gift card in the account area.

• A pick & collect flow renders a pickup pass CTA on an authenticated pickup page, using a pickup reference as identifier.

For generic cinto SDK usage (pass id mode, platform detection, desktop QR customization), see On your website.

How it works

The Wallet Crew cinto SDK renders the correct CTA based on device.

On iOS, the button downloads an Apple Wallet pass. On Android, it opens Google Wallet. On desktop, the SDK redirects to a hosted pass page that can be scanned or opened on mobile.

In this PrestaShop setup, the pass is retrieved using a pass type (example: user) and an external identifier derived from the logged-in customer session. The identifier is signed with an HMAC computed server-side. This keeps the identifier exchange tamper-proof and avoids exposing secrets in the storefront.

The HMAC must be computed server-side. It must not be generated in the browser.

Prerequisites

• A pass template and pass issuance already configured in The Wallet Crew.

• The Wallet Crew tenant id available (used by the SDK script URL).

• A stable identifier available on authenticated pages.

• An external identifier key name agreed during onboarding.

The stable identifier is often the PrestaShop customer id. A project can also use a CRM id if it is stored on the customer entity and stays stable over time.

Implementation approach (module + hook or theme override)

PrestaShop modules can inject blocks into pages using hooks. Themes can also be overridden when a more specific placement is required.

The recommended integration pattern stays consistent with other e-commerce platforms.

1. Read a stable identifier server-side.

2. Compute an HMAC with the tenant secret.

3. Render a cinto container element with pass type, identifier, and HMAC.

4. Load the cinto SDK script once per page.

Where to place the button

Common placements are:

• The My Account dashboard, next to the loyalty or membership number.

• A dedicated Wallet / Loyalty page in the account area.

• A gift card list page, with one button per gift card.

Hook availability depends on the theme and PrestaShop version. Many projects use a module hook for the account dashboard. Some projects use a theme override to place the button in a specific section.

Setup steps

1

Choose the external identifier contract

The Wallet Crew retrieves or creates a pass from:

• passType (example: user)

• externalIdentifier.key (example: prestashop.customer_id)

• externalIdentifier.value (example: the logged-in customer id)

• externalIdentifier.hmac (HMAC-SHA256 of the value)

Identifier keys should stay stable over time. Lowercase keys reduce HTML attribute casing issues and make long-term maintenance easier.

If The Wallet Crew tenant already uses a mixed-case key, changing it can affect existing installations. Treat this as a migration topic.

2

Store tenant configuration and secret server-side

The tenant id can be used client-side. The HMAC secret must remain server-side.

Common approaches in PrestaShop deployments are:

• Environment variables injected by the hosting platform.

• A server-side configuration store managed by the module, with strict access control in the back office.

The secret must not be stored in theme files or rendered in HTML. Only the computed HMAC should reach the storefront.

3

Build a small module that renders the button

The module typically:

• Registers on an account-related hook, or provides a small controller for a dedicated account page.

• Reads the logged-in customer id from the session context.

• Computes the HMAC using the server-side secret.

• Assigns tenant id, pass type, identifier value, and HMAC to the template variables.

Caching should be handled explicitly. Account pages must not be cached across customers.

4

Load the cinto SDK once per page

The cinto SDK loader should be included once per page. When several buttons exist on the same page, the loader should be placed in a shared footer or header partial and the button markup should be repeated per pass.

If the storefront uses security headers that restrict third-party scripts, allowlisting the SDK host is required.

Validate the result

Validation typically covers platform rendering and pass installation.

1. On iOS Safari, the CTA should display Add to Apple Wallet.

2. On Android Chrome, the CTA should display Add to Google Wallet.

3. On desktop, the CTA should redirect to a hosted pass page.

4. After installation, the pass should be visible in Apple Wallet or Google Wallet.

Troubleshooting

The button does not render

The most common causes are blocked SDK loading (CSP or script restrictions) or missing markup. The final HTML should contain:

• one cinto SDK loader script

• one container element configured as an “Add to Wallet” button

Clicking the button leads to an error

This usually means the external identifier or HMAC does not match what The Wallet Crew expects. Confirm:

• The external identifier key name matches the one configured for the tenant.

• The identifier value matches exactly what is signed server-side.

• The HMAC is computed with the correct tenant secret.

The button renders for the wrong customer

This typically indicates caching across sessions. Confirm that:

• account pages are not cached at page level

• any reverse proxy or CDN respects session cookies on authenticated routes

FAQ

Does this require a custom PrestaShop module?

A theme override can be enough when server-side values are already available in the template context. A dedicated module is usually preferred. It keeps HMAC computation out of theme templates and centralizes secret loading.

Which identifier works best for loyalty passes?

The PrestaShop customer id is commonly used because it is stable and available in the logged-in session. A project can also use a CRM id if it is persisted on the customer and stays stable over time.

Where should the HMAC secret be stored?

The secret should remain server-side. Environment variables or a protected module configuration store are common approaches. It must never be exposed in templates or browser code.

Can the same approach be used for gift cards?

Yes. The same pattern works as long as a stable gift card identifier exists and can be signed server-side. Many projects render one button per gift card in the account area, with a dedicated pass type for gift cards.

Can the button be displayed outside My Account?

Yes. Any authenticated page that has access to the stable identifier server-side can render the button. Common examples are a loyalty dashboard, a gift card list page, or a pick & collect page when a pickup pass is used as an in-store scan token.