Tabby and Tamara Odoo Modules: Which One to Buy

A buyer's comparison of the Tabby and Tamara modules on the Odoo Apps Store: what each one covers, what it really costs, and a checklist for any of them.

The short version

Search the Odoo Apps Store for Tabby and you get a page of modules that look interchangeable. They are not. The things that decide whether you are still happy in six months do not show up in the screenshots. They show up in four questions: how many providers the module covers, how many places inside Odoo it can actually take a payment, which Odoo edition and versions it supports, and what licence you get with the source.

Be upfront about who is writing this: we publish Tabby & Tamara for Odoo, $200 on the Apps Store. We think the comparison below goes our way, and we will say plainly where another module is the better buy for you. Every competitor fact here is the vendor's own published claim on their own listing, and every price is the listing price at the time of writing, per Odoo version.

What you are actually buying

The four places a customer can pay

An Odoo business can present a payment button in four different places, and they are not the same piece of software:

1. Website checkout. The eCommerce cart, the classic case.
2. Portal invoices. The invoice you emailed, with a Pay button on it.
3. Portal sales orders. A quotation the customer approves and pays online, before an invoice exists.
4. Point of Sale. A customer standing at your counter.

Most Apps Store listings cover exactly one of those, usually the first. That is fine if you are a pure eCommerce store. It is not fine if you invoice B2B customers, quote projects, run a clinic, or have a branch with a till. Plenty of Gulf businesses take more revenue through emailed invoices and quotations than through the web cart, and those two surfaces are exactly the ones nobody advertises.

The cost you should be comparing

The sticker price on a listing is not the cost of the decision. If you want both Tabby and Tamara and the market answer is one provider per module at around $270, then the real number is around $540, spread over two vendors, two support queues, two configuration screens and two upgrade cycles. Odoo licences modules per version, so that pair of purchases comes back around at your next major upgrade, and it comes back at whatever the two vendors are charging then.

That is the comparison that matters: not $200 against $270, but $200 against the total of everything you have to buy to cover your business.

What is on the Apps Store today

One provider per module, around $270 each

This is the most common shape by a wide margin: a Tabby module from one vendor, a Tamara module from another, roughly $270 apiece. There is nothing wrong with these. They are focused, most of them do the website checkout properly, and if you have decided you will only ever offer one provider on a website, one of them will serve you.

The catch is structural rather than technical. Two vendors means two answers when something breaks at checkout, and neither of them owns the whole picture. It also means that the day you decide to add the second provider, you start the buying, installing and testing cycle again from zero.

Both providers, website only: $269.91

oe_tabby_tamara_payment_connector, listed at $269.91, puts Tabby and Tamara in a single module. This is genuinely closer to what most Saudi merchants ask for than the one provider modules are, and credit where it is due. For a pure eCommerce store with no counter, no portal invoicing and no quotations, it is a reasonable purchase.

Its own listing describes website checkout. There is no Point of Sale. If you open a branch, run a pop-up at a mall, or start taking payment at a service desk, you are back on the Apps Store looking for a second module.

Both providers, Point of Sale only, Enterprise required: $278.93

ol_pos_tabby_tamara_merged, listed at $278.93, covers both providers at the Point of Sale. If the counter is where your problem is, this is a real POS integration and it addresses it.

Two limits, both from the vendor's own description. It is Point of Sale only, so your website, your portal invoices and your quotations are not covered. And it requires Odoo Enterprise. If you run Odoo Community, that is the end of the conversation, and moving to Enterprise to buy a $278 module is not a payments decision, it is a licensing decision with a recurring bill attached.

The premium Point of Sale module: $557.86

There is a Tabby Point of Sale module listed at $557.86 under the OPL-1 proprietary licence. It is the most expensive option in this comparison, it covers one provider, and it covers one surface.

The licence deserves a sentence of its own. OPL-1 is proprietary, so your implementation partner is not free to read and adapt the code the way they can with an LGPL module. When you need a change to fit your flow, your only route is a ticket and a wait. On a payment path, that matters more than it does on a reporting widget.

The budget option: $149.33

There is a cheaper module at $149.33. It is single domain licensed and its terms forbid sharing the source.

Read that carefully against how you actually work. Single domain licensing tends to mean the staging database on a different hostname is not covered, a second brand is not covered, and a partner who maintains your system may not be allowed their own copy. If you have one production database and nothing else forever, the saving is real. If you have a staging environment, and you should, price the second licence into the comparison.

What almost no listing mentions

Three gaps run across the category, and they are worth knowing about before you buy anything, including ours:

