Tabby and Tamara in Odoo POS: BNPL at the Counter

How to accept Tabby and Tamara instalments at the counter in Odoo Point of Sale: the QR flow, why no terminal is needed, and how Validate stays locked.

Buy now pay later grew up online, so almost everything written about it assumes a website checkout. In Gulf retail the reality in the shop is different. A customer picks up a product, reaches the counter, and asks whether they can split the payment. If the answer is no, part of that basket goes back on the shelf.

Odoo has no native BNPL support in the Point of Sale, so it has to be added. The good news is that the in store flow is simpler than most people expect, and it needs no hardware at all. This article covers how the flow works, how to configure it, what to teach the cashier, and the one safety property that decides whether you can trust it with real stock.

Why the counter is harder than checkout

On a website you have a safety margin. The order is not shipped until you see a paid state, and a fulfilment team can hold anything that looks wrong.

At a counter there is no margin. The customer is standing in front of you holding the goods, and those goods leave the building seconds after the sale closes. Nothing downstream will catch a mistake.

So the only design question that really matters for BNPL in a POS is this: what stops a cashier from closing an order that the provider never actually approved. Everything else is detail.

What the customer actually does

The flow that works in a branch uses a device you do not have to buy, because the customer already owns it.

Step by step at the till

1. The cashier rings up the basket normally in the POS screen.
2. At payment, they pick Tabby or Tamara instead of cash or card.
3. A popup opens showing a QR code generated for this specific sale, with the basket amount bound to it.
4. The customer scans the code with their phone camera. The provider page or app opens, shows the instalment plan, and the customer signs in and approves.
5. The approval happens on the provider side, not on your screen. The POS polls the gateway for the real status.
6. Once the payment is authorised, the server captures it.
7. Only after capture succeeds does the Validate button unlock for the cashier.

One detail people miss: the QR is generated per transaction because the amount is part of it. You cannot print a sticker and leave it on the counter. Any solution built on a fixed printed code is a marketing link, not a payment flow.

The same applies to solutions that email a payment link to the customer while they stand at the till. It technically works, but it makes the cashier wait while someone digs through their inbox in a queue. Scanning from the screen is faster and easier to explain.

No terminal, no extra hardware

The customer's phone is the reader. You display a code, they scan it.

In practice that means:

• No device to buy, ship, charge, insure or repair.
• No separate end of day settlement on a second machine. Everything stays inside Odoo.
• It runs on whatever already shows the POS screen: a desktop, a laptop or a tablet.
• No IoT Box is required, because nothing is physically connected.
• You can enable it in a new branch the same day, and remove it just as easily.

The only thing the customer needs is data on their phone. That is the real friction point in a shop, and the fix is simple: give the counter area guest wifi.

The safety property that matters to an owner

If you remember one line from this article, make it this one.

Picture the queue. The customer holds up their phone and says it went through. The cashier is under pressure, hits Validate, and the customer walks out with the goods. Later it turns out the payment was never completed, or that what the cashier glanced at was a screenshot of an older approval.

The answer is not training, a warning sticker, or a policy. The answer is that the system must not allow the mistake. In Tabby & Tamara for Odoo the Validate button stays locked until the server confirms capture with the provider. There is no manual override and no reliance on what the customer says or shows.

That is the same trust model applied on the web side. The return URL carries only a reference, and the real state is read back from the provider API with GET /api/v2/payments/{id}. A forged success page cannot mark an order paid. Webhooks are re verified the same way, and transactions that already reached a final state are never processed twice.

Legacy POS and the new POS

Odoo rebuilt the Point of Sale front end. Versions 14 to 16 run the legacy POS, versions 17 to 19 run the rewritten one, and the way a payment method registers itself differs substantially between them.

A single install covers both, from 14.0 through 19.0, on Community and Enterprise. If you run branches on different versions, the cashier experience is identical everywhere, which keeps training short.

One honest note so nobody is surprised at renewal time: Odoo sells each version as a separate product from 13.0 onward, so moving to a newer version means buying the build for that version. What is listed above is what is covered today.

Setting it up

Get the merchant accounts first

Before anything technical, you need your own Tabby merchant account at merchant.tabby.ai and your own Tamara merchant account. They will typically ask for a commercial registration or a freelance document, plus a bank account in the name of the business.

No module can get you approved. Integration work starts after you hold the keys.

Enter the keys and press Test Connection

Add the credentials in the payment providers settings and start in test mode. Use the Test Connection button before anything else. Most reports of a provider not appearing come down to a key that was pasted with a trailing space or copied from the wrong environment, and that button finds it in two seconds instead of in front of a customer.

Enable the method on the POS configuration

Go to Point of Sale, then Configuration, then Payment Methods. Create a method for Tabby and one for Tamara, then attach them to the POS configuration used by that shop. Close the open session and start a new one, because session settings load at opening.

You can enable one provider in one branch and both in another, depending on your agreements.

Check the currency

The providers work in a defined set of currencies: SAR, AED, KWD, BHD, QAR and OMR. If the POS currency is outside that list, the method hides itself rather than appearing and failing in front of a customer.

This is the first thing to check whenever Tabby does not show up, on the website checkout or in the POS.

Train the cashier on two moments

The whole training is two scenarios and takes about two minutes.

First, the provider declines. That is a credit decision by Tabby or Tamara, not a fault in your system. Give the cashier one sentence: the provider did not approve this one, would you like to pay another way. No improvising, no explaining someone else's risk rules.

Second, the customer has no connectivity. Offer the guest wifi, or fall back to another payment method.

When something goes wrong

Every call to the gateway is written to an API log inside Odoo with secrets redacted. When a branch tells you a sale hung, you can open the log and see what was sent and what came back, instead of raising a ticket and waiting.

The golden rule for staff: never mark an order as paid by hand to clear a queue. If capture did not happen, no money arrived, and you are handing over stock for nothing.

Refunds

Refunds are issued from the back office, in full or in part, including from the invoice. Partial matters in retail, because customers return one line out of a basket far more often than the whole thing.

Be clear about the boundary: the number of instalments and the merchant fee rates are set by Tabby and Tamara in your agreement with them, not by any module. The integration executes and records the refund, and the commercial terms follow your contract with the provider.

What this does not do

For the avoidance of doubt:

• It does not open a merchant account for you and does not influence approval.
• It is not an official Tabby or Tamara product and carries no affiliation or endorsement. It is an independent integration by Kerneltics built against the public APIs.
• It does not set fee rates or instalment plans.

The source is LGPL-3 and commented, so an Odoo partner can read and maintain it without asking anyone for permission.

A checklist before you go live in a shop

• Merchant account approved and production keys in hand.
• Test Connection returns success on the live database.
• POS currency is one of the supported currencies.
• Payment method attached to the right POS configuration, and the session reopened.
• One small end to end sale completed, then refunded.
• The cashier has seen a declined transaction at least once.
• Guest wifi works at the counter.

Work through that list and you can run BNPL in a branch with the same confidence you have in a card machine, because nothing leaves the shop until capture is confirmed. If you also want the website checkout, portal invoices and portal quotations covered by the same install rather than by a stack of separate apps, Tabby & Tamara for Odoo was built for exactly that.

Frequently asked