Tabby on Odoo Community or Enterprise: What Really Changes
Whether Tabby and Tamara run on Odoo Community, what Enterprise adds, and why Odoo Online cannot install the module while Odoo.sh and on-premise can.
The question comes up in almost every first conversation with a store on Odoo Community: does Tabby actually work here, or is instalment payment one of those things that quietly needs Enterprise? The short answer is that it works, in full, on Community. The longer answer is that the edition is the wrong question. What decides whether you can offer Tabby or Tamara at all is where your database is hosted and which Odoo version it runs, and the edition you pay for settles neither.
This page separates the two, using Tabby & Tamara for Odoo as the example because it is the module we maintain and can speak for line by line. Everything about Odoo itself comes from Odoo's own documentation and is linked.
Two questions, not one
Odoo comes in two editions. Community is the free, open source one, licensed under LGPLv3. Enterprise is the paid one that adds apps, official support, hosting and the upgrade service. Odoo's editions comparison lists app by app which is which.
Separately, an Odoo database lives in one of three places. Odoo Online, hosted and run by Odoo. Odoo.sh, Odoo's platform where you deploy from a Git repository. Or on-premise, meaning your own server, a VPS or a container you control. Odoo's hosting page explains how a database moves between them.
Edition decides which Odoo apps you get. Hosting decides whether you are allowed to add code Odoo did not write. A BNPL module is code Odoo did not write, so hosting is the question that can actually block you.
What the module needs from Odoo
The manifest of Tabby & Tamara for Odoo declares five dependencies: payment, account_payment, website_sale, point_of_sale and mail. Every one of them ships with Community. The payment provider framework, the online payment button on invoices, eCommerce, the Point of Sale and the messaging layer are all in the free edition, and Odoo's comparison page lists Invoicing, Payments, eCommerce and Point of Sale as available in both.
There is no dependency on the Enterprise accounting app, Studio, the IoT box or the mobile app. The Point of Sale flow is a QR code in a browser popup and a server that polls the gateway, so nothing sits between the register and Tabby except your own Odoo server. The only Python library imported beyond Odoo itself is requests, which Odoo already requires. The licence is LGPL-3, so your partner can read and maintain the code on either edition.
One consequence of that list: the module pulls in Point of Sale even on a website-only store, and eCommerce even on a counter-only business. On Community that costs nothing. On Enterprise the plans on Odoo's pricing page currently include all apps for one per-user price, so an extra app should not change the bill, but read that page against your own contract rather than taking it from us.
On Odoo Community
Everything the module does works on Community: the checkout option, the promo badge under the price, portal invoices and quotations, the register, refunds from the back office, the API log and the Test Connection button. There is no Community-only branch and no reduced feature set. What changes that list is your Odoo version, never the edition: Odoo 14 has no API log, no Test Connection button on the provider form and no web refund, and the install guide's version table sets out the rest. If you are setting it up for the first time, the step by step guide to adding Tabby to Odoo applies unchanged.
Three things do differ, and none of them are inside the module.
The menu is called Invoicing
Community has the Invoicing app, not Accounting. Payment providers live under Invoicing, then Configuration, then Payment Providers. Guides written for Enterprise say Accounting, and a Community user following one can stop there and assume the module did not install. Same screen, different app name. Website, then Configuration, also reaches it. The name follows the app, not the licence: an Enterprise database without the Accounting app installed shows Invoicing too.
Matching the payout is manual
Tabby and Tamara pay you in settlements, not per order. Matching a settlement to the orders inside it is where the editions genuinely diverge. Odoo's comparison places bank statement reconciliation under the Enterprise accounting app. On Community you record the payout as a payment in Invoicing and match it by hand, or add a community reconciliation module. It works, and plenty of stores run that way, but budget the bookkeeper's time for it. The clearing account and payout entry that make either edition easier are set out in the guide to reconciling Tabby and Tamara payouts.
The upgrade is your project
An Enterprise subscription includes Odoo's upgrade service for the database. Community does not. That matters for the module because it is built per Odoo version, one branch for each release from 14.0 to 19.0, and when you move the database you switch branches with it. On Community the whole migration is yours or your partner's to run. The open source route is OpenUpgrade, from the Odoo Community Association. It is not an Odoo service and its scripts cover Odoo's own modules, so taking the module's branch across and testing it on the new version stay on your list either way.
On Odoo Enterprise
The code is the same. There is one branch per Odoo version and nothing in it checks the edition, so the module installs on Enterprise exactly as it does on Community. What Enterprise adds is around it: the full Accounting app with the reconciliation screen and reconciliation models for the settlement work above, Odoo's upgrade service for your database between major versions, and official support for Odoo itself. Support for the module still comes from us on either edition, because Odoo's support covers Odoo's own code.
Two Enterprise apps do change what you see, though, and both get blamed on the module because nothing warns you about them.
The Accounting app holds back the entry and the Paid status
Odoo's own source spells out the split. Community has no reconciliation screen, so Odoo books every payment straight away and marks the invoice Paid. With the Accounting app installed, an invoice settled by a payment still waiting for its bank match reads In Payment, and from Odoo 18 an online Tabby or Tamara payment with no outstanding receipts account set books no journal entry at all until that match happens.
So one sale can show Paid with an entry on a Community test database, and In Payment with no entry on your Enterprise one. The payment has not failed. One setting resolves both: point the provider's line on the clearing journal at the clearing account, as the guide to reconciling payouts sets out step by step. What counts is whether Accounting is installed, not the licence, so an Enterprise database running Invoicing alone behaves like Community.
The Subscriptions app hides Tabby and Tamara
Odoo's comparison page lists Subscriptions under Enterprise only, and the app wants a payment method on file to charge for the next period. Tabby and Tamara cannot be saved as one, because the customer approves each purchase on the provider's own page, so a cart holding a subscription product offers neither. No setting changes that. The checklist for a provider missing at checkout covers it alongside the other filters.
On Odoo Online: this is the wall
Odoo Online is Enterprise hosted by Odoo, and Odoo's documentation for it states that it is incompatible with custom modules and with modules from the Odoo Apps Store. Not just this module: any third-party module, including the ones sold on Odoo's own store.
Part of the reason is that Odoo Online also runs in-between releases Odoo calls SaaS versions, 19.1 to 19.4 in the last cycle, released every two or three months and only on Odoo Online. Third-party modules are built against the major releases.
So if your store is on Odoo Online, the honest answer is that no Tabby or Tamara module can be installed, ours included. The options are:
- Move the database to Odoo.sh or to your own server. Odoo's pricing page says the Custom plan covers either, with Odoo.sh hosting billed on top, and the hosting page describes the move as downloading a backup and restoring it. Whether that gets you to this module depends on your version, as the next section shows.
- Stay on Odoo Online and use only what Odoo's built-in payment providers offer on their own hosted pages. Whether one of them adds instalments is a question for that gateway, not for Odoo.
Before you move: read your version
Odoo's hosting page is firm that SaaS versions do not run on Odoo.sh or on-premise. A database on one must first upgrade to the next major version, and Odoo's upgrades do not go backwards. That next major version is now 20.0, which the module has no branch for. To see where you stand, open the database manager and click the gear next to the database name.
| Your version on Odoo Online | Can it move? | This module afterwards |
|---|---|---|
| 18.0 or 19.0 | Yes, as it is | Take the matching branch |
| SaaS 19.x | Only after upgrading to 20.0 | No branch yet |
| 20.0 | Yes, as it is | No branch yet |
If you are on either of the last two rows you cannot use this module today, and changing host does not change that. The buyer's comparison covers which kinds of module already have a 20.0 build. On the first row, pay a sandbox order on the moved copy before you rely on it.
Check all this before buying any module, from anyone. A refund request is far more paperwork than a two minute check.
On Odoo.sh
Odoo.sh requires an Enterprise plan that includes Odoo.sh hosting, so there is no Community on Odoo.sh. Deployment is by Git: you add the module folder to a branch of the GitHub repository linked to the project and Odoo.sh detects module folders on its own. Odoo's project setup guide suggests submodules for publicly available modules; for a purchased one, commit the folder into your own repository.
Push to a staging branch first. A staging database is a neutralized copy of production, so put test keys in before you set the provider to test mode, and change the register's keys as well; the pre-launch test plan explains why. Then click Test Connection and run a sandbox order.
After that, merge, and expect to set things up a second time. Odoo's branch documentation is plain that merging a staging branch moves only the source code, and nothing you changed in the staging database reaches production. So on production, install the module, enter the live keys, and configure the provider and the register's payment methods the way you did on staging.
On your own server
On-premise is the only place where both editions run with third-party code. Copy payment_tabby_tamara into a directory on the addons path, restart Odoo, turn on developer mode, update the apps list and install. With the official Docker image the extra addons directory is /mnt/extra-addons. The steps are identical on Community and Enterprise; Enterprise only adds registering your subscription code. If the module does not show up in Apps or the install stops, the install and upgrade troubleshooting guide takes each failure in turn.
Three server settings a payment depends on
Test Connection only proves that your server can call the gateway. These three decide whether the answer comes back, and on your own server they are yours to get right on either edition.
- Proxy mode. Behind nginx or another reverse proxy, set
proxy_mode = Trueand have the proxy passX-Forwarded-HostandX-Forwarded-Proto, as Odoo's deployment guide shows. From Odoo 15 the module builds the address it sends the shopper back to, and Tamara's notification address, from what Odoo sees on the request. Without proxy mode that can come out as an internal host name, or as http when your shop is on https. On Odoo 14 it reads theweb.base.urlsystem parameter instead, so check that one. - dbfilter. If one server holds more than one database, set
dbfilterso each hostname leads to exactly one. A gateway's notification arrives with no session, so Odoo has nothing else to choose a database by: it answers 404 and the module never hears about the call. Odoo's guide makes it mandatory on a production server hosting several databases. - A public address. Notifications have to reach your server from the internet, and Tabby's address has to be registered first. A sandbox order can look perfect without them, because Odoo also checks the payment when the browser returns. The shopper who approves and closes the tab then stays unpaid, which is the case the test plan tells you how to try.
Upgrading with Tabby or Tamara installed
Enterprise's upgrade service upgrades your database and Odoo's own apps. It does not port a third-party module's code to the new version. Odoo's upgrade documentation counts every module that extends Odoo outside Studio as a custom module, and says a database containing one cannot be upgraded until that module has a version for the target release. On either edition, the matching branch of your BNPL module has to exist before the upgrade can go ahead.
Odoo 20.0 came out in September 2026. The module has no 20.0 branch at the time of writing, so a store that takes Tabby or Tamara through it cannot move to 20 today.
Rehearse any upgrade on a copy first. Odoo neutralizes test databases, upgraded test copies and Odoo.sh staging builds included, and part of that is taking payment providers out of live mode. On the copy, put Tabby and Tamara in test mode with sandbox keys, click Test Connection, pay a sandbox order through to the confirmation page, and refund it. A clean install proves only that the module installs; the order proves a payment still gets confirmed on the new version. The pre-launch test plan covers what else to check.
The decision in one table
| Where you are | Module installs? | Note |
|---|---|---|
| Community, on-premise | Yes | Menu is Invoicing, payout matching is manual |
| Enterprise, on-premise | Yes | Same steps plus subscription registration |
| Enterprise, Odoo.sh | Yes | Deploy through the GitHub repository |
| Odoo Online, any plan | No | No third-party modules at all; moving off depends on your version |
Two checks before you pay for anything
First, know where you are hosted. If you signed up on odoo.com, never installed anything on a server and never connected a GitHub repository, you are on Odoo Online. An Odoo.sh project and an on-premise server are both things you would remember setting up.
Second, know your exact major version, because the module is sold and built per version. Odoo's support table shows which releases are still inside standard support; 17.0's ended in September 2026. If you are upgrading or starting a new database, pick a version the module covers and take the matching branch with it.
Once those two are settled, what remains is which surfaces you take money on and which providers you want, which the buyer's comparison of Tabby and Tamara modules walks through. The counter has its own guide to BNPL at the Point of Sale.
Frequently asked
Does Tabby work on Odoo Community?
Yes, with every feature. The module depends on payment, account_payment, website_sale, point_of_sale and mail, all of which ship in the free edition. There is no separate Community branch and nothing is removed. Payment Providers sit under the Invoicing app rather than Accounting, and what does vary between stores is the Odoo version, not the edition.
Can I install a Tabby module on Odoo Online?
No. Odoo's documentation states that Odoo Online is incompatible with custom modules and with modules from the Odoo Apps Store, and that applies to every Tabby or Tamara module from any vendor. The route is moving the database to Odoo.sh or to your own server, but check the version first: a SaaS version such as 19.4 has to upgrade to 20.0 before it can move, and this module has no 20.0 branch at the time of writing.
Does the Point of Sale part need Enterprise or an IoT box?
No. The cashier picks Tabby, a popup shows a QR code, the customer scans it and approves on their phone, and the server polls the gateway for the result. All of that runs inside the Point of Sale session in the browser on both Community and Enterprise, with no IoT box and no mobile app.
How do I deploy the module on Odoo.sh?
Odoo.sh requires an Enterprise plan that includes its hosting, and deployment is through Git. Add the payment_tabby_tamara folder to a branch of the GitHub repository linked to your project and Odoo.sh detects module folders on its own. Start on a staging branch with test keys, click Test Connection and run a sandbox order. Merging then moves only the code, so install the module on production and enter the live keys and settings there.
What does Enterprise actually add for BNPL?
Nothing inside the module, which runs the same code on both. Around it you get the full Accounting app with the bank statement reconciliation screen, and Odoo's upgrade service between major versions. Two Enterprise apps also change what you see. With Accounting installed, an online payment can read In Payment, and from Odoo 18 book no entry, until it is matched or the provider has an outstanding receipts account. And a cart holding a Subscriptions product offers neither Tabby nor Tamara. Support for the module comes from us on either edition.
My store is on Odoo 17. Which version should I move to?
Standard support for 17.0 ended in September 2026, and Odoo lets you upgrade to any major version still inside standard support: 18.0, 19.0 or 20.0. The module has branches for 14.0 through 19.0 and none for 20.0 at the time of writing, and Odoo will not upgrade a database until every custom module in it has a version for the target. Pick a version the module covers, take the matching branch with you, and rehearse the upgrade on a test copy with a sandbox order first.