Choose the Matching Route for Your Checkout
A connected payment provider supplies payment records. Matching those records to a website visit also needs the visitor reference or another supported identity route. Choose the instructions for the checkout you actually use.
Instructions reviewed
Match the checkout to its reference
Use this table to choose the next check. Automatic browser behavior applies only to a supported standard-tracker installation after the site's consent requirements are met. Aggregate tracking cannot supply the same persistent visitor-level payment matching.
| Checkout | Matching route to check | Important boundary |
|---|---|---|
| Stripe Payment Links | The standard tracker writes client_reference_id on supported links. | An existing business reference in that field needs a server-created Checkout Session and metadata instead. |
| Server-created Stripe Checkout | Pass the browser visitor ID in client_reference_id or metadata.attriboo_visitor_id. | Private keys, prices and customer authorization stay on the server. Standalone PaymentIntents are unsupported. |
| Polar hosted links or custom checkout | Supported polar.sh links carry reference_id. Server-created checkouts can carry metadata.attriboo_visitor_id. | Check the resulting order or checkout metadata and the selected Polar organization. |
| Lemon Squeezy hosted checkout | Supported links carry checkout[custom][visitor_id]. Check the custom data received with the order. | A custom checkout creation flow must preserve the matching reference; connecting a store alone does not create it. |
| Shopify storefront cart | The standard tracker writes _atb_vid to the cart attributes; the order can carry it in note attributes. | Test headless storefronts and cart replacements separately. This integration starts with new orders. |
| Paddle Billing with Paddle.js | The standard tracker can add attriboo_visitor_id to Checkout.open customData. | Paddle.js must be detected by the tracker. A server-created transaction needs its own supported custom-data path. |
| PayPal JavaScript SDK | The standard tracker can add custom_id during supported order/subscription creation without replacing an existing value. | Server-created and existing custom_id flows need a developer to check the actual reference received. |
| WooCommerce | Use the Attriboo WordPress plugin with orders and refunds enabled. | Check a new paid order and its storefront visit. The plugin does not import earlier orders. |
Verify a known route before expanding
- Confirm one website, provider account and currency.
Check a recorded visit before investigating the matching payment.
- Inspect the reference on the actual checkout path.
Use the provider's metadata or order record with authorized access. A code snippet in a draft project does not prove the published checkout carried it.
- Reconcile the result.
Check the payment and refund dates, deduplication and visitor linkage. Retain an unmatched result when the evidence is absent. Never bypass consent or make a charge just to complete this checklist.
You are done when
You have identified the matching route for the checkout in use and know which known visit/payment pair to verify.
Still need a hand?
Send a question without needing to sign in.