Matching products across shops

Your shops rarely use the same article number. The main shop sells SKU ABC; the shop that charges for the order calls the very same article SKU DEF. GatewayChanger matches the two, so you can route by product instead of by one shop's spelling — and so the charging shop's own bookkeeping shows the right items.

What it gives you

• Rules that talk about articles. "Everything containing Widget Pro is charged by Shop B" keeps working when Shop A renames its SKU, and it matches carts from any of your seller shops.
• Chargers that actually carry the goods. A candidate can be required to have the cart's products in its own catalog; one that does not is skipped, and the decision trace says so.
• Mirror orders with real line items. The charging shop books its own products (WooCommerce) instead of a single "payment on behalf of …" line, with one adjustment line for shipping, taxes and anything unmatched.

Where the products come from

Each connected shop's plugin pushes its catalog: a full sync once a day, and the products you edit a few minutes after you save them. Nothing sensitive leaves the shop — SKU, name, price, GTIN, categories, stock status.

WooCommerce sends products and variations, and reads the GTIN from WooCommerce's own "GTIN, UPC, EAN or ISBN" field (or from _gwc_gtin meta on older shops). Magento sends its catalog from the nightly cron. The four plugins still in build — PrestaShop, OpenCart, nopCommerce and Zen Cart — do not push a catalog yet; orders from those shops match through identical SKUs and GTINs.

You can switch the sync off per shop in the shop's configuration, and push on demand with wp gwc catalog or bin/magento gatewaychanger:catalog.

How matching works

Open Products in the dashboard. You will see one card per shop (how many products it has, how many are matched) and two tabs: the matched products, and everything still unmatched.

Press Auto-match and GatewayChanger links what is unambiguous:

Everything below that is a suggestion: open an unmatched product, and the drawer shows the likely counterparts in your other shops with the reason for each score. You confirm — nothing is linked behind your back, and a link you made by hand is never changed by a later automatic run. Use Preview auto-match first if you want to see what it would do without writing anything.

A product with no counterpart yet can still be promoted to a product of its own; later shops join it automatically as soon as their catalog arrives.

Using products in rules

In the rule builder:

• Products — the rule matches when the cart contains one of these articles, under any shop's SKU.
• Excluded products — the rule is skipped when the cart contains one of them.
• Must carry the cart (per candidate, under Caps and capture mode) — At least one item or Every item. A charger whose catalog has no match is skipped with the reason products_unmatched, and the trace shows exactly which lines were missing.

The rule simulator shows the same answer the real checkout gets, including the translated line items.

Requiring a product match needs both shops to have synced their catalogs. The Products page tells you at a glance which shop has not sent one yet.

What the checkout does with it

When a seller shop asks who should charge an order, the answer now carries the cart translated into the charging shop's own products:

"items": [
  { "sku": "ABC", "qty": 2, "amount": 3998, "product": "prd_01J8…", "matched": true,
    "charger": { "sku": "DEF", "name": "Widget Pro", "price": 2049 } },
  { "sku": "GIFT-WRAP", "qty": 1, "amount": 300, "matched": false, "reason": "not_in_catalog" }
]

The seller passes those SKUs to the charger, which looks them up in its own catalog and ignores anything it does not recognise. The amount always comes from the signed grant, never from the line items, so the payment is unaffected by an unmatched or renamed article.

Every decision keeps its mapping, so you can see on /app/decisions/… what was matched for an order and what was not.

Automating it

The same thing is available to scripts with an organization key: GET /api/v1/shop-products?q= searches every shop's catalog, GET /api/v1/products lists the matched articles with their per-shop SKUs, POST /api/v1/shop-products/{id}/match links two of them, POST /api/v1/products/auto-match runs the automatic pass, and POST /api/v1/catalog/map answers "if Shop B charged this cart, what would it book?". See the API reference.