Apple Pay & Google Pay Express for Odoo

Key Features

Native Apple Pay and Google Pay express buttons rendered on the product detail page, cart, and checkout via QWeb/OWL template inheritance (xpath), styled to your theme

Browser Payment Request API and Apple Pay JS session handling — the wallet sheet opens client-side and returns contact, billing, and shipping data without a full page redirect

Server-side mapping of wallet-supplied address onto res.partner and sale.order over a JSON-RPC controller, reusing Odoo onchange/compute so taxes and totals stay correct

Dynamic shipping-option callback: delivery methods and rates are computed and returned into the native wallet sheet so the shopper selects a carrier inside the sheet

Finalization through your existing payment.provider and payment.transaction records — no parallel payment path, full reconciliation and refund support intact

Automated Apple Pay domain verification: apple-developer-merchantid-domain-association hosting and merchant-validation callback handled by a configuration action per domain and staging environment

SCA / 3-D Secure frictionless authorization path preserved end-to-end so low-risk transactions complete without an extra challenge step

payment.transaction model extension carrying the wallet token, merchant session, and network reference for audit and settlement matching

Guest-checkout and logged-in-portal-user express flows both supported, with public-user and multi-company boundaries enforced via ir.model.access.csv and record rules

Graceful capability detection: buttons only render when the browser and device actually support the wallet, falling back cleanly to the standard checkout otherwise

Configurable button placement, label, and per-website enablement so multi-website Odoo instances can turn express wallets on selectively

Idempotent order creation on the express endpoint to prevent duplicate sale.order records from double-taps or retried sessions

Works with website_sale delivery, coupons/loyalty, and eWallet where present, so express orders honor the same promotions as the standard cart

Compatible with Odoo 17.0, 18.0, and 19.0 on Community or Enterprise (wallet availability depends on your configured acquirer, not the edition)

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your Odoo.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

Mobile shoppers abandon carts when they are forced to hand-type addresses and card numbers on a small screen. Odoo's native eCommerce checkout is a multi-step flow — address form, delivery method, then a payment provider redirect — and while providers like Stripe or Adyen can surface Apple Pay or Google Pay inside their hosted payment element, Odoo core gives you no express "buy now" wallet button on the product page or in the cart, no way to let the wallet supply the shipping address before an order even exists, and no shortcut past the address and delivery steps. That is where most one-tap conversion is won or lost, and it is exactly where the native flow runs out of road.

ECOSIRE builds a dedicated Odoo module that renders native Apple Pay and Google Pay express buttons directly on the product detail page (PDP), the cart summary, and the checkout. When a shopper taps the button, the module invokes the browser's Payment Request / Apple Pay JS session, receives the wallet-supplied contact, billing, and shipping details, and maps them onto a sale.order and res.partner server-side over a controller endpoint (JSON-RPC), calling onchange/compute logic so taxes, delivery methods, and totals recompute exactly as they would in the standard flow. Shipping options are returned to the wallet sheet dynamically, the shopper picks one inside the native sheet, and the module finalizes the transaction through your existing payment.provider / payment.transaction records so the acquirer, SCA (3-D Secure) frictionless flow, and reconciliation all work the way Odoo expects — no parallel payment path, no shadow ledger.

Technically, the module ships a clean __manifest__.py declaring dependencies on payment, website_sale, and sale, new OWL/QWeb templates that inject the wallet buttons into the website views via XML inheritance (xpath), a Python controller extending WebsiteSale for the express endpoints, and model extensions on payment.transaction to carry the wallet token and merchant session data. Access is governed by ir.model.access.csv and record rules so express orders respect the same multi-company and portal-user boundaries as any other order. Domain verification for Apple Pay — the apple-developer-merchantid-domain-association file and the merchant validation callback — is automated by a configuration action so your team is not manually placing files on the server for every domain and staging environment. Everything is version-matched to Odoo 17.0, 18.0, or 19.0, and works with Community or Enterprise (the wallet capability depends on your acquirer, not the edition).

Because this is a build-to-order engagement, you are not downloading a generic add-on and hoping it fits. We start with a short scoping call to confirm your acquirer (Stripe, Adyen, or another supported provider), your Odoo version and edition, your theme, and which pages you want the express buttons on. We then build against your exact setup, validate on a staging instance with real UAT against Apple Pay and Google Pay sandbox credentials, and hand over installable source, a git repository, and documentation. Typical delivery is 2 to 4 weeks from confirmed scope, and you get a post-go-live support window after launch.

What you get

Installable Odoo module source code built for your exact version (17.0, 18.0, or 19.0) and edition

Installation and configuration on your environment, including acquirer wiring and Apple Pay domain verification setup

Technical documentation: manifest, models, controller endpoints, security rules, and configuration reference

End-user guide plus a live training session for your team on operating and monitoring express wallet orders

UAT on a staging instance against Apple Pay and Google Pay sandbox credentials, with a documented rollback plan

Post-go-live support window for defect fixes and configuration questions after launch

