Conversions API for WooCommerce, without plugins that break

Where a duplicate purchase comes from

The Pixel in the browser and a send from the server are two paths for the same purchase. Meta counts it once only when both events carry the same id. In a shop with several tools that send a purchase (say two plugins, or a plugin and a checkout builder) it is easy to end up with three paths and nobody knows which does what. A user in one thread wrote about “6 purchases vs 2 real orders”.

What Basketly does on WooCommerce

You give the shop address and a REST API key. The app does the rest, and you see every purchase and where it went.

• Saving the key checks it by reading one order, creates the shop’s webhooks (orders and products, each with its own secret) and queues the reads. A webhook is accepted only with a valid signature.
• Orders changed since the last read come back every 15 minutes, so nothing hangs on a single notification.
• A paid, not cancelled order becomes a purchase: value, currency, products from the lines, e-mail, phone (hashed before sending), and the buyer’s IP and browser from checkout. Cancelled, refunded, failed and trashed orders are not sent.
• Every purchase is saved first and then sent with retries. When Meta has an outage, the purchase waits instead of getting lost.
• WooCommerce products (name, description, price, photo, stock, brand, GTIN from GTIN plugin fields) land on the Products screen with a diagnosis for Google Merchant Center and the Meta catalogue, and from there in a fixed feed.
• The key is stored sealed and is never shown again.

Connect WooCommerce in 4 steps

It takes a few minutes. You need no developer, but you will paste a short snippet from the guide into the shop.

1. 1

   Create a REST API key in WooCommerce

   In the WordPress admin create a WooCommerce REST API key and note the Consumer key (ck_…) and the Consumer secret (cs_…).

2. 2

   Add the shop in the app

   In Basketly open Integrations → Data sources → Add source, choose WooCommerce and enter a name and the shop address. From the source’s menu open the API connection, enter the WordPress address and the keys, tick the bought statuses and confirm the legal basis for passing the data.

3. 3

   Connect Meta and paste the guide’s snippet

   Sign in with your Meta account, choose the dataset (Pixel) and keep the purchase flow from the shop to Meta. The connection guide shows the shop script and the PHP snippet that saves the id in the order.

4. 4

   Check the first purchase

   Click “Fetch now”, send a Test event with the code from Events Manager and, after the first orders, open the purchase balance.

Bank transfer, cash on delivery and statuses

An order paid online has a payment date and is bought at once. A bank transfer usually waits in “on hold”, and cash on delivery gets its payment date when the order is completed. When connecting you tick the statuses that count as bought (by their technical names, for example on-hold). Cancelled, refunded, failed and trashed orders never become a purchase. Keep Meta’s limit in mind: a purchase older than 7 days is not accepted.

Tying the purchase to the visit

Reading an order alone does not tell where the buyer came from. The connection guide adds a snippet to the shop that saves the Basketly script’s id in the order (a cookie and a PHP snippet, for classic and block checkout). The purchase sent to Meta then carries what the script saw during the visit, but only after the buyer’s consent, because the script runs only then.

How to check that it works

• Test event: one click sends the newest shop purchase with the test code from Events Manager, and you see it under Test Events.
• Purchase balance: shop orders next to purchases Meta accepted, day by day, with the most common error reasons. A Pixel duplicate shows in Events Manager as more purchases than orders.
• Self-check: compares the dataset’s statistics in Meta with what was actually sent, and says what to fix.
• Orders: each order shows whether its purchase was accepted, failed or is waiting.