Odoo payment provider integration: what it connects and how it works
If your customers need to pay Odoo invoices, portal documents or eCommerce orders online, the integration you need is a payment provider configured inside Odoo, with each payment recorded against the right invoice or order and reconciled in Accounting. That is the core of this page. The payment provider handles the card or wallet transaction, and Odoo records the outcome, links it to the customer document and posts it to the accounting journal. Whether that chain works end to end depends on the provider you choose, the Odoo version and edition you run, and how your payment flows are set up. Odoo's payment providers are configured inside Odoo itself, in the payment provider settings of the Accounting or Website and eCommerce apps. Each provider module adds its own credentials fields, supported payment methods, and enablement options, so the configuration is per provider rather than one generic setup. Before you commit to a provider, confirm the exact provider list, the features each one offers, and any edition requirements against the Odoo version and edition you run, since these change between releases. Check the current documentation and the Odoo Apps Store entry for the provider rather than relying on a summary from a third party.
Do not assume that a provider supports the features your business needs. Tokenization (storing a reusable payment reference so customers can pay again without re-entering card details), manual capture (authorizing a payment now and capturing the funds later, for example when goods ship), refunds initiated from Odoo, and express checkout (wallet or one-click payment buttons on the storefront) are all things that vary by provider and sometimes by Odoo version. For each provider on your shortlist, verify these points in writing: whether the feature exists in your Odoo version, whether it is in the Community or Enterprise edition, which payment methods and countries it covers, and whether the vendor's own account and plan must support it. Reconciliation deserves the same scrutiny as the checkout itself. Ask how a successful payment becomes a journal entry, how fees and payouts are recorded, what happens to partial payments and failed or cancelled transactions, and how a refund or chargeback reverses the original posting. Test these flows in a copy of your database with the provider's sandbox or test mode before go-live. If you run Odoo on-premise, also confirm how the provider's webhooks or return URLs reach your server, because a payment that succeeds at the provider but never returns to Odoo will leave invoices open and cash unmatched. Plan the work as a fixed set of checks rather than a single switch-on. Document which provider is enabled for each website, company and currency, which journals receive the postings, who may configure credentials and who approves refunds, and where API keys are stored. Keep test and production credentials separate, and rehearse the reconciliation close with a sample month of transactions before relying on the integration for real cash.
Costs and effort split across several parties. The provider charges transaction and account fees under its own contract, Odoo's plan or edition determines which apps and integration features you can use, and implementation work covers configuration, testing and reconciliation design. Ask any implementation partner to quote these separately, state which provider features are included, and list what must be confirmed in each provider and Odoo environment before the quote is final. Note that some provider capabilities may depend on your Odoo edition, so the quote should name the edition it assumes.
What you need in place before configuring a payment provider
Payment provider configuration depends on decisions made before anyone opens the provider settings. The six items below set the edition, version, accounts, endpoints, ledger structure and module source that the integration relies on, so gaps found here are cheaper to close than gaps found during testing.
Odoo edition and hosting
Decide between Odoo Online, Odoo.sh and on-premise before choosing a provider, because the hosting type limits what you can install. Odoo's pricing page lists only the Custom plan for Odoo.sh or on-premise hosting, and Custom is also the plan that includes external API access and custom modules. Any connector or custom module you plan to add may depend on that access. Confirm with Odoo which plan and hosting type your contract covers, and whether your edition is Community or Enterprise, since Enterprise source code is not publicly available.
Supported major version
Pick a major version that stays under standard support for the planned life of the integration. Standard support covers the first three years after a major release, including security updates and bug fixes, and security patches are only provided during that window. According to Odoo's support documentation, Odoo 19.0 standard support runs until September 2028 and Odoo 18.0 until September 2027, while Odoo 17.0 standard support ended in September 2026. On Odoo Online and Odoo.sh, major upgrades are mandatory every two years, so schedule the next upgrade alongside the provider setup.
Merchant account with each provider
Each provider you plan to enable needs its own merchant account with live and test credentials. The account must support the payment methods, currencies and countries you intend to sell in. Ask each provider which capabilities its account includes, such as tokenization, manual capture, refunds and express checkout, because some may be enabled or contracted separately. Record the legal entity on the contract and who holds the API keys and webhook secrets, since those credentials are entered into Odoo and must be rotated when staff change. Open test accounts early so the sandbox is ready before go-live.
Public HTTPS base URL for callbacks
Providers send payment status updates to Odoo by calling a public HTTPS address, so the server's base URL must be reachable from the internet with a valid certificate. Set the web.base.url system parameter to that address and confirm that the reverse proxy, firewall and any web application firewall pass the callback paths through unchanged. Internal DNS names, test-only hostnames and self-signed certificates can cause callbacks to fail without a visible error, so test the address from outside your network. If Odoo sits on a private network, plan the inbound routing with your network team first.
Accounting configuration for payments
Payments post into Accounting, so the journals, currencies and payment terms must exist before the first transaction. Define a payment journal for each provider and each currency you accept, and decide which outstanding receipts and payments accounts those journals use. Confirm the chart of accounts, the tax treatment and the payment terms that invoices will carry, because a payment in a currency with no matching journal is harder to reconcile. Ask your finance team who approves journal entries for fees, refunds and chargebacks, since these usually need their own accounts.
Provider module source check
Not every payment provider ships with every Odoo edition and version, so confirm the module source before planning the build. Check whether each provider module is included in your edition and version, comes from the Odoo Apps Store, or is supplied by a partner or the community. Record the module name, version, vendor and license for each one, and confirm it supports your Odoo major version and hosting type. A module that is unavailable or unsupported on Odoo.sh or on-premise may need a custom build, which changes scope and the support you can expect.
How a payment moves from the customer to the Accounting journal
The key point for this section is that a payment in Odoo is not one event. It is a chain of steps across the customer's browser, the payment provider, Odoo's payment module and Accounting, and each step can succeed or fail on its own. The flow usually starts when a customer opens a payment link from an invoice, a link in the customer portal, or a checkout page on an eCommerce site. Odoo creates a transaction record at that point, and the customer is sent to the provider's hosted payment page or an embedded form to enter payment details. Next, the provider either authorizes the amount or captures it. Authorization reserves funds on the card or account, while capture takes the money. Odoo then needs to learn the result. It does this through the return path (the customer is redirected back to Odoo) and through a server-to-server notification, usually called a webhook. Relying on the browser return alone is a common weakness, because a customer can close the window before the redirect completes. Confirm for each provider in scope which notification events Odoo listens to, how it verifies them, and what happens when a notification arrives before or after the redirect.
Once Odoo receives a successful status, it updates the payment transaction and creates a payment record. That record is then matched to the open customer invoice. Matching is what closes the receivable, so the invoice moves toward paid only after this step completes. A transaction can be marked done in the payment module while the matching or posting step is still pending, so check both the transaction status and the invoice status when you test. The choice between authorization and capture timing changes when revenue and bank entries appear. If the provider captures at payment, the payment record and the bank side typically follow soon after the customer pays. If your setup authorizes first and captures later, for example when goods ship or a service is delivered, the funds are reserved but not settled, and the accounting entries and bank movement come later. Decide which pattern fits your revenue recognition policy and your fulfillment process before you configure the provider, because changing it later affects open transactions and reporting periods. Before go-live, confirm with each provider in scope how it handles capture, partial captures, voids, refunds and settlement timing with Odoo, and which Odoo version and provider module that behavior applies to. Ask the provider for its settlement schedule and fee treatment, since the amount that reaches the bank can differ from the invoice amount. Then run one test per scenario: a paid invoice, an authorized but uncaptured payment, a payment where the browser closes before the redirect, and a refund. Record which Accounting journal each one posts to, and confirm that the bank reconciliation step sees the amounts you expect.
How to configure a payment provider in Odoo, step by step
This sequence takes an Odoo database from a confirmed edition and version to a payment provider that records paid invoices and balanced journal entries. Each step is tested on a neutralized copy before live keys are used. The result is a provider configured in Accounting, tested on invoices and the customer portal, and switched to live only after sign-off.
Confirm the Odoo edition and version
Record the edition (Community or Enterprise), the exact Odoo version and the hosting type (Odoo Online, Odoo.sh or on-premise) before you touch the payment settings. Check whether that version is still inside Odoo's standard support window, because security patches are only provided during standard support. Ask the provider's integration documentation which Odoo versions its module supports. Create a neutralized test copy of the production database, as Odoo documents for test databases, and confirm with the vendor what neutralization changes for payment settings. Done when you have a written record of edition, version and hosting, and the test copy is running.
Install the provider module for that version
On the test copy only, install the payment provider module that the provider or its documentation confirms for your exact Odoo version. Do not assume a module built for another version will work, and check the module listing for any dependency that requires an Enterprise subscription. Note any extra modules the provider pulls in, since they affect your upgrade and testing scope later. Done when the installation finishes without errors, the logs show no failed dependencies, and the provider appears in the payment provider list in a disabled state.
Create the provider account and collect API credentials
In the provider's own dashboard, create or confirm the merchant account for the legal entity that receives the money, then open the developer or API section. Collect the test API keys and any webhook signing secret the module requires. Store them in your organization's secrets manager with a named owner, not in tickets, chat or the Odoo notes field. Ask who can rotate the keys and who has dashboard access. Done when the test keys are stored with an owner and the provider dashboard clearly shows that test mode is active.
Set test mode and enter credentials in Odoo
Open the provider record in Odoo Accounting configuration, enter the test credentials and keep the provider in test mode. Link the provider to a dedicated payment or bank journal, and confirm that the currency matches the settlement currency of the provider account and the invoice currencies you plan to accept. Check the journal's default accounts with your accountant before going further. Done when the record saves without a credential error and the journal and currency match what you wrote down in the previous step.
Set the base URL and callback endpoints
Confirm that the web base URL in Odoo's system settings matches the public hostname that customers and the provider will use, including the scheme. A mismatch between the configured address and the public address is a common reason callbacks fail. Copy the return and webhook endpoints generated by the module into the provider dashboard, and confirm that any reverse proxy, load balancer or firewall in your environment allows the provider to reach them. Done when the provider's webhook test reports successful delivery to the endpoint.
Run a test payment on an invoice
In the test copy, create a customer invoice for a small amount in the configured currency and post it. Use the payment link or register the payment through the provider, using the test payment details the provider publishes for its sandbox. Repeat with a partial payment if your process allows partial settlements. Done when the invoice status changes to paid, or the amount due reaches zero, and the provider's test dashboard shows a completed transaction with the same amount and reference.
Test checkout and confirm the payment records
Repeat the payment from the customer portal or the eCommerce checkout while logged in as a portal user, so the path your customers actually use is tested. Then open the payment transaction and the journal entry it created. Confirm that the transaction links to the invoice, that the journal entry debits and credits balance, and that the payment reconciles against the invoice. Ask the provider which refund, capture and tokenization options its module supports, because support differs by provider. Done when the transaction, invoice and journal entry agree on amount, currency and date.
Switch to live credentials after sign-off
After the test results are approved, replace the test keys with live keys in the provider record and switch the state to enabled. Register the live webhook endpoints in the provider's live dashboard, since test and live modes are usually configured separately. Make one low-value live payment from an agreed internal account, then refund it through the provider's documented process. Done when the live transaction appears with a matching journal entry, the refund is recorded, and the test copy still contains only test records.
Which Odoo records map to which provider objects
This table compares each Odoo accounting and sales record with the closest object at the payment provider, and the field used to match an incoming webhook back to the Odoo record. Provider object names, identifiers and webhook payload fields differ between providers, so confirm each one in that provider's own documentation before you finalize the mapping. The main takeaway is that every provider event needs one agreed match field, decided before the build starts.
| Odoo record | Provider object | Field to match provider event | Data owner |
|---|---|---|---|
| Partner | Customer object, if the provider creates one | Provider customer ID, stored on the Odoo partner (confirm the field) | Odoo for invoicing details; provider for any stored payment data |
| Invoice | Payment intent, order or checkout session | Invoice reference sent as provider metadata or description (confirm the key) | Odoo owns the invoice; provider owns the charge state |
| Payment transaction | Charge, payment intent or order ID | Provider transaction ID, plus the Odoo reference sent at creation | Odoo holds the record; provider holds authorization and capture state |
| Payment method | Payment method or token | Provider token or method ID (confirm in the provider API reference) | Provider vault; confirm what Odoo stores locally for each provider |
| Journal | Not a provider object; payouts feed it | Payout or settlement reference matched during reconciliation | Odoo accounting team; finance approves reconciliation |
| Currency | Currency code on charge, refund and payout | Currency code in the event payload (confirm the field name) | Provider for charge currency; Odoo for reporting currency |
| Refund | Refund object linked to the original charge | Refund ID together with the original charge ID | Shared: Odoo credit note or refund record, provider refund state |
| Payout | Payout or settlement batch listing charges and fees | Payout ID, recorded in the reconciliation entry (confirm the Odoo field) | Provider for funds movement; Odoo for bank reconciliation |
How to secure payment credentials, callbacks and card data
Payment integrations connect Odoo to provider accounts, customer portals and checkout pages, so each link in that chain needs an owner and a control. The cards below cover the credentials, access paths, callbacks, transport, data separation and card data scope decisions that determine how exposed the integration is.
Provider key storage and rotation
Provider API keys and webhook signing secrets give access to live payment accounts, so they should never sit in shared spreadsheets, module code or database fields readable by all users. Decide where the secrets are stored in your environment, who can read them, and how a key is replaced without taking checkout offline. Ask the provider how keys are scoped, whether test and live keys are separate, and how revoked keys are handled. Document the rotation procedure and rehearse it on a test database first.
Back-office access by group
Odoo controls payment provider settings, payment transactions, refunds and payment journals through user groups, so a user who can view invoices may not need to configure a provider or issue refunds. Map each payment-related function to a named group before go-live, and limit administrator rights to a small set of accounts. Review group membership on a schedule and after staff changes. Confirm which API users are allowed to create transactions, since external API access is a separate exposure from back-office screens.
Verifying provider callbacks
Payment providers notify Odoo of completed, failed and refunded transactions through callbacks, and an endpoint that accepts unverified notifications can be used to mark invoices as paid. Confirm that the connector checks the provider's signature or equivalent proof on every notification and rejects those that fail. Test callbacks with replayed and altered messages in a test database, and check how the connector handles duplicate or delayed deliveries. Ask the provider and the integration team to show where this verification happens.
HTTPS for portal and checkout
Customer portal pages, payment links and eCommerce checkout must be served only over HTTPS, with the public address and any redirect targets using the secure scheme. Check that HTTP requests redirect or fail, that certificates are issued and renewed under your control, and that the proxy in front of Odoo passes the original scheme correctly so generated payment links are not downgraded. Review mixed content on checkout pages and confirm the provider's return URLs match your public domain.
Separating test and live databases
Test payment configurations and live payment configurations should never run against the same database, because a test copy with live provider keys can create real charges or send real customer messages. For on-premise installations, Odoo documents database duplication with neutralization for test copies, and neutralization is the step that should disable outgoing mail, scheduled actions and live payment settings in the copy. Verify the neutralized copy's payment providers are switched to test mode or disabled before any integration test.
Deciding whether card data enters your environment
The most consequential decision is whether card numbers ever reach your servers, logs or Odoo database. Hosted payment pages and tokenized flows keep card entry with the provider, while server-side handling of card fields expands what your environment must protect. PCI DSS scope depends on the provider integration model and on how Odoo and its surrounding systems are configured, so the scope conclusion must come from your assessor or the provider, not from this page. Ask both to confirm in writing which components are in scope before you choose the integration model.
Why payments fail to post, and how to fix them
This table lists the failures engineers most often meet when an Odoo payment provider is connected, with the likely cause and a check to run for each. Work down the rows in order when a payment is missing from Accounting, because the first two rows block every other fix. Keep the results of each check with the go-live record so the team can show how the integration was verified.
| Failure | Likely cause | Check to run |
|---|---|---|
| Provider callbacks never arrive | The database base URL or the provider's webhook address is wrong, or the firewall blocks inbound provider traffic | Confirm the web.base.url system parameter is the public HTTPS address, then send a test event from the provider dashboard and find it in the provider's delivery log |
| Test credentials used in live mode | The provider is set to test mode in Odoo, or the test API keys were saved in the live configuration | Open the provider record and confirm the environment is production and the key prefix matches the live account in the provider dashboard |
| Currency or journal mismatch | The payment journal currency differs from the invoice currency, or the provider settles in a currency Odoo does not expect | Compare the invoice currency, the provider account settlement currency and the currency set on the payment journal, then post one test invoice per currency |
| Payments created but not matched to invoices | The payment posts to the outstanding account and is never reconciled with the open receivable on the invoice | Open the invoice and the payment side by side, check the payment state and the reconciliation entries, and confirm the invoice shows as paid |
| Duplicate payment records after retries | The provider resends a webhook or the customer retries checkout, and the transaction reference is not treated as unique | Search payment transactions by provider reference for repeated entries, and review whether the provider retry settings match what the integration expects |
| Refunds not reflected in Accounting | The refund was issued only in the provider dashboard, or the refund event is not subscribed or processed | Subscribe to refund events, issue a test refund, and confirm a matching entry appears against the original invoice or credit note in Odoo |
| Provider module unavailable on the installed version | The provider connector is not published for the installed Odoo version or edition, so it is missing from the Apps list | Check the Apps list for the provider module at your exact Odoo version and edition, and confirm the module's supported version with the vendor before upgrading |
Reconciling provider payouts in Accounting
Provider payouts rarely match individual invoices. The provider settles a batch of captured payments, subtracts its fees and any refunds or chargebacks, and sends one net amount to your bank account. The reconciliation design has to decide how that net amount is split back into the gross payments, fee lines and refund entries it represents in Odoo Accounting. If this is left until after go-live, invoices show as paid while the bank line remains open, and the difference has to be cleared by hand every settlement cycle.
The first decision is where fees go. Most teams create a dedicated expense account for provider fees, and some also separate fixed fees from percentage fees so that the cost of accepting each payment method is visible. Next, decide on the payout journal. A separate bank or outstanding account for each provider lets you see what is in transit between capture and settlement. Confirm with your accountant whether gross payments are recorded as received when the provider captures them or when the payout lands, because that choice changes what appears as receivable and what appears as cash at month end. Document the answer before configuring the provider journals.
Refunds need a rule as well. Confirm how the chosen provider module creates refund entries in Odoo, whether the refund reverses the original payment in the same journal, and how a refund that falls into a later settlement period is matched. Partial refunds, disputes and chargebacks follow different paths at most providers, so list each case your business actually produces and check the resulting journal entries for it. The provider's own settlement report is the reference you will reconcile against, so confirm which report fields map to Odoo fields such as the transaction reference and the payout identifier.
The bank feed side of this work is covered in the separate bank synchronization and reconciliation page. This section only concerns how the provider's data lands in Accounting. Whether a payout line is imported automatically, uploaded as a file or entered manually changes who does the matching and how often, so note that dependency in your design but do not treat the bank connection as solved by this section.
Before go-live, run a full settlement period in a test database that holds copies of real provider settlement reports. Pick a period that includes at least one refund, one fee adjustment and one payout that spans month end if your business has them. Compare the Odoo journal entries, the payout journal balance and the provider report line by line, and record every unmatched item with its cause. Repeat the test until the closing balances agree. The effort depends on your transaction volume and the number of providers, so ask any implementation partner to base its estimate on the test period you agreed with your accountant.
Questions buyers ask before hiring help with Odoo payments
What drives the cost of an Odoo payment provider integration?
Cost depends on how many payment providers you connect, which Odoo edition and hosting model you run, and how much custom work surrounds the connector. Each provider adds its own account setup, configuration and testing, so two providers cost more than one. Edition and hosting matter because Odoo's pricing page lists only the Custom plan for Odoo.sh or on-premise hosting. Custom modules add design and maintenance effort. Reconciliation complexity, such as provider fees, partial payments, multiple journals and multiple currencies, adds analysis and test time. Testing scope is often the largest variable. Ask for a written quote that lists each provider, each payment flow, each journal and each environment to be tested. Support and upgrades are usually separate items that recur after go-live.
How long does an Odoo payment integration take to deliver?
Duration depends mainly on provider approvals, the number of payment flows, reconciliation rules and when upgrades fall in your schedule. Provider account approval runs on the provider's timeline, so start it early and confirm lead times with each provider directly. Each payment flow, such as invoice payments, customer portal payments, eCommerce checkout and refunds, needs configuration and testing. Reconciliation rules, which decide how fees, payouts and partial payments post in Accounting, often take the most design time. Upgrade timing also matters. Major versions on Odoo Online and Odoo.sh are mandatory every two years, so a setup built on one version must be checked against the next. Ask the partner for a timeline tied to a written scope rather than a generic estimate.
Can our in-house team set up Odoo payments without a partner?
Yes, if your team has Odoo administration skills, developer skills for any custom code, and an edition that supports the provider you choose. Administrators handle journals, provider configuration and user access. Developers are needed when behavior goes beyond standard settings, such as custom reconciliation or extra checkout logic. Before you decide, confirm in writing that your edition and hosting model support the provider and each feature you need, because availability varies by provider and edition. Check also that someone owns the work after go-live, including upgrades, provider changes and failed-payment investigations. Many teams begin in-house with one provider and bring in outside help when the scope grows to several providers or complex reconciliation.
What must we provide before an Odoo payment project starts?
Four inputs usually decide whether the project starts on schedule.
Provider accounts for each payment provider, including the business verification each provider requires. Share API credentials only through your approved secure channel.
Decisions on which journals receive payments, how provider fees are recorded, and which currencies and payment methods you accept.
A test environment, meaning a copy of your database with neutralization so test runs cannot send emails or touch live records, plus sandbox or test credentials from each provider.
Odoo admin access for configuration, and a named finance contact who signs off on reconciliation results. Ask the partner to list these inputs in the written scope so gaps appear before work begins.
Which Odoo edition do we need for online payment providers?
Confirm the edition before you select a provider, because the edition and hosting model decide what you can install. Odoo's pricing page lists One App Free and Standard as Odoo Online only. It states that only the Custom plan can run on Odoo.sh or on-premise, and that only Custom includes external API access and custom modules. Community is open source under the LGPL-3.0 license, but it has no access to Odoo's upgrade service. Enterprise source code is not public and requires a subscription or partner access. Which payment providers are available on each edition, and whether a given feature works on it, is not settled by this page. Confirm both with Odoo and the provider, and check the module list for your target version before you commit.
How do Odoo upgrades affect a payment integration already in production?
Upgrades are a common source of breakage for payment setups, so plan them as part of the integration. Odoo's upgrade service moves a database to a newer supported version through an upgraded test database, which should be tested before production. On Odoo Online and Odoo.sh, major versions are mandatory every two years, so the integration will be revisited on that schedule. Standard support covers the first three years after a major release, and security patches are provided only during standard support, so your chosen version sets the deadlines. Ask that the upgrade test cover every payment flow, refunds and reconciliation. Confirm any changes to the provider's own API or connector with the provider. Community users have no access to the upgrade service, so their upgrade path needs separate planning.
What should an engineer test before going live with Odoo payments?
Test every payment flow in a sandbox before any live charge. Use a copy of the production database with neutralization so test runs do not send emails or touch live records, and pair it with the provider's test credentials. Cover each flow in your scope, including invoice payments, customer portal payments, eCommerce checkout, manual capture if you use it, and refunds. Test failed, cancelled and partially paid transactions, because these create most reconciliation errors. Confirm that each payment posts to the correct journal, that provider fees and payouts reconcile in Accounting, and that user permissions limit refunds to the right staff. Repeat the full test after every Odoo upgrade or provider change, and keep the results as evidence for finance and audit teams. Confirm the test tools each provider offers, since they differ.
How DeployOpen works on this
DeployOpen plans, configures, tests and documents Odoo payment provider integrations inside the infrastructure you control, starting from a written scope. We begin by confirming which Odoo edition, hosting type and version you run, since payment features and upgrade paths depend on them. Engagements are fixed-scope, with ongoing support available as a retainer.
How we scope
- Confirm your Odoo edition, hosting type and version, and whether you run Community or Enterprise on your own servers
- List the payment flows in scope: invoice payments, customer portal payments, eCommerce checkout and any express checkout options
- Agree which payment providers are in scope and which provider accounts, sandboxes and payment methods you will supply
How we build
- Configure each provider in Odoo for tokenization, manual capture and refund behavior, matching the flows agreed in the scope
- Map payment journals and reconciliation accounts in Accounting so each provider payout reconciles to the right ledger entries
- Test payments, refunds and failed transactions in a non-production database copy before any change reaches production
How we hand over
- Deliver a configuration record covering each provider, journal, account mapping and webhook or return URL setting
- Provide a test log showing which payment, capture, refund and reconciliation cases passed and which were out of scope
- Document operating steps for finance and support teams, including how to handle disputed or partially refunded payments
How we support
- Offer ongoing support as a retainer covering provider configuration changes, troubleshooting and reconciliation questions
- Review payment module and provider changes before each Odoo major version upgrade, tested on an upgraded database copy
- Confirm with your payment providers and Odoo support windows which versions and features remain supported over time