• Portal invoices and portal quotations are absent from essentially every description. Nobody is claiming them, which is a good hint that nobody is doing them.
• No listing we checked documents how it verifies a payment, beyond saying that it registers webhooks. "We register a webhook" is not a security statement. The question is what the code believes when a browser comes back from the gateway claiming success.
• No Tabby or Tamara listing we checked claims Arabic interface strings. In a market where Tabby and Tamara exist because of Arabic speaking shoppers, that is a strange thing to leave out.

The comparison table

Read that table honestly. If your business is one website and nothing else, the $269.91 module covers you and this is a close call on price. If your business is a counter and nothing else and you already pay for Enterprise, the $278.93 module covers you. The moment your business is more than one of those surfaces, the arithmetic stops being close.

Where Tabby & Tamara for Odoo sits

One install, $200, both providers, and all four surfaces: website checkout, portal invoices, portal sales orders and the Point of Sale. Odoo 14.0 through 19.0, Community and Enterprise. LGPL-3, so the source is readable and your partner can maintain it. Arabic plus eleven more locales.

The parts we would want a buyer to poke at:

The Point of Sale flow needs no hardware. The cashier picks Tabby or Tamara, a QR popup appears, the customer scans it and approves on their own phone. The server polls the gateway and captures automatically on authorisation, and the Validate button stays locked until capture actually succeeds. That last detail is the one that keeps your till honest at the end of the day. It works on the legacy POS in 14 to 16 and the rebuilt POS in 17 to 19. The flow, the setup and the two things to train a cashier on are in BNPL at the counter in Odoo Point of Sale.

Payment status comes from the provider, not from the browser. The return URL carries only a reference. The real state is read back from the provider's API with a server side call, so a forged redirect claiming success cannot mark an order paid. Webhooks are re-verified the same way, and a transaction that is already done, cancelled or in error is never re-processed, so a replayed notification cannot flip it. Why a fake success URL cannot mark an Odoo order paid shows the attack, the naive code that falls for it, and an audit you can run on any module.

Refunds are where integrations usually stop. Full and partial refunds run from the back office and directly from the invoice, gated behind a dedicated access group so not everyone with an accounting login can push money back. A Point of Sale refund is sent to the provider automatically when the refund order syncs.

You can see what happened. Every gateway call is written to an API log with secrets redacted, and there is a Test Connection button for your keys. When something does go wrong, you are reading a log instead of guessing.

The checklist to use on any module

This is the part to keep even if you buy from someone else. Send these questions to any vendor before you pay.

Scope

1. Does it cover both Tabby and Tamara, or will I be buying a second app later?
2. Which of the four surfaces does it cover: website, portal invoices, portal quotations, Point of Sale? Ask surface by surface, not "does it work with Odoo".
3. Does it need Odoo Enterprise?
4. Which Odoo versions are covered, and what is the upgrade policy at the next major release?

Correctness

5. How is a payment confirmed? If the answer is anything other than a server side read from the provider's API, keep asking.
6. What happens if the same webhook arrives twice, or arrives for an already cancelled order?
7. Can I refund partially? From the invoice, or only from a separate screen? Is it permission controlled?
8. What happens to a Point of Sale refund at the provider?

Storefront

9. Is there a live instalment badge under the product price, and does it recalculate on quantity and variant changes, or is it a static image?
10. Is there a breakdown the customer can open, showing the schedule and what they pay today?
11. What happens in a currency the provider does not support? Hiding the method is correct. Showing it and failing at the last step is not. If a provider is missing at checkout today, the fix guide for a provider not showing explains which filter hid it.
12. Are the customer facing strings available in Arabic?

Ownership

13. What licence? LGPL-3 means readable, maintainable source. Proprietary or single domain licensing changes what your partner is allowed to do and may cost you a second purchase for staging.
14. Is there an API log you can read when a payment goes wrong, and a way to test credentials before go live?

What no module can do for you

Three things worth saying plainly, because a listing that hides them is not being straight with you.

You need your own merchant account with Tabby and Tamara. The module connects your keys once you are approved. It does not get you approved, and nobody selling an Odoo module can shorten that process.

We are not affiliated with or endorsed by Tabby or Tamara. Neither is any other vendor on that store page.

The fee rate and the number of instalments are set by Tabby and Tamara in your merchant agreement, not by any module. Any percentage you read in a forum belongs to someone else's contract.

How to decide this afternoon

Write down the surfaces you actually take money on today, and the ones you will take money on within a year. Write down whether you are on Community or Enterprise. Write down whether you want one provider or both. If that last one is still open, Tabby versus Tamara for a Saudi store is the page for it.

If that list is one website, one provider, forever, buy the cheapest module that passes the checklist above and get on with your day.

For everyone else, the arithmetic is straightforward. Tabby & Tamara for Odoo is $200 for both providers across website checkout, portal invoices, portal quotations and the Point of Sale, on Community and Enterprise, with source you can read. The alternative is two purchases at around $270 each that still leave the portal and the counter uncovered.

Frequently asked