Sales, service, and rental teams that run Odoo frequently need to take a customer's card at the point of enquiry — a website contact form, a quote request, or a booking intake — and hold it on file so an agent can charge it later from the back-end once the order is confirmed. Odoo's native payment stack is built for the checkout flow: a logged-in portal customer completes a payment.transaction and, with Enterprise, a payment.token may be saved. It has no supported path for capturing raw card data on a marketing contact form and turning it into a reusable, PCI-safe token attached to a res.partner without a full e-commerce cart. Teams that try to bridge that gap end up emailing card numbers or pasting them into notes — a serious compliance liability.

We build a made-to-order module that closes this gap correctly. On the website side we render a hardened intake form whose card fields are handled by your acquirer's client-side tokenization (hosted fields / JS SDK), so the raw PAN never touches your Odoo server or database — only the gateway-issued token and the last four digits, brand, and expiry are transmitted back. A controller receives the tokenization result, resolves or creates the res.partner, and persists a payment.token record linked to the acquirer, exactly the object Odoo's own _send_payment_request already knows how to charge. Back-end users see the saved cards on the partner and on the sale order, gated by ir.model.access.csv and record rules so only the sales/finance groups you nominate can view or use them; QWeb-free, the UI is standard OWL list/form views with an audited "Charge saved card" action that creates the payment.transaction server-side.

Technically the build ships as a proper Odoo addon with its own __manifest__.py, models/ extending payment.token/res.partner with @api.depends computed display fields (masked number, expiry status), server actions and optional base_automation rules to flag expiring cards, and a controller layer for the website endpoint. Everything routes through the acquirer provider your instance already uses, so tokens created here are chargeable through Odoo's standard payment flows and via the external XML-RPC/JSON-RPC API for any headless integration. We support Odoo 17.0, 18.0, and 19.0; where a capability depends on Enterprise (e.g. the built-in saved-payment-method framework) versus Community we tell you up front and adapt the design so the module behaves consistently on your edition.

Because this is build-to-order, work starts with a short scoping call, not a download. We confirm your acquirer(s), the forms that will capture cards, the security groups, and your compliance posture, then deliver a fixed quote and a signed scope. Typical delivery is one working week from confirmed scope, including UAT on a staging database before anything touches production. Pricing starts from $999 (indicative, single-company base scope for one acquirer and one intake form); additional acquirers, multi-company token isolation, deeper localization or gateway-specific compliance work, and migrating existing stored cards increase the quoted scope. You receive a firm, fixed quote after the scoping call — never a surprise on the invoice.