Quick facts
- Price
- $299.00 USD
- Odoo versions
- 17, 18, 19
- Setup time
- 30 min
- License
- One-time perpetual
- Languages
- 11 languages
One-time Purchase
Save Payment Token In Back-end
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.
$299.00USD
No payment now. This sends a quote request to our team — we'll follow up by email with pricing and next steps.
Key Features
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
Optional `base_automation` / server actions to flag or notify on cards nearing expiry
Intake form hardening: honeypot, throttling, and server-side validation on the website controller
Full audit trail of who captured, viewed, and charged each token, written to the chatter / mail.thread
XML-RPC / JSON-RPC exposure so external systems can create partners and trigger charges against saved tokens
Multi-company aware token isolation (optional scope) so a card saved in one company is not chargeable from another
Odoo 17.0 / 18.0 / 19.0 compatible builds, with Community vs Enterprise behavior reconciled at design time
Configurable mapping from form submissions to lead / partner creation so captured cards attach to the right CRM record
Clean uninstall and data-retention hooks so tokens can be purged in line with your retention policy
About this Product
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.
Why Choose Save Payment Token In Back-end
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.
What you get
- Installable, version-pinned source code for your Odoo edition (17.0 / 18.0 / 19.0) as a self-contained addon
- Installation and configuration on your environment, including acquirer/provider wiring and security-group setup
- Technical documentation: model/field reference, controller endpoints, access rules, and API usage notes
- End-user guide plus a live training session for your sales and finance teams
- UAT on a staging database with a documented test plan and a rollback plan before production cutover
- A post-go-live support window for defect fixes and configuration adjustments
- Git repository handover with full commit history and tagged release
- Compliance handoff notes covering the tokenization boundary and your PCI-scope responsibilities
Who this is for
Sales operations lead
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.
Finance / compliance manager
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.
Odoo administrator / IT lead
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.
Service or rental business owner
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.
Installation overview
Download from ECOSIRE
Buy the license on ecosire.com and download the Save Payment Token In Back-end module ZIP from your account dashboard.
Upload to Odoo
Extract the ZIP into your Odoo custom addons folder on the server (or upload via Apps > Install from file on Odoo.sh / runbot).
Install the module
Activate Developer Mode, open Apps, click Update Apps List, search for Save Payment Token In Back-end, and press Install.
Configure settings
Open the new menu, paste your ECOSIRE license key, connect any external credentials (Shopify, Amazon, Stripe, etc.), and save.
Verify & go live
Run the built-in connection test, sync your first 10 records, and schedule the recurring cron. Contact support if anything fails.
How Save Payment Token In Back-end Compares
| Criterion | ECOSIRE | Custom Build | Competitor | Odoo Native |
|---|---|---|---|---|
| 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 |
Frequently Asked Questions about Save Payment Token In Back-end
Do you store the actual credit card number in Odoo?
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.
How long does delivery take?
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.
How does pricing and scoping work?
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.
What support and updates do I get after go-live?
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.
Does it work on Odoo Community as well as Enterprise?
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.
Can external systems charge the saved cards?
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.
Which acquirers / payment gateways are supported?
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.
Related Modules
Request a quote
Save Payment Token In Back-end
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.
- 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