A build-to-order Odoo module that lets your team securely capture card details submitted through website contact and intake forms and store them as gateway payment tokens in the back-end for later charging. ECOSIRE scopes, builds, installs, and supports it — nothing is charged or stored until you confirm the design. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $299.00 USD; request a quote for a scoped proposal.

A build-to-order Odoo module that lets your team securely capture card details submitted through website contact and intake forms and store them as gateway payment tokens in the back-end for later charging. ECOSIRE scopes, builds, installs, and supports it — nothing is charged or stored until you confirm the design.
今すぐのお支払いはありません。これはチームへの見積もり依頼を送信します。価格と次のステップをメールでご案内します。
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.
Client-side tokenization via the acquirer's hosted fields / JS SDK so raw PAN never reaches the Odoo server, DB, or logs
Website controller endpoint that receives only the gateway token plus masked card metadata (last four, brand, expiry) and persists a standard `payment.token`
Saved cards linked to `res.partner` and surfaced on the sale order, reusing Odoo's native `payment.token` object for downstream charging
Back-end "Charge saved card" server action that creates a `payment.transaction` through the acquirer's existing provider flow
`ir.model.access.csv` plus record rules restricting token visibility and charge rights to nominated sales/finance security groups
Computed `@api.depends` fields for masked number, card brand, and an expiry-status indicator on the token form
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 2 to 4 weeks from confirmed scope, including UAT on a staging database before anything touches production. Pricing starts from $299 (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.
Runs the quote-to-cash flow in Odoo and needs agents to capture a customer's card at enquiry time and charge it from the back-end once the deal is confirmed, without handling raw card numbers.
Owns PCI posture and wants card capture pushed to gateway tokenization so raw PANs never land in Odoo, with strict record rules and a full audit trail over who can view or charge saved cards.
Maintains the instance across 17/18/19 and Community vs Enterprise, and needs a clean addon with proper `ir.model.access.csv`, upgrade-safe models, and no untracked customizations bolted onto core.
Takes deposits and recurring charges against cards on file and needs a reliable, supported way to store tokens on the partner and trigger charges as bookings and orders progress.
ecosire.com でライセンスを購入し、アカウント ダッシュボードから Save Payment Token In Back-end モジュールの ZIP をダウンロードします。
ZIP をサーバー上の Odoo カスタム アドオン フォルダーに抽出します (または、[アプリ] > [Odoo.sh / runbot のファイルからインストール] を介してアップロードします)。
開発者モードをアクティブにし、アプリを開き、「アプリリストの更新」をクリックして、「Save Payment Token In Back-end」を検索し、「インストール」を押します。
新しいメニューを開き、ECOSIRE ライセンス キーを貼り付け、外部認証情報 (Shopify、Amazon、Stripe など) を接続して保存します。
組み込みの接続テストを実行し、最初の 10 レコードを同期し、定期的な cron をスケジュールします。何か問題が発生した場合はサポートにお問い合わせください。
| 基準 | エコシエール | カスタムビルド | 競合他社 | オドゥー ネイティブ |
|---|---|---|---|---|
| Card capture on a contact/intake form | Purpose-built hardened website form wired to gateway tokenization | Possible but you design and secure the whole flow | Often assumes checkout/portal context, not a marketing form | |
| Where raw PAN lives | Never touches Odoo — tokenized client-side at the acquirer | Depends entirely on your implementation discipline | Varies; some persist unsafe data if misconfigured | |
| Access control over saved cards | Scoped `ir.model.access.csv` + record rules per your groups | You must author and test every rule | Generic defaults, rarely tailored to your groups | |
| Charging from the back-end | Audited server action creating `payment.transaction` on the token | Build the action and audit trail yourself | Charge UX inconsistent; audit trail often absent | |
| Odoo 17/18/19 + Community vs Enterprise | Version-pinned build, edition differences reconciled at design | Your team owns cross-version compatibility | Version support varies; edition gaps often unstated | |
| External API charging | XML-RPC / JSON-RPC ready against standard `payment.token` | Achievable with additional development | Usually not exposed for headless use | |
| Delivery model | Build-to-order: scoped, built, installed, supported (2-4 wks) | Depends on in-house capacity and backlog | Instant download, but you integrate and maintain it | |
| Support & handover | Docs, training, support window, full git repo handover | Internal knowledge only unless documented | Vendor forum / ticket support, no code ownership |
No. Card fields are tokenized client-side by your acquirer's hosted fields or JS SDK, so the raw PAN never reaches your Odoo server or database. We only persist the gateway-issued token plus masked metadata (last four, brand, expiry), which keeps the sensitive data inside your acquirer's PCI scope rather than yours.
Because this is build-to-order, work begins after a scoping call — not an instant download. Typical delivery is 2 to 4 weeks from confirmed scope, including UAT on a staging database before anything reaches production. Larger scopes (multiple acquirers, multi-company isolation, data migration) can extend that, which we state in the quote.
Pricing starts from $299 as an indicative single-company base scope for one acquirer and one intake form. After a short scoping call we confirm your acquirers, forms, security groups, and compliance needs and issue a firm, fixed quote and signed scope. Drivers like extra acquirers, localization depth, or migrating existing stored cards adjust the final figure.
Every build includes a post-go-live support window for defect fixes and configuration adjustments, plus the full git repository so you own the code. Version upgrades (for example moving from 18.0 to 19.0) or new acquirers are handled as a scoped follow-on engagement rather than a silent auto-update.
Yes, we support 17.0, 18.0, and 19.0 on both editions. Some capabilities rely on Enterprise's built-in saved-payment-method framework; where that applies we tell you at design time and adapt the module so behavior is consistent on your edition rather than assuming a feature that isn't there.
Yes. Tokens are stored as standard `payment.token` records tied to your acquirer's provider, so they are chargeable through Odoo's native payment flows and via the XML-RPC / JSON-RPC API — letting a headless storefront, subscription engine, or middleware create partners and trigger charges against a card on file.
Any acquirer that offers client-side tokenization and is (or can be) configured as a payment provider in your Odoo instance. During scoping we confirm your specific gateway and wire the intake form to its hosted fields; supporting an additional acquirer later is a defined add-on to scope.
A build-to-order Odoo module that lets your team securely capture card details submitted through website contact and intake forms and store them as gateway payment tokens in the back-end for later charging. ECOSIRE scopes, builds, installs, and supports it — nothing is charged or stored until you confirm the design.