Tabby vs Tamara: which one should your store offer

Published 13 September 2026Updated 1 November 202616 min read

Tabby or Tamara for a Saudi store: instalments, customer habit, currencies and fees, and how the two differ inside Odoo when you run both side by side.

The short answer, before the detail

For most Saudi stores this is not really a choice between two competing products. Tabby and Tamara are the two names shoppers look for at checkout, and a shopper who has an account with one does not always have an account with the other. A store that shows both serves both groups. A store that shows one is asking part of its traffic to change a habit at the worst possible moment, which is the second before payment.

The reason the question keeps coming up is not that one provider is clearly better. It is that adding a second provider used to mean a second app, a second invoice, a second settings screen and a second thing to debug at 11pm. That part is a software problem with a software answer. The comparison below is still worth reading, because you should understand what you are switching on before you switch it on.

How each one splits the basket

Tabby: four payments

Tabby's best known plan in Saudi Arabia splits the order into four interest free payments for the customer. The customer approves the plan during checkout, pays the first part, and the provider collects the rest on the schedule it sets. You, the merchant, are paid by Tabby according to your settlement agreement, not by the customer over time.

Tabby offers other plans in some markets and for some merchant categories. Which plans your account can show is set in your merchant agreement and visible in your Tabby dashboard, so confirm it there rather than from an article.

Tamara: three payments

Tamara's best known plan splits the order into three interest free payments, with the same basic shape: the customer approves, you get settled by the provider, the provider owns the collection.

Tamara has also offered plans that are not a simple split, such as paying the full amount at a later date. Again, what appears on your checkout depends on what is enabled for your account. In Odoo the instalment count sent to Tamara is a field on the provider, so it has to match that plan; the Tamara setup guide for Odoo covers it along with the token and the sandbox.

What the instalment count actually changes

Take a basket of 295 SAR. Under a four payment plan the badge under the price reads about 73.75 SAR per payment. Under a three payment plan it reads about 98.33 SAR. Same total, same zero interest to the customer, different number on the product page.

That difference is mostly psychological, and it cuts both ways. A smaller per payment figure reads lighter next to a price. A shorter plan finishes sooner, which some customers prefer on larger items. In practice the badge matters far more than the number inside it. A product page with no instalment message at all is the version that loses the sale.

This is also why Tabby asks merchants to show the promo message near the price during go live checks. If you are building the integration yourself, plan for a live badge that recalculates when the customer changes quantity or picks a different variant, not a static banner image that lies the moment someone buys two. How the module's badge does that, and what Tabby's checklist actually asks for, is in the Tabby 4 payments message under the price in Odoo.

Which name your customers already recognise

Nobody should decide this from a blog post, including this one. Three ways to find out for your own store:

• Read your own inbox. Search your WhatsApp and Instagram messages for both names. Customers ask for the one they use.
• Look at the checkouts of three or four stores in your exact category, not at big general retailers. Category habits are real.
• Ask each provider's sales contact for guidance on your category, in writing, during onboarding.

One more thing worth asking about: both providers run consumer apps with merchant directories, and being listed there is a traffic channel of its own. Ask what listing requires and whether your store qualifies, because that can be worth more than the checkout button itself.

Coverage and currency, in practical terms

Both providers are GCC focused and both keep expanding, so treat any country list you read as something to confirm with the provider before you promise it to a customer.

What matters inside Odoo is what happens when the currency is not supported. If your website is priced in a currency a provider does not handle, the correct behaviour is that the method never appears, rather than appearing and failing at the last step. Tabby & Tamara for Odoo supports SAR, AED, KWD, BHD, QAR and OMR, and hides a provider automatically when the order currency is outside its list. If you build your own integration, build that rule in early. It is the single most common reason a merchant reports that the payment method is not showing at checkout, and the fix guide for that exact complaint walks the currency, pricelist and published filters in the order Odoo applies them.

Those six are wider than either provider's published list, on purpose, because a module that serves both cannot know which markets your contract covers. At the time of writing Tabby's merchant help centre names SAR, AED and KWD, while Tamara's checkout API reference accepts SAR, AED, BHD, KWD and OMR, and neither lists QAR. So a store pricing in Bahraini dinars or Omani rials can offer Tamara there but not Tabby, which may settle the choice on its own. The guide to which currencies Tabby and Tamara take in Odoo puts both lists next to the module's and explains which currency a checkout is actually sent in.

Cost to you, without invented numbers

Merchant fees for both providers are negotiated per merchant and per category. Any percentage you read in a forum is somebody else's rate, not yours, so ask both companies for a written rate card and compare:

• the merchant fee per transaction
• the settlement schedule, meaning when the money actually lands in your bank account
• how refunds and partial refunds are handled and whether the fee is returned
• minimum and maximum order value, which decides whether the badge can even appear on your cheapest and most expensive products
• what happens on a return or a dispute

Then compare that total against the extra revenue, which you can only measure after launch. Run both live for a full month before you judge either one.

Approval is between you and the provider

You apply for a Tabby merchant account at merchant.tabby.ai and for Tamara through its own merchant onboarding. Both will normally want a commercial registration, or a freelance document where they accept one, plus a bank account in the business name. Approval and the terms attached to it are entirely theirs to give.

No Odoo app can approve you or speed that up, and any listing that hints otherwise is overselling. An integration carries your API keys, speaks the provider's API, and records the result against the right document in Odoo. That is the whole job. Once both approvals are in, the Odoo side is two step by step guides: adding Tabby to Odoo and the Tamara Odoo integration.

For the same reason, be clear about affiliation. Tabby & Tamara for Odoo is an independent integration built by Kerneltics against the public APIs of both providers. It is not official and not endorsed by either company.

The real cost of running both, and how to keep it small

Two providers means two sets of keys, two dashboards, two settlement reports and two refund paths. That overhead is manageable, and most of it is unavoidable because it lives on the provider side. The part you control is what happens in Odoo. Two settlement reports, for example, stay easy to check when each provider posts to its own clearing journal, as set up in reconciling Tabby and Tamara payouts in Odoo.

Before you buy any integration, for either provider, check these. If you want the list applied to the modules actually on the Apps Store today, with prices, that is the buyer's comparison of Tabby and Tamara modules for Odoo.

• Does it cover every surface where you take money? Website checkout is the obvious one. Portal invoices and portal quotations matter for service businesses and anyone who sends a payment link. The Point of Sale matters the moment you have a counter.
• In the Point of Sale, is it a QR code the customer scans and approves on their own phone, or an emailed payment link? Those are very different experiences with a queue behind the customer.
• Does the Validate button stay locked until the provider has actually captured the payment? If a cashier can close a sale on an unconfirmed authorisation, you will eventually give away stock.
• How is the payment status verified? A return URL is a browser redirect and a browser redirect can be forged. The state must be read back from the provider's API, for example GET /api/v2/payments/{id}, and webhooks must be re-verified the same way. Transactions already in a final state must never be reprocessed. Why a fake success URL cannot mark an order paid shows the attack and a twenty minute audit you can run on any module.
• Can you issue full and partial refunds from the back office, including from the invoice, or does accounting have to log into a provider dashboard?
• Is there a Test Connection button and a log of API calls with secrets redacted? Without those, diagnosing a failed transaction means opening a ticket and waiting.
• Community or Enterprise, and which Odoo versions? Many GCC retailers run Community, and several payment modules quietly require Enterprise.
• Arabic strings, and the licence. LGPL-3 with readable source is very different from a single domain proprietary licence if a partner has to maintain it.

Running both in one Odoo: where the two differ

In Tabby & Tamara for Odoo the two providers are separate payment provider records. Both arrive Disabled when you install the module, and each one is switched on by itself. They share the currency rule, the API log, the refund flow and the address shoppers come back to. A few things are not shared, and those are the ones that catch a merchant who sets up one provider and assumes the other behaves the same way.

Each one goes live on its own day

Approvals rarely land in the same week, so expect a stretch with one provider live and the other still in testing. Each record has its own State, so that is fine, as long as the one that is waiting stays out of customers' sight. On Odoo 16 and later, Test Mode unpublishes a provider, and Odoo shows unpublished providers only to people logged in as staff. On Odoo 14 and 15 there is no such filter and a provider in Test Mode appears to every visitor, so keep the waiting one Disabled there. Step 5 of the Tabby setup guide walks through both cases.

Go-live day is not the same move for the two. For Tabby you swap the test key for the live one, because the key decides where the order goes. For Tamara you switch the State to Enabled and paste the live token in the same sitting, because the State is what moves it to the live server, and a sandbox token there fails with "Tamara authentication failed". The Tamara setup guide has that message and the others word for word.

Match each instalments field to the plan you were given

Both providers have an instalments field, set to 4 for Tabby and 3 for Tamara out of the box, and they do different jobs. Tabby's only sets the number on the badge under the price; the plan a shopper is offered on Tabby's page comes from your Tabby account. Tamara's is also sent to Tamara with each checkout as the number of instalments to offer. Set both to the plans in your two agreements. A badge that promises four payments when the provider's page offers something else is exactly the kind of mismatch a shopper takes a screenshot of.

When one says no, can the shopper switch to the other?

This is the strongest argument for offering both, so it is worth knowing how it plays out in Odoo. It depends on where the no arrives.

Before the shopper leaves your site. Tabby checks the order when the module asks it to open a checkout. If it refuses, the shopper stays on your payment step and reads "Tabby could not approve this order. Please choose a different payment method." The cart is untouched and Tamara is one click away. Tamara's early stops appear in the same place: the message asking for a mobile number, or "Tamara error:" followed by Tamara's own reason when it will not open a checkout.

After the provider's page. If the shopper is declined on Tabby's or Tamara's own page, or the checkout there is cancelled or runs out of time, the module records "Tabby declined this payment." or "Tamara declined this payment." (or a cancelled or expired note) and Odoo takes over. What the shopper sees next is Odoo's own code, and it has changed from version to version:

On the confirmation page the reason sits in a red box. "Cart cleared" means Odoo has taken the order out of the shopper's browser session. A customer logged in to an account usually gets it back on the next page they open, because Odoo reloads a customer's last unconfirmed website order. A guest starts again from an empty cart, and rebuilding a basket straight after a refusal is a lot to ask. On Odoo 14, cancel one sandbox checkout and see where you land.

In every case the order stays in Sales as an unpaid quotation with the failed transaction attached, so nothing is lost on your side. When one of those belongs to a real customer, a payment link sent from the quotation lets them finish with the other provider. The guide to instalments on quotations, invoices and payment links shows how, and what to check on the contact before you send it.

Testing before a real customer sees it

Get sandbox credentials from both providers. Run Test Connection. Place a test order on the website and confirm the transaction state in Odoo comes from the provider, not from the redirect. Open a portal invoice and pay it the same way. Run one Point of Sale sale end to end and watch whether the Validate button unlocks only after capture. Then refund part of an order and check the provider dashboard agrees with Odoo. With both providers on, also cancel one checkout on each provider's page and note where your Odoo version leaves the shopper, so you know what a refused customer will see. Only after all of that should you announce it.

A decision path you can follow today

If you are launching this week and have capacity for one integration, start with the provider your own customers mention most, and put the second on the calendar for the same quarter.

If you sell mid to high ticket items, electronics, furniture, clinic packages, offer both from the start. Each provider runs its own approval decision on each customer, so a shopper declined by one is sometimes approved by the other. With only one provider on the page, that shopper simply leaves.

If you also have a counter, decide early, because a Point of Sale flow is where cheap integrations fall apart and where switching later is most disruptive. What the counter flow should look like, step by step, is in Tabby and Tamara in the Odoo Point of Sale.

The honest conclusion

There is no winner here. Tabby and Tamara are close enough in what they do for the customer that picking one on features is the wrong exercise. The decision that actually moves revenue is whether both names appear at checkout, on the product page, on the invoice you emailed, and at the till.

The only reason most stores did not offer both was that it cost two purchases and two integrations. When both providers live in one module, one settings screen, one API log and one refund path, offering both stops being a decision and becomes the default.

Before choosing, ask whether instalments suit your store at all in the article on what BNPL changes at checkout.

Frequently asked