Purchases from the script

When you control a thank-you page but cannot add a server integration, you can report a completed purchase from that page. Install the tracker first. Use this only if the page can supply the actual successful order's amount, currency and stable ID; visiting a generic success URL is not proof of payment.

window.trafficcx?.('purchase', {
  revenue: { amount: 49, currency: 'USD' },
  id: 'order_1001', // your order ID
  props: { plan: 'pro' },
});

• Run the call after the tracker loads. Optional chaining avoids an error if it is blocked, but does not queue or retry a missing call.
• The purchase is associated with the recorded visit it happened in. To see it as a goal conversion, configure a custom-event goal named purchase; another event name can be used if your goal matches it.
• Supported currencies are converted to the site's reporting currency using historical ECB rates. Missing rates can delay conversion.
• Deduplication. If a verified payment (Stripe, Dodo Payments, Lemon Squeezy, Polar or the Payments API) has the same ID as id (its transaction ID, Checkout Session, or order ID), the verified one replaces the script's report, keeping its goal. Send id whenever you have one.
• The Revenue page labels these payments Tracker.

Anyone can send events to a public script, so treat these numbers like any client-side analytics. For money that matters, connect a provider or use the Payments API.

Verify the report

On a separate test site, complete a test order and report its real test order ID. Find the payment labelled Tracker in Revenue. Reload the thank-you page with the same ID and check that it does not add another payment. If you also connect a provider, confirm that its verified payment replaces the tracker report using a matching transaction ID or supported external reference; unrelated IDs will not deduplicate.

Troubleshooting and limits

• A blocked script or a call made before it loads may send nothing. Check the Network panel and window.trafficcx first.
• A different browser or an untracked checkout page can lose the original visit link. A server/provider integration with checkout IDs is more reliable.
• Do not put provider API keys or customer email addresses in this browser call. Use only the order fields and non-personal event properties needed for the report.
• For a real refund, use a provider integration or the Payments API. A client-side purchase event is not a refund instruction.
• The custom purchase event also counts toward your event allowance. Use an actual order ID consistently; a newly generated ID on every reload creates separate reports.

Tracker events and deduplication are exercised in local tests; fresh transactions in a hosted checkout remain part of verifying your own integration. See revenue attribution and identity limits.