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
- The cashier rings up the basket normally in the POS screen.
- At payment, they pick Tabby or Tamara instead of cash or card.
- A popup opens showing a QR code generated for this specific sale, with the basket amount bound to it.
- 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.
- The approval happens on the provider side, not on your screen. The POS polls the gateway for the real status.
- Once the payment is authorised, the server captures it.
- 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. The web side of that model, including what a forged return URL looks like and how to test any module against it, is in why a fake success URL cannot mark an order paid.
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, and the website side of that work, from merchant account to first live order, is in the full guide to adding Tabby to Odoo.
Enter the counter's keys in Settings
The register does not use the keys you entered on the website's payment providers. It reads its own, from Settings, in the Tabby BNPL section: the Tabby secret key, public key and merchant code, the Tamara API token, and a Tamara Sandbox switch. Start with Tabby's test keys and Tamara Sandbox ticked, then press Test Tabby connection before anything else. A key copied from the wrong environment, or for the wrong Tabby region, fails there in two seconds instead of in front of a customer. There is no such button for Tamara on this screen, so one small sandbox sale at the counter is your Tamara test. Where the Tamara token comes from, how to check it with Test Connection on the website's Tamara provider, and why the sandbox switch has to change together with the provider at go-live are all in the Tamara setup guide for Odoo.
The same section sets how long the register waits for the customer's approval: 300 seconds by default, and Tabby asks for at least 180. If a branch has its own Tabby merchant code, set it on that branch's POS configuration.
Enable the method on the POS configuration
Go to Point of Sale, then Configuration, then Payment Methods. The module tries to create a Tabby and a Tamara method when it is installed; if yours are missing, create them and tick Enable Tabby (Buy Now, Pay Later) or Enable Tamara (Buy Now, Pay Later) on each. Two things usually explain missing methods: the database had no bank journal when the module was installed, or you are working in a company other than the one it was installed from, which the automatic step skips. Why the POS methods can be missing after install shows the log line that confirms it. 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 module works with a defined set of currencies, SAR, AED, KWD, BHD, QAR and OMR, and your Tabby or Tamara account may cover fewer. On the website the module hides a provider when the order is in any other currency. The register has no such filter: the Tabby and Tamara methods show whatever the POS currency is, and the payment is sent in that currency, so a POS priced outside the list shows the method and fails when the cashier uses it. Check the POS currency before the first sale.
On the website, currency is also the first thing to check when Tabby does not show up at all. Pricelists and the published flag add more ways to hide a provider there, and the fix guide for a provider not showing at checkout walks them in order. Which currencies your account can actually take, and how to sell in more than one, is in the guide to GCC currencies for Tabby and Tamara.
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 counter payment has its own record under Point of Sale, Orders, Tabby Payments, which lists the Tamara ones too: its status, the amount, and the provider's error message when a call failed. When a branch tells you a sale hung, open that record and read what the provider answered, instead of raising a ticket and waiting. Calls from the website side are kept separately, in the API log, with secrets redacted.
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
A counter sale is refunded like any POS sale: the cashier opens the original receipt, presses Refund and picks the lines coming back. For a Tabby payment the module sends that amount to Tabby when the refund order syncs. Partial matters in retail, because customers return one line out of a basket far more often than the whole thing, and here the lines set the amount. From the back office, the Refund on Tabby button on the invoice or on the payment record refunds whatever remains, for users given the Tabby Refund right. For now that button is also the route for a Tamara counter sale, so a partial Tamara return is arranged with Tamara directly. All three paths, and what happens when a cashier's refund syncs to the provider, are in the guide to Tabby and Tamara refunds in Odoo.
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 Tabby connection, under Settings, Tabby BNPL, returns success with the live keys, and Tamara Sandbox is off.
- 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
Do I need a card terminal or any extra hardware to accept Tabby or Tamara in the Odoo POS?
No. The customer's own phone is the reader. The POS shows a QR code generated for that specific sale, the customer scans it, and approves on the provider side. Nothing is physically connected, so no IoT Box or payment terminal is required, and it runs on a desktop, laptop or tablet.
Can a cashier validate the order before the customer has actually been approved?
No. The Validate button stays locked until the server confirms with the provider that the payment was authorised and captured. There is no manual override, so the cashier cannot close the sale based on what the customer shows on their phone.
Which Odoo versions and editions does this work on?
Odoo 14.0 through 19.0, on both Community and Enterprise. It supports the legacy Point of Sale used in versions 14 to 16 and the rewritten Point of Sale used in versions 17 to 19, so the cashier experience is the same across branches on different versions.
Do I still need my own Tabby and Tamara merchant accounts?
Yes. You apply directly to Tabby at merchant.tabby.ai and to Tamara, and they usually ask for a commercial registration or freelance document and a bank account in the business name. The integration connects your keys once you have them. It is an independent product by Kerneltics with no affiliation with or endorsement from either provider.
Why is Tabby not showing as a payment method in my POS or checkout?
At the counter, the method shows once it is attached to that shop's POS configuration and the session has been reopened, because settings load when a session opens. If it shows but fails, check the keys under Settings, Tabby BNPL, with the Test Tabby connection button, and make sure the POS currency is one the providers support. On the website the usual causes are an unsupported currency, which hides the provider automatically, and a provider that is enabled but not published.
How do refunds work for an in store BNPL sale?
The cashier refunds it like any POS sale: open the receipt, press Refund and pick the lines coming back. For a Tabby payment the amount reaches Tabby automatically when the refund order syncs, so a partial return is just fewer lines. The Refund on Tabby button on the invoice or the payment record refunds whatever remains, and for now it is the route for a Tamara counter sale. The instalment count and the merchant fee rates are set by Tabby and Tamara in your agreement with them, not by the module.