Testing Tabby and Tamara in Odoo Before Go-Live

Published 27 September 20269 min read

What the Test Connection button really checks, what a sandbox order proves and misses, and an afternoon test plan for Tabby and Tamara in Odoo.

A green Test Connection notification feels like the finish line. It is closer to the start. It tells you that one credential was accepted by one server. It says nothing about whether a customer can actually pay, whether Odoo will confirm the order, or whether you are taking real money while you think you are testing.

This guide is about that gap. It assumes the module is installed and the keys are in, as covered in the Tabby setup guide and the Tamara setup guide. The question here is narrower: what should you see with your own eyes before real customers see the button? Everything below follows how Tabby & Tamara for Odoo is actually built.

Test or live is decided in three places

Most people picture one switch. There are three, and they do not follow each other.

The Tabby trap

For Tabby, the State field does not choose a server. The module sends every Tabby call to the address in the Tabby API URL field whatever the State says, and Tabby decides test or live from the key. So a Tabby provider in Test Mode that holds a live secret key creates real checkouts and takes real money. The reverse is just as bad: a provider set to Enabled that still holds test keys can mark orders paid that nobody paid for.

Test Mode still does one useful job. From Odoo 16 on it unpublishes the provider, and Odoo shows unpublished providers only to logged in employees, so customers do not see the button. It hides the payment. It does not make it fake. Before every test session, read the first characters of both keys.

What Test Connection actually checks

The button under the credentials on each provider form makes one authenticated call and shows you the answer.

• Tabby asks for a list of recent payments with the secret key. Green means that key is valid on the server in the Tabby API URL field. A red result about authentication means a wrong key, a key from the other environment, or a key issued in Saudi Arabia pointed at api.tabby.ai when it needs api.tabby.sa.
• Tamara asks for an order that cannot exist. A good token gets a polite "not found", which counts as a pass. A wrong token, or one from the other environment, is refused.

The list of things it does not look at is longer:

• The Tabby public key, which only the price badge on product pages uses.
• The Tabby merchant code, which is sent only when a real checkout is created. A wrong merchant code passes Test Connection and then fails at checkout.
• The Tamara notification token.
• Whether the provider is published, has a journal, or suits the currency on your pricelist.
• Whether Tabby and Tamara can reach your store to send customers and notifications back.

In Settings, under Tabby BNPL, the Test Tabby connection button runs the same Tabby check against the Point of Sale keys. There is no equivalent for the till's Tamara token, so one sandbox sale at the counter is the test.

What a sandbox order proves

A sandbox order runs the whole path that matters. The module builds a checkout from your real order, the gateway accepts or rejects it, the customer goes to the hosted page and comes back, and Odoo then asks the gateway directly what happened before it captures the payment and marks the transaction done. That return trip is where weak integrations break, and it is the part the guide to server side payment verification takes apart.

So a clean sandbox order proves four things: the gateway accepts your order data, the redirect back to your store works, the capture succeeds, and Odoo confirms the sale order and records the payment on the provider's journal.

What a sandbox order cannot prove

• That the live keys work. They are different credentials. Only Test Connection after the swap, and one real order, prove them.
• Who gets approved. Sandbox approvals come from test identities. Real approval depends on the shopper and on Tabby's or Tamara's own checks, and no Odoo setting changes that.
• Money. Sandbox payments never settle. Fees and payouts appear only with the first live settlement, which is where reconciling BNPL payouts in Odoo begins.
• Notifications, if you test on a private machine. A laptop, or a server behind a login, cannot receive the gateway's call. The order still confirms when the browser comes back, because the return alone is enough, but the case where the customer never comes back has not been tested.

A test plan for one afternoon

Stay logged in as an employee so you can see the unpublished providers, and keep the Tabby/Tamara API Log open in a second tab. It sits in the menu next to Payment Providers. Run each case once for every provider you plan to offer.

1. The happy path. A normal order with a product, shipping, and a discount code if you use them. Check that the order is confirmed, the transaction is Done, and the amount matches the gateway's portal exactly.
2. The cancel. Start an order and cancel on the hosted page. The order must stay unpaid.
3. The decline. Use the test identities in the gateway's own sandbox documentation to force a rejection. Odoo should record the decline and leave the order unpaid.
4. The closed tab. Approve, then close the tab before your store loads. If your test site is reachable from the internet, the notification should confirm the order on its own. If it is not, write down that this case was skipped.
5. Tamara without a phone. Remove the mobile number from the test customer's address. The module should stop before anything reaches Tamara and ask for one.
6. The wrong currency. Switch to a pricelist outside SAR, AED, KWD, BHD, QAR and OMR. Both buttons should disappear. If a button disappears when you do not expect it, the checklist for a provider missing at checkout walks through every filter.
7. A partial refund. Refund part of the first order from Odoo, then find the refund in the portal.
8. One sale at the till for each provider, if you use the Point of Sale.

Reading the log as you go

Every website call lands in the log with the request, the response and the HTTP status, keys masked. In a checkout request you will see either your product lines or one single line named after the order reference. Both are normal. Whenever the lines do not add up exactly to the amount due, after shipping or a discount for example, the module sends one line for the full amount instead, because both gateways reject a basket that does not match its total.

At the end of the session, filter by Errors only. An empty list is the result you want. Counter payments are not in this log; each keeps its status and its error on its own record under Point of Sale, Tabby Payments.

Sandbox orders leave real records

A sandbox payment is fake on the gateway's side only. In Odoo it is a finished transaction like any other: the sale order is confirmed, a payment is posted to the provider's journal, and a draft invoice attached to the payment is posted too. If you test on your live database, clean those up afterwards, or better, keep them off it entirely.

On a trading store there is one more thing customers can see. The instalment line under the price appears as soon as a provider leaves Disabled, Test Mode included. Untick the promo option on the provider until you go live if that matters to you.

Testing on a copy of your database

A staging copy is the right place for all of this, with two warnings.

When Odoo neutralizes a copy, its standard step disables every provider that was Enabled and leaves the keys in their fields. Set one of those back to Test Mode to try Tabby and you are in the Tabby trap again: live keys, real money. Put test keys in first.

The Point of Sale settings are not neutralized at all. They travel with the copy, so the till on staging holds the live Tabby key and the live Tamara token, with the sandbox box exactly as it was in production. Change them before anyone rings up a test sale.

Switching to live, in order

1. Replace every credential: both Tabby keys, the Tamara token, and the Point of Sale keys in Settings.
2. Set each provider to Enabled and check that it reads Published.
3. Untick Tamara Sandbox for the till.
4. Press Test Connection on each provider, and Test Tabby connection in Settings.
5. Open a private window and confirm the buttons appear for a visitor.
6. Pay one small real order with each provider, refund part of it, and match both against the portal.

If the last step is clean, you are live. If it is not, the API log already holds the answer, and the refund guide covers what to check when the refund is the part that failed.

Frequently asked