Tabby and Tamara in Odoo: Install Errors and the API Log
Why the Tabby and Tamara module will not show, install or upgrade on Odoo 14 to 19, what differs by version, and how to read the API log when a payment fails.
When a payment module will not install, the first instinct is to blame the module. Most failures happen before Odoo reads a line of its code: the folder sits one level too deep, the build belongs to another Odoo release, or Odoo was busy when you clicked Install. This guide takes them in the order you meet them, then shows how to read the API log that Tabby & Tamara for Odoo keeps of every call it makes. It follows the module's own code, branch by branch, and Odoo's own source.
Two checks that rule out half the errors
Where the database lives. Odoo Online accepts no third-party modules at all, from anyone. If your store is there, no troubleshooting will help. Tabby on Odoo Community or Enterprise explains the hosting options and how a database moves.
Which branch you have. There is one branch per Odoo release, 14.0 to 19.0, and it must match your server's major version exactly. There is no 20.0 branch yet, and the 19.0 build will not do there: it sets the provider's State field, which Odoo 20 removed.
There is nothing to pip install. Beyond Odoo, the only Python library the module imports is requests, which Odoo already needs.
The module does not appear in Apps
Any one of these is enough to hide it:
- The folder is one level too deep. Odoo looks for
payment_tabby_tamara/__manifest__.pydirectly inside each directory on the addons path. If the folder you copied contains anotherpayment_tabby_tamara, Odoo will never see it. A wrong path shows in the server log asaddons path does not exist. - Odoo was not restarted. The addons path is read at start-up.
- The apps list is stale. Turn on developer mode, then click Update Apps List in the Apps menu. The entry is hidden until you do.
- The Apps filter hides it. This one catches experienced people. The Apps screen opens filtered to modules flagged as applications, and a payment provider is not one. Remove the filter, then search for Tabby.
On Odoo.sh, the folder must be committed to the branch you are looking at; a module on staging reaches production only when you merge.
Confirm the branch before you click Install
With developer mode on, open the module's card in Apps and read the version on its Information tab. Odoo puts its own release number in front of any version that does not already start with it. The right build on Odoo 18 reads something like 18.0.2.1.0; the 17.0 build copied onto Odoo 18 reads 18.0.17.0.2.1.0. Two release numbers in a row means the wrong branch.
The install stops with an error
"Odoo is currently processing a scheduled action"
Odoo refuses to install, upgrade or uninstall anything while a scheduled action is running. Nothing is wrong with the module. Wait a minute and click again.
A ParseError or "Invalid field" naming a file inside the module
Read the traceback from the bottom. If the file it names sits inside payment_tabby_tamara, the cause is almost always a build for another release, because views, fields and asset bundles change between versions. Check the version as above and swap the folder.
The browser times out
The module depends on Website, eCommerce and Point of Sale, so on a database without them those apps install in the same click. A server running with workers gives each browser request 120 seconds by default, then kills the worker. If the server log later shows Some modules have inconsistent states, the install never finished.
Install from the command line instead, where that limit does not apply. Stop the service, run this with your own config file, then start it again:
odoo-bin -c your.conf -d your_database -i payment_tabby_tamara --stop-after-init
Odoo's command line reference documents -i, -u and the time limits. Either way, install on a copy of your database first: Website and Point of Sale arriving on a live database change the menus every user sees.
Installed, but something is missing
No Tabby or Tamara at the register
On install, the module tries to create Tabby and Tamara payment methods for the Point of Sale on the company's first bank journal. A new database with no accounting has no journal yet, so the server log says deferred creating the BNPL POS methods (no journal/account yet); upgrading the module later will create them.
Set up accounting and upgrade the module once, or create the methods under Point of Sale, Configuration, Payment Methods with Tabby BNPL or Tamara BNPL ticked. The automatic step covers the current company only, so in a multi-company database create the others by hand. From Odoo 15, a ticked method without a journal is refused with "A BNPL payment method must have a Journal so captured payments post to an account". Which journal to pick is in the guide to reconciling BNPL payouts, and the counter itself in BNPL at the Point of Sale.
The providers exist but the shop does not show them
By design. Both are created Disabled, and from Odoo 16 also unpublished. Configure and publish them as in the Tabby setup guide; if one stays hidden, the checklist for a provider missing at checkout covers every filter.
What differs by version
| Odoo | Screen name | API log | Register payments post through |
|---|---|---|---|
| 14.0 | Payment Acquirers | None, server log only | Receivable account |
| 15.0 | Payment Acquirers | Yes | Journal |
| 16.0 to 19.0 | Payment Providers | Yes | Journal |
| 20.0 | No branch yet |
On Community these screens sit under Invoicing, on Enterprise under Accounting.
Upgrading
A new build on the same Odoo version. Replace the folder, restart Odoo, then upgrade the module from its card in Apps or with -u payment_tabby_tamara. The restart loads the Python code, the upgrade reloads views and data; skip one and you run half of each build. Your keys survive, because the provider records are written once at install and never overwritten. Reload any open register afterwards.
On Odoo.sh production, a push restarts the server on the new code, but Odoo.sh upgrades a module only when the version number in its manifest has gone up. If that fails, it rolls back to the previous revision.
A new Odoo version. The branch moves with the database; the rest of that project is in Tabby on Odoo Community or Enterprise. On the upgraded copy, check the keys are still there, press Test Connection and pay one sandbox order to the end.
Do not uninstall to start over
Uninstalling drops the module's own tables: the API log, and the in-store payment records holding the payment IDs that counter refunds rely on. The credential fields go too. The two register methods created at install are ordinary records, so they stay behind as plain methods, and a cashier could still pick Tabby and record a payment no gateway confirmed. An upgrade fixes what people hope an uninstall will, without the damage.
Reading the API log
From Odoo 15 the log sits in Invoicing or Accounting, under Configuration, next to Payment Providers, as Tabby/Tamara API Log. Only administrators and accounting managers can open it. Each row is one call Odoo made: date, provider, method, endpoint, HTTP status and an Error box. Red rows mean a status of 400 or above, or network-error when the gateway could not be reached. Open a row for its Request and Response tabs.
| Endpoint | What it is |
|---|---|
Tabby POST /api/v2/checkout |
Checkout created |
Tabby GET /api/v2/payments/{id} |
Status read after the return or a notification |
Tabby POST .../captures, .../refunds |
Capture, refund |
Tabby GET /api/v2/payments?limit=1 |
Test Connection |
Tamara POST /checkout |
Checkout created |
Tamara GET /orders/{id} |
Status read |
Tamara POST /orders/{id}/authorise, /payments/capture |
Authorise, capture |
Tamara POST /payments/simplified-refund/{id} |
Refund |
Tamara GET /orders/00000000-... |
Test Connection |
Patterns worth recognising
- A healthy Tabby sale is three rows with no error: checkout, payment read, capture.
- A red 404 on the row of zeros is a pass. Tamara's Test Connection asks for an order that cannot exist, so a good token gets "not found". A 401 there is the real failure.
- A 401 anywhere means a wrong key or one from the other environment. For Tabby keys issued in Saudi Arabia, also check the API URL on the provider.
network-errormeans your server could not reach the gateway: firewall, proxy or DNS. The keys were never tested.- A 400 on checkout carries the gateway's reason in the Response tab, while the customer saw only a short message. The Tamara setup guide explains those messages one by one.
- A clean checkout row and nothing after it, though the customer came back, points at Odoo rather than the gateway. Search the server log for
Tabby/Tamara: error finalising.
To follow one order, add a custom filter on Request containing its reference, copy the payment or order ID from that row's Response, then search the endpoints for that ID.
What the log does not hold
- Inbound calls. Notifications and customer returns go to the server log; the status check Odoo makes in reply is here.
- Counter payments. Each keeps its status and error under Point of Sale, Tabby Payments.
- The host. Only the path is stored, so a row cannot tell sandbox from live. For Tabby the key prefix decides, for Tamara the provider State.
- Your keys. The authorisation header is never stored and fields named like a key, token or secret are masked. Customer names, phones and addresses are stored, so keep access narrow. Bodies stop at 6,000 characters and old rows are never deleted automatically.
Odoo 14 has no log screen; its server log records each call's address and status, without bodies. Once the log is clean, the pre-launch test plan is the next step.
Frequently asked
Why does the module not show up in Apps after I copied it to the server?
Usually one of four things: the folder sits one level too deep, Odoo was not restarted, the apps list was not updated in developer mode, or the default Apps filter is on. That filter shows applications only, and a payment provider is not one, so remove it before searching.
Can I install the 19.0 build on Odoo 20?
No. Each branch is written for one Odoo release, and the 19.0 build sets the provider State field that Odoo 20 removed. There is no 20.0 branch at the time of writing, so a store taking Tabby or Tamara through the module stays on 19 or earlier for now.
Will upgrading the module erase my Tabby and Tamara keys?
No. The provider records are written once at install and an upgrade never overwrites them, so keys and settings stay. Uninstalling is different: it removes the credential fields, the API log and the in-store payment records.
Tamara's Test Connection passed, so why is there a red row in the API log?
The test asks Tamara for an order that cannot exist. A valid token gets a 404 "not found", which the module counts as a pass, while the log marks every status of 400 or above in red. A 401 on that row would be the real failure.
Where do I see errors from Point of Sale payments?
Not in the API log. Each payment at the counter has its own record under Point of Sale, Tabby Payments, with its status and last error. Problems on the website, the portal and invoices go to the API log.