Connecting Tabby and Tamara to Odoo: instalments online and at the till, and books that reconcile

Your first Tabby or Tamara sale feels like a win. The button shows up at checkout, the customer splits the bill, everyone is happy.

The trouble starts a few weeks later. A customer returns one item out of three, the cashier processes the return in Odoo, and a month on the customer calls to ask why they are still paying instalments. Or the accountant finds one transfer from Tamara covering a pile of orders, smaller than the sales report, and asks where the rest went.

This post covers what the checkout page does not show: what happens to your money, what a correct integration does online and at the till, and how to set up the books so payouts reconcile. Still choosing providers? Start with payment gateways in Saudi Arabia.

Instalment money does not behave like card money

With a card, the customer pays you. With buy now, pay later, the customer owes Tabby or Tamara in instalments, and the provider pays you. Three things follow.

• You are paid net. The provider keeps its fee. The rate is in your contract, not in any blog post.
• Payouts are batched. One transfer covers many orders and can net off refunds from the same period. Tamara's settlement documentation, for example, describes a weekly cycle and a model that holds the transfer until your balance reaches a threshold. Read the current terms in your own merchant dashboard.
• Money only moves after a particular stage. Which needs its own section.

Authorised is not captured

When the customer completes checkout, the order becomes AUTHORIZED at Tabby, authorised at Tamara. The money is reserved, not yours yet. Your system has to send a capture: the order is confirmed on your side. Tabby's payment processing guide says only captured payments are settled to you, and Tamara settles only captured orders too.