Git repository handover with full commit history so your team owns and can extend the code

Version-compatibility notes and an upgrade path summary for future Odoo major releases

Who this is for

Mobile-heavy DTC merchant

Runs an Odoo eCommerce storefront where most traffic is on phones and sees cart abandonment spike at the address and payment steps. Needs a one-tap wallet button on the PDP and cart to capture impulse purchases before the shopper drops off.

Head of eCommerce / conversion owner

Owns checkout conversion rate and mobile revenue. Wants express wallets that pass wallet-supplied shipping into the standard order flow so promotions, taxes, and delivery methods still apply, without a bolt-on that breaks reporting.

Odoo technical lead / systems integrator

Maintains the Odoo instance and needs a module that follows framework conventions — clean manifest, controller extensions, record rules, no core patching — so it survives upgrades and integrates with the existing payment.provider setup they already configured.

Finance / reconciliation manager

Needs express wallet transactions to settle through the same payment.transaction records and acquirer as every other order, with the network reference and token stored for audit, so month-end reconciliation and refunds require no special handling.

How Apple Pay & Google Pay Express for Odoo Compares

Criterion	ECOSIRE	Custom Build	Competitor
Express button placement	Apple Pay & Google Pay buttons on PDP, cart, and checkout, theme-styled	Whatever you build; PDP-level wallet buttons are non-trivial to get right	Often checkout-only, limited placement control
Wallet-supplied shipping address	Mapped to res.partner/sale.order with onchange + delivery callback into the sheet	Must be built and tested against the Payment Request API yourself	Varies; many skip dynamic shipping-option callbacks
Odoo version & edition fit	Built for your exact 17.0/18.0/19.0, Community or Enterprise	Depends on your team's Odoo depth	Generic build; may lag on newest major or edition specifics
Apple Pay domain verification	Automated per domain and staging via a config action	Manual file hosting and callback wiring you implement	Usually manual, documented as a setup step
Acquirer & reconciliation integrity	Finalizes through your payment.transaction; refunds and settlement intact	Risk of a parallel path if not carefully integrated	Generally integrated but varies by module quality
Source code & ownership	Full git repo handover, you own and can extend it	You own it but carry all build cost and risk	Often licensed/obfuscated, limited modification rights
Support & fit to your setup	Scoped to your acquirer/theme, UAT on staging, post-go-live support window	Self-supported unless you hire it out	Generic vendor support, not tailored to your instance
Time to value	2-4 weeks build-to-order, validated before go-live	Unpredictable; depends on in-house capacity	Fast to install but integration and edge cases fall on you

Frequently Asked Questions about Apple Pay & Google Pay Express for Odoo

How long does delivery take?

This is a build-to-order module, not an instant download. Typical delivery is 2 to 4 weeks from confirmed scope. After the scoping call we agree on your Odoo version, acquirer, and page placements, then build against your exact setup, validate on staging with wallet sandbox credentials, and schedule go-live. Timelines depend on your acquirer readiness and how many websites or domains need Apple Pay verification.

How do support and updates work after launch?

Every engagement includes a post-go-live support window for defect fixes and configuration questions. You receive the full git repository so your team can maintain and extend the code. For future Odoo major-version upgrades or new features, we scope those as a follow-on. We can also provide an ongoing support and maintenance retainer if you prefer us to own updates.

Do I need Odoo Enterprise, or does this work on Community?

It works on both Community and Enterprise for Odoo 17.0, 18.0, and 19.0. The wallet capability depends on your payment acquirer (for example Stripe or Adyen supporting Apple Pay and Google Pay), not on the Odoo edition. During scoping we confirm your acquirer supports the wallets in your region and currencies.

Which payment providers are supported?

Apple Pay and Google Pay are surfaced through acquirers that support them in Odoo's payment framework, such as Stripe and Adyen. The module finalizes through your existing payment.provider and payment.transaction records, so it does not replace your acquirer — it adds the express button experience on top of it. Tell us your acquirer on the scoping call and we confirm compatibility before we build.

Does the wallet-supplied address flow through Odoo's normal tax and delivery logic?

Yes. When the wallet returns the shipping and billing details, the module maps them onto res.partner and sale.order server-side and calls the same onchange and compute logic Odoo uses in the standard checkout. Taxes recompute by fiscal position, delivery methods and rates are returned into the wallet sheet for selection, and coupons or loyalty apply as they normally would.

Will this break when I upgrade Odoo?

The module is built to framework conventions — QWeb/OWL template inheritance via xpath, controller extension, and model extensions rather than core patching — which minimizes upgrade friction. It is version-matched to your Odoo major release. When you move to a new major version we scope a compatibility pass; the git handover means your own team can also perform the migration.

How does Apple Pay domain verification work across staging and production?

Apple Pay requires hosting the apple-developer-merchantid-domain-association file and responding to a merchant-validation callback per domain. The module includes a configuration action that automates hosting the association file and handling the callback, so registering staging, production, and any additional website domains does not require manual server file placement each time.