Install the snippet

The snippet is the shortest way to capture evidence: two tags in your checkout and one call per event. It talks to the browser channel for you.

If your checkout is rendered on the server, or if you prefer not to load a third-party script, skip this page and call the endpoint directly.

Where to get the token

In the dashboard, under Settings › Integrations, on the capture SDK card. Enable it and the dashboard shows the ready-made snippet, already with the token of the selected merchant. The card shows up for those who have the dispute product active.

The token is publishable: it stays in your store’s HTML and needs no protection. With it you can only send events, never read data. An event that does not match one of your orders is discarded.

Installation

<script src="https://api.rapidchargeback.com/sdk/v1/rapid.js"></script>
<script>rapid('init',{token:'your_publishable_token'})</script>

Two things matter in the order above:

init has to come after the script loads, which is why the tag has neither async nor defer
init already starts identifying the device, so call it as early as possible on the page, not only at payment time

The script is about 5 KB, has no dependencies and does not block the page.

Calls

// Purchase completed. Also captures the device data.
rapid('checkout', { order_ref: 'TXN-2026-001' })

// Customer accepted the terms.
rapid('terms', { order_ref: 'TXN-2026-001' })

// Customer accessed the product.
rapid('track', 'access_log', { order_ref: 'TXN-2026-001' })

// Customer used the product or service.
rapid('track', 'usage_log', { order_ref: 'TXN-2026-001' })

Call	Event generated	Payload the snippet builds
`rapid('checkout', …)`	`checkout`	device identification
`rapid('terms', …)`	`terms_acceptance`	the page URL
`rapid('track', 'access_log', …)`	`access_log`	the page URL
`rapid('track', 'usage_log', …)`	`usage_log`	the page URL

order_ref is required in all of them. It is the order identifier in your system, the same one you send in external_id when creating the transaction. See Types and payload.

A call without order_ref is ignored: it generates neither an event nor a visible error.

Fire and forget

The snippet never breaks the checkout, and that has a cost worth knowing:

every call is silent. It throws no exception, returns no promise and does not read the response
validation errors (wrong type, order_ref too long) do not show up in the console
network failures are not retried in the browser

To test the integration, call the browser endpoint directly with curl, where you see the status and the message. Once validated, the snippet does the same in production.

Sending uses navigator.sendBeacon when available, with fetch in keepalive mode as the alternative. Both survive navigation to the next page, so the checkout event is not lost in the payment redirect.

Device identification

On checkout, the snippet identifies the device before sending the event. It tries Fingerprint, with a 2-second cap, and falls back to its own identification if it cannot (an identifier in localStorage plus a hash of browser attributes).

The result goes in the payload’s fp field:

`fp`	Meaning
`pro`	Fingerprint identification, validated on the server side
`fallback`	the snippet’s own identification

The difference is practical: only the validated identification fills in the transaction’s device and IP and generates the verification record. See The checkout event.

If your site has a strict CSP, Fingerprint is loaded from https://fpjscdn.net. If it is blocked, capture keeps working in fallback mode.

How to know it is working

The same dashboard card shows whether the account has already received events and when the last one was. After installing, make a test purchase and check there.