# 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.

Canonical page: https://www.attriboo.com/docs/payments/checkout-matching

Instructions reviewed: 2026-10-31

## 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

1. **Confirm one website, provider account and currency.** Check a recorded visit before investigating the matching payment.

2. **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.

3. **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.

- [Choose the provider connection and history scope](https://www.attriboo.com/docs/payment-connections)
- [Understand revenue records](https://www.attriboo.com/docs/revenue)

## You are done when

You have identified the matching route for the checkout in use and know which known visit/payment pair to verify.

## Related guides

- [Connect your payment provider](https://www.attriboo.com/docs/markdown/payment-connections.md)
- [Track Stripe Payment Links](https://www.attriboo.com/docs/markdown/payments/stripe-payment-links.md)
- [Track Server-Created Stripe Checkout](https://www.attriboo.com/docs/markdown/payments/stripe-checkout.md)
- [Visits appear but sales do not](https://www.attriboo.com/docs/markdown/troubleshooting/missing-sales.md)