pos_payment_provider_cards

Connecting a card terminal to Odoo means installing the right integration module and then configuring a payment method to use it. Those are two screens apart, and knowing which module goes with which terminal is its own piece of knowledge.

This widget collapses both. It shows a card per supported provider, tells you whether that provider's module is installed, offers to install it, and once installed fills the payment method's fields for you.

The provider list is not discovered: it is a table in the source, currently fourteen entries pairing a selection value, a module name and a display name.

Terminal choice is usually decided by your acquirer rather than by preference, so the real value here is removing the lookup step: which Odoo module corresponds to the terminal your bank supplied.

The hard-coded list is worth knowing about when planning. A provider not in that table is not offered here, which does not mean it cannot be integrated, only that it is not one of the fourteen with a first-party module.

Placing it

<widget name="pos_payment_provider_cards"/>

No attributes. It reads the payment method from the record.

A table entry

["stripe", "pos_stripe", "Stripe"]
# selection value, module, display name

Fourteen of these in the file.

What setup writes

payment_method_type   = "terminal"
use_payment_terminal  = the selection value
name                  = the display name

Three fields, no server call.

The startup sequence is one call for fourteen providers, which is the right shape: asking per provider would be fourteen round trips for a screen that renders once.

What comes back is a list of module states, and the widget joins it against the hard-coded table by module name. Providers with no matching state are dropped. The surviving entries carry the selection value and display name from the table plus the state from the server, merged into one object per card.

Installing is guarded. The record is saved first and the handler returns if that failed, because installing a module reloads the page and unsaved edits would be lost. A disabled flag is raised during the install and cleared in a finally block, so a failure does not leave the buttons permanently dead.

A successful install reloads the whole page rather than refreshing the view, which is necessary because a new module brings new assets that the running page has not loaded.

Setup is the cheap half: it finds the provider in the already loaded state and writes three fields on the record. No server call, because nothing needs to be looked up.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The development branch is unstable and this may still change; we re-verify this page after the release.

Reworked. The development branch changes the component substantially, including the provider handling. The card grid and the install then configure flow are what to expect to survive; the table's contents are likely to shift as providers are added.