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
POS Card Terminal Payment Connector for Odoo
A build-to-order Odoo POS payment connector that pairs physical card terminals (Stripe Terminal, PAX, Ingenico) to your point of sale for tap, chip and contactless capture, with refunds, tips and cashback handled straight from the receipt. ECOSIRE builds, installs and supports it for Odoo 17, 18 and 19.
$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
Custom `pos.payment.method` provider with an OWL/JS `PaymentInterface` subclass driving the terminal directly from the POS Validate screen
Stripe Terminal integration via server-driven `PaymentIntent` create/capture, with reader discovery and connection-token handling
PAX and Ingenico support over semi-integrated ECR (local LAN/serial) or the vendor's cloud terminal API, matched to your device firmware
Tap, chip (EMV) and contactless capture with card brand, last-four and acquirer reference written back onto the `pos.payment` record
Exact order total pushed to the terminal on Validate — cashier never re-keys the amount, eliminating amount-mismatch errors
Linked refund from the original POS receipt using the stored acquirer transaction reference, tied to the Odoo credit note
Tip adjustment posted to a configurable `account.account`, plus cashback recorded as a cash payout line where hardware supports it
Terminal timeout, decline, cancel and partial-approval states surfaced in the POS UI with clean retry and void handling
Full terminal round-trip audit log (request, response, reference) for chargeback and dispute investigation
`ir.model.access.csv` plus record rules restricting acquirer credentials and raw transaction logs to nominated roles
End-of-day reconciliation view and optional QWeb settlement report matching the acquirer batch against the POS session close
Multi-terminal / multi-till routing — bind specific readers to specific POS configs so each register talks to its own device
Credentials and endpoints held in `ir.config_parameter` / dedicated config models, never hardcoded, with per-environment values
JSON-RPC / XML-RPC reachable payment routing for kiosk and self-checkout tills, plus offline-queue handling for dropped links
About this Product
Retail and F&B teams lose real money at the counter when the card terminal and the point of sale don't talk to each other. Cashiers key the amount into a standalone PAX or Ingenico device by hand, then mark the order paid in Odoo POS — two separate acts that drift apart. Odoo Community ships no certified in-store card acquiring at all, and while Odoo Enterprise offers a handful of built-in terminal integrations (Stripe Terminal, Adyen, Viva, SIX/Worldline in specific regions), the moment your acquirer, device model, or country falls outside that supported matrix, native runs out of road. You are left with mistyped amounts, no automatic reconciliation between the acquirer batch and Odoo's pos.payment records, and refunds that have to be processed on the terminal separately from the credit note.
Why Choose POS Card Terminal Payment Connector for Odoo
Custom `pos.payment.method` provider with an OWL/JS `PaymentInterface` subclass driving the terminal directly from the POS Validate screen
Stripe Terminal integration via server-driven `PaymentIntent` create/capture, with reader discovery and connection-token handling
PAX and Ingenico support over semi-integrated ECR (local LAN/serial) or the vendor's cloud terminal API, matched to your device firmware
Tap, chip (EMV) and contactless capture with card brand, last-four and acquirer reference written back onto the `pos.payment` record
Exact order total pushed to the terminal on Validate — cashier never re-keys the amount, eliminating amount-mismatch errors
Linked refund from the original POS receipt using the stored acquirer transaction reference, tied to the Odoo credit note
ECOSIRE builds a payment connector that binds your specific terminals to Odoo POS as a first-class pos.payment.method. Technically, we extend the POS payment interface — an OWL/JS PaymentInterface subclass on the frontend paired with a pos.payment.method provider and server-side models.Model records that hold terminal identifiers, acquirer credentials, and routing rules. When the cashier hits Validate, the exact order total is pushed to the paired terminal over the vendor path that fits your hardware: Stripe Terminal's server-driven PaymentIntent flow, or PAX/Ingenico via their local LAN/semi-integrated ECR protocol (or a cloud terminal API where the device supports it). The terminal captures tap, chip, or contactless; the authorization result, card brand, last-four, and acquirer reference flow back and are written onto the pos.payment line so the sale and the settlement are a single reconciled fact.
The build covers the operations that break in a manual setup. Refunds are driven from the original POS receipt — we look up the stored acquirer transaction reference and issue a linked refund to the same card rather than a blind new charge, keeping the credit note and the acquirer reversal tied together. Tip adjustment and cashback are handled inline where the acquirer and hardware support them, with the tip posted to the configured account.account and cashback recorded as a cash payout line. Access is locked down through ir.model.access.csv and record rules so terminal credentials and raw transaction logs are visible only to the roles you nominate, and every terminal round-trip is logged for dispute handling. Reconciliation views and an optional QWeb end-of-day settlement report line the acquirer batch up against Odoo's POS session closing, and where you run headless tills or kiosks the same routing is reachable over Odoo's JSON-RPC/XML-RPC API.
Because this is built to order, nothing ships as a blind download. We start with a scoping call to confirm your exact terminal models, acquirer(s), country, and Odoo edition and version (we support 17.0, 18.0 and 19.0, Community or Enterprise), then agree the connection method — semi-integrated ECR, cloud terminal API, or Stripe Terminal server-driven — because that single decision shapes the whole integration. From confirmed scope, typical delivery is 2 to 4 weeks: we develop against a staging copy of your database, run UAT on real hardware with test cards, and only then schedule the production cutover with a rollback plan. You receive the full installable source for your version, a git repository handover, and a defined post-go-live support window — no vendor lock, no black box.
What you get
- Installable Odoo module source code built for your exact version (17.0, 18.0 or 19.0) and edition (Community or Enterprise)
- Installation and configuration on your environment — payment method setup, terminal pairing, and acquirer credential wiring
- Technical documentation: models, `pos.payment.method` provider design, connection protocol, and security (access rules) reference
- Cashier and manager user guide plus a live training session covering charge, refund, tip, cashback and end-of-day reconciliation
- UAT on a staging copy of your database with real terminal hardware and test cards, plus a documented production rollback plan
- Defined post-go-live support window for defect fixes and configuration adjustments after cutover
- Git repository handover with full commit history — you own the source, no vendor lock-in
- End-of-day reconciliation view and optional QWeb settlement report configured to your POS session workflow
Who this is for
Multi-lane retail store manager
Runs several POS registers and needs each till bound to its own card terminal, with amounts pushed automatically and the acquirer batch reconciling cleanly against every POS session close — no more end-of-day discrepancies from hand-keyed totals.
F&B / restaurant operator
Needs fast tap-and-go payment at the table or counter, plus tip adjustment posted to the right account and the occasional cashback payout, all captured on the terminal and reflected on the Odoo receipt in one step.
Merchant on an unsupported acquirer or device
Already committed to a specific PAX or Ingenico model or a regional acquirer that Odoo's built-in terminal list doesn't cover, and needs a connector built to that exact hardware and semi-integrated protocol.
IT lead / Odoo administrator
Owns the deployment across 17/18/19 and wants secured credentials, role-scoped access via record rules, a full transaction audit trail, and a clean git handover they can maintain in-house.
Installation overview
Download from ECOSIRE
Buy the license on ecosire.com and download the POS Card Terminal Payment Connector for Odoo 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 POS Card Terminal Payment Connector for Odoo, 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 POS Card Terminal Payment Connector for Odoo Compares
| Criterion | ECOSIRE | Custom Build | Competitor | Odoo Native |
|---|---|---|---|---|
| Terminal / acquirer coverage | Built to your exact PAX/Ingenico/Stripe device and acquirer | Whatever your in-house team can build and maintain | Fixed to the acquirers the listing chose | |
| Odoo Community support | Yes — 17/18/19, Community or Enterprise | Possible but you build it | Varies; many are Enterprise-oriented | |
| Amount routing | Exact total pushed on Validate, no re-keying | Depends on your implementation | Usually supported for its target devices | |
| Refund from receipt | Linked refund to original reference + credit note | Must be built and tested by you | Often blind refund, weak reconciliation | |
| Tips & cashback | Posted to configured accounts where hardware allows | Extra scope you specify and fund | Rarely both, if at all | |
| Reconciliation | Batch-vs-POS-session view + optional QWeb report | You design the reconciliation yourself | Basic or none | |
| Source & ownership | Full source + git repo handover, no lock-in | You own it but carry all the effort | Encrypted/obfuscated in many cases | |
| Support path | Scoping, UAT, rollback + post-go-live window | Your team is the only support line | Ticket queue, no scope guarantee |
Frequently Asked Questions about POS Card Terminal Payment Connector for Odoo
+How long does delivery take?
This is a build-to-order module, so nothing ships as an instant download. After a scoping call to confirm your terminal models, acquirer, country and Odoo version, typical delivery is 2 to 4 weeks from confirmed scope. That window includes development against a staging copy of your database, UAT on real hardware with test cards, and a scheduled production cutover with a rollback plan.
+Which card terminals and acquirers do you support?
We build for Stripe Terminal (server-driven PaymentIntent flow), PAX and Ingenico devices over their semi-integrated ECR protocol or cloud terminal API where available. Because the connection method differs per acquirer, device model, country and firmware, we confirm your exact hardware on the scoping call and build the connector to match — rather than shipping a one-size-fits-all integration.
+Does this work with Odoo Community or only Enterprise?
Both. We support Odoo 17.0, 18.0 and 19.0 on Community and Enterprise. Odoo Enterprise ships a limited set of built-in terminal integrations for specific regions; Community ships none. This connector is built for cases where your acquirer, device or country falls outside Odoo's native matrix, or where you need routing, reconciliation and refund behaviour that native doesn't provide.
+How are refunds handled?
Refunds are driven from the original POS receipt. We store the acquirer transaction reference on the `pos.payment` record at sale time, then issue a linked refund to the same card and tie it to the Odoo credit note — rather than processing a blind new charge on the terminal that never reconciles back to the original sale.
+What about tips and cashback?
Where your acquirer and hardware support them, tip adjustment is captured on the terminal and posted to a configurable account, and cashback is recorded as a cash payout line on the order. We confirm which of these your specific device supports during scoping, since not every terminal exposes tip-on-device or cashback.
+What do we get, and do we own the code?
You receive the full installable source for your Odoo version, installation and configuration, technical docs, a user guide plus training, UAT on staging with a rollback plan, and a git repository handover. You own the source outright — no vendor lock-in, no black box.
+How do updates and support work after go-live?
Every build includes a defined post-go-live support window for defect fixes and configuration adjustments. Beyond that, because you hold the git repository you can maintain it in-house, or engage ECOSIRE for version upgrades (for example moving the connector from 18.0 to 19.0) and enhancements under a separate support arrangement.
Related Modules
Request a quote
POS Card Terminal Payment Connector for Odoo
A build-to-order Odoo POS payment connector that pairs physical card terminals (Stripe Terminal, PAX, Ingenico) to your point of sale for tap, chip and contactless capture, with refunds, tips and cashback handled straight from the receipt. ECOSIRE builds, installs and supports it for Odoo 17, 18 and 19.
- Custom `pos.payment.method` provider with an OWL/JS `PaymentInterface` subclass driving the terminal directly from the POS Validate screen
- Stripe Terminal integration via server-driven `PaymentIntent` create/capture, with reader discovery and connection-token handling
- PAX and Ingenico support over semi-integrated ECR (local LAN/serial) or the vendor's cloud terminal API, matched to your device firmware
- Tap, chip (EMV) and contactless capture with card brand, last-four and acquirer reference written back onto the `pos.payment` record