Tabby and Tamara redirect the customer off your domain to complete payment. If the shopper does not land back on your thank you page, the purchase event never fires, so Meta and Google never learn the sale happened. On UAE stores with heavy BNPL use this can hide a large share of revenue and make profitable campaigns look like losing ones.
The short version
- The problem is the redirect, not the payment method. Any off site checkout can do this.
- Mobile is where it bites hardest, because customers close the app before returning.
- Compare platform reported purchases against your store back office weekly. A persistent gap is the symptom.
- Server side tracking fixes it properly. Pixel only setups will keep losing these orders.
Why do Tabby and Tamara orders go missing from Meta and Google?
Because the purchase event usually fires on your thank you page, and BNPL checkouts take the customer off your site to approve the payment. The order completes on the provider side. Whether your tracking sees it depends entirely on whether the customer comes back.
On mobile, plenty do not. They approve payment, get a confirmation from the provider, and close the browser. The order is real, the money arrives, and your ad account never hears about it.
How do I know if this is happening to me?
Compare purchases reported in Meta and Google against orders in your store back office for the same window. A gap of ten to twenty percent has ordinary explanations such as attribution windows and blocked cookies. A gap that is much larger, and that grows with BNPL share, points at this.
Then segment your store orders by payment method. If the shortfall lines up with Tabby and Tamara volume specifically, you have confirmed it. We wrote about the wider version of this problem in why your Shopify numbers do not match Ads Manager.
What does this do to your ad account?
More damage than the missing reporting suggests. The reported return drops, which is annoying but survivable. The real cost is that Meta optimises toward the conversions it can see, so it learns from an incomplete and biased sample of your customers.
If BNPL buyers skew younger or higher basket value, and their orders are invisible, the algorithm actively learns to avoid the people who buy most. You are not just under reporting. You are training the system against your best customers.
How do you fix it?
Send the purchase server side, so the event does not depend on the customer returning to your site. Conversions API for Meta and enhanced conversions for Google both do this, and on Shopify the native integrations cover most of it once configured properly.
The detail that matters is deduplication. If both the pixel and the server send the same order you will double count, which is worse than under counting because it looks like success. Use a consistent event ID across both.
On one UAE store we run, the last 90 days returned AED 213,502 in conversion value on AED 39,372 of spend, a 5.1x. That figure is only trustworthy because the tracking underneath it captures orders that never touched a thank you page. Before the tracking work, the same account looked meaningfully worse than it was.
| Symptom | What it usually means |
|---|---|
| Store orders consistently exceed platform reported purchases by 25 percent or more | Off site checkout dropping events |
| Gap grows on days with higher BNPL share | Confirms BNPL as the cause |
| Mobile gap much larger than desktop | Customers not returning after payment approval |
| Purchases suddenly double after a tracking change | Deduplication is misconfigured, not a genuine improvement |
A mistake we made: we implemented Conversions API on a UAE store and reported a large improvement in tracked revenue to the client the same week. It was not real. The pixel and the server were both firing without a shared event ID, so every BNPL order was counted twice. We had turned an under reporting problem into an over reporting one and briefly believed our own numbers. Now we verify deduplication in the events manager before anyone sees a report.
If your store numbers and your ad platform numbers have never agreed, we can find where the events are going. Book a growth call or see how we handle conversion tracking and attribution.
Frequently asked questions
Tabby takes the customer off your domain to approve payment, and the purchase event normally fires on your thank you page. If the shopper does not return to your site, that event never fires and Meta never learns about the sale even though the order completed.
Ten to twenty percent is ordinary, caused by attribution windows, blocked cookies and cross device journeys. A gap much larger than that, especially one that tracks with buy now pay later volume, usually means events are being lost at checkout.
Largely yes, because it sends the purchase from your server rather than relying on the customer returning to a thank you page. The critical detail is deduplication, since a pixel and server both firing without a shared event ID will double count every order.
Yes, and more than the reporting gap alone. Meta optimises toward conversions it can see, so invisible orders bias its learning. If your buy now pay later customers differ from the rest, the algorithm learns to avoid exactly the people converting best.
It affects any checkout that redirects the customer off your domain, so Tamara behaves the same way. It is a structural issue with off site payment flows rather than anything specific to one provider.