Never capture, and both providers document a 21 day limit: after it, Tabby may capture the remaining amount itself, and Tamara captures automatically (Tamara's order status flow). So an order cancelled in Odoo, where nobody told the provider, can be captured three weeks later from a customer who cancelled.

The rule:

• Before capture, money going back is a cancellation. Tabby calls it closing the payment without a capture; Tamara lets you cancel while the order is still authorised.
• After capture, it is a refund.

An Odoo integration has to know which stage each order is in, not just "paid or not".

Online checkout: never trust the return page

The customer approves on Tabby's or Tamara's page and is sent back to a "payment successful" URL on your site. The classic mistake is a module that treats arriving at that URL as proof of payment. Anyone who knows the URL can open it without paying.

The right way, as Tabby's own documentation describes it: the return URL gives you a reference, and your server asks the provider directly for the status. Webhooks get the same treatment: a nudge, with the real status read from the provider.

The reverse happens too. A customer pays and closes the page before being sent back, so Tabby has an approved payment and Odoo has nothing. Webhooks catch it, if they are switched on. Orders stuck in NEW on Tabby's dashboard with no matching order in Odoo usually mean exactly this.

At the till: do not rely on the customer's phone

A shop counter has no safety margin. The customer is holding the goods and leaves the moment the sale closes.

The flow in Tabby's POS guide and Tamara's in-store guide: the screen shows a QR code for this sale and amount, the customer scans it and approves with the provider, and the system asks the provider for the status. What matters to an owner: the validate button must stay locked until the system itself has confirmed with the provider. Not until the customer holds up a phone, because that could be a screenshot of an older approval.

The no-integration route is the cashier creating the sale in the provider's merchant app, then recording it in Odoo by hand. It works, but you now run two systems that know nothing of each other, every return is done twice, and month end is matched by hand. For the till in general, see Odoo point of sale and e-invoicing.

Returns: a credit note in Odoo refunds nobody

The mistake we see most. A credit note is an accounting document in your Odoo. Tabby and Tamara never see it, and the customer keeps paying for something they returned.

A real refund is a request to the provider, and it only counts once the provider confirms it. Tabby's documentation sets the limits: full or several partial refunds up to the captured amount, started within 180 days of the payment being created, and a processed refund cannot be cancelled.

So from the integration you want:

• Partial returns from the till. One item comes back, the cashier does an ordinary return, and only that item's value goes to the provider.
• No double refunds. A double click, or an offline till syncing the same return twice, must not refund twice. Tabby supports an idempotency key for exactly this; the integration should use it.
• Permissions. Decide who in Odoo may send money back.
• A log. When the provider rejects a refund, read its answer instead of guessing.

Accounting: one clearing account per provider

The decision that saves your accountant days: do not let instalment sales land directly in your bank account.

Setup

Create one journal per provider in Odoo's accounting configuration, of type Bank, named something like "Tabby clearing" and "Tamara clearing", each with its own account. It is not a real bank; it holds what the provider owes you and has not paid out. Keep the two apart, because their schedules, fees and reports differ.

Set those journals on the payment provider (shop and invoices) and on the point of sale payment method, so online and till sales for each provider collect in one place. Add an expense account for instalment fees.

The cycle

• Sale: the invoice is paid at its full amount, which sits in clearing.
• Refund: it leaves from the same clearing account, so when the next payout nets it off, the figures still meet.
• Payout: one entry from the settlement report. Debit the bank with what arrived, debit fees and the tax on them, and credit clearing with the total, which equals sales less refunds in that settlement. Tamara's settlement dashboard shows sales, refunds, fees, VAT and net payable as separate columns, so the entry is laid out for you.

Matching

It comes down to the reference. The integration should send an Odoo reference with each payment (the payment reference, or the POS order number), and that reference appears beside each order in the settlement report. Go line by line: find it in the clearing journal, check the amount, reconcile. Enterprise's bank reconciliation screen and reconciliation models speed this up; on Community you do it by hand. Same result, different time.

The month end check

On the last day of the month, each clearing account should hold only captured sales not yet paid out: the last few days. If the balance grows month after month, something is not clearing: a payout booked as income, a fee in the wrong account, or a refund recorded in Odoo that never reached the provider.

What about VAT?

The customer's invoice keeps its full value and normal VAT; instalments change nothing there (see ZATCA e-invoicing on Odoo). The provider's fee is a service it sells you, with its own tax invoice. Download it from the merchant dashboard and let your accountant book it.

Buy a module or build the integration?

Either way, the questions are the sections above: capture and cancellation, verification with the provider, refunds, and the reference in the settlement. How to vet any module is in buy from the Odoo Apps Store or build it?, and when custom code pays off is in custom Odoo add-ons.

One example from our own work: Tabby & Tamara for Odoo, a module we built and publish on the Odoo Apps Store. (It is ours, and it is not affiliated with Tabby or Tamara.) It adds both providers to the shop, the point of sale, invoices and quotations, reads the status from the provider, keeps the till's validate button locked until capture is confirmed, handles refunds from Odoo and logs API requests, on Odoo 14 to 19, Community and Enterprise. Its limits, plainly: a partial return on a Tamara sale made at the till is arranged with Tamara directly, and the module does not import settlement reports or book fees. That is the accounting routine above, and the module's site has a guide to reconciling Tabby and Tamara payouts.

Quick questions

Do I need my own Tabby and Tamara merchant accounts first?

Yes. An integration connects your shop to your account; it does not open one. Apply to each provider, then take test keys and later live keys from their dashboards.

Should I offer both, or is one enough?

It depends on your customers, and some shops run both. If you do, give each its own clearing account from day one. We compared them in Tabby vs Tamara.

I am on Odoo Online. Can I install a Tabby and Tamara module?

No. Under the Odoo Apps Store's conditions, third-party modules install on Odoo.sh and on your own server, not on Odoo Online.

How we do it

We start from month end, not the checkout button: clearing journals set up and linked to the providers and the till's payment methods before the first sale. Then we install Tabby & Tamara for Odoo on a copy of your database, run a sale and a return through the shop and the till with test keys, and match them against the provider's report. Once everything lines up, we switch to live keys.

See our Odoo page and Odoo with e-invoicing, or book a consultation.