Tabby vs Tamara: which one should your store offer

An even handed comparison of Tabby and Tamara for Saudi stores: instalment counts, customer habit, currency coverage, fees, and why most offer both.

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.

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.

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.

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.

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.

Before you buy any integration, for either provider, check these:

• 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.
• 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.

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. 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.

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.

Frequently asked