Tokenization
Tokenization is how you securely collect card data in the browser without your server ever touching raw card numbers. The Strictly platform uses ZeroGateway.js — a client-side JavaScript library that renders hosted input fields and exchanges card details for a single-use payment token.
Your server then uses that token to make charge or vault requests. Raw card numbers never pass through your infrastructure.
The platform uses two separate keys: a tokenization key (client-side, loaded with ZeroGateway.js)
and an API key (key-hash, server-side only). They are not interchangeable — using the wrong
one in the wrong context will fail silently or with an auth error.
How it works
Code
Setup
-
Get your tokenization key
In the Strictly dashboard, go to Administration → Security Keys and copy the value under Tokenization Source. This key is safe to expose in client-side code.
-
Create placeholder containers
ZeroGateway.js injects hosted iframes into your page. Add empty
divelements where you want the fields to appear:index.html -
Load the script
Load ZeroGateway.js with your tokenization key as a query parameter:
CodeReplace
YOUR_TOKENIZATION_KEYwith the key from Administration → Security Keys. -
Initialize ZeroGateway.js
Call
CollectJS.configureto map your placeholder divs to payment fields and set up the token callback:payment.jsThe callback receives:
callback responseField Description tokenSingle-use paymentTokencard.numberMasked card number — send it as card.numberon charge and vault requestscard.expExpiration normalized to MMYYcard.hashCard fingerprint checkBank-account (check) tokenization data, when applicable There is no
binfield — derive the BIN from the first 6 digits ofcard.numberwhen you need it for surcharge rates. -
Send the token to your server
Pass the token and the masked card from the callback to your backend. Your server then uses them to make the charge request (
card.numberis required alongsidecard.paymentToken):payment.js — send to your backend -
Charge from your server
Your server receives the token and makes the charge request to the Strictly API. The raw token never hits the browser again. The example below uses Java, but this works the same in any server-side language:
ChargeController.java — Spring Boot
Payment tokens are single-use
A paymentToken is valid for one transaction only. It is consumed by POST /payment/charge,
POST /customer (create with card) and POST /customer/card/{id} (add card). It is not
consumed by GET /payment/rate, so you can fetch the surcharge rate and then charge with the same
token. Do not store or reuse tokens after they are consumed.
If you need to charge a customer multiple times without re-collecting their card, use the
Customer Vault to store their card and charge via vaultId.
Server-side tokenization
For PCI-scoped integrations that already handle raw card data, a server-side endpoint exists:
POST /v1/public/tokenize with { tokenizationKey, ccnumber, ccexp, cvv }. It returns the same
single-use token. Prefer ZeroGateway.js unless your infrastructure is already in PCI scope.
Styling the hosted fields
ZeroGateway.js fields are iframes — you cannot style them directly with your page's CSS. Instead, pass
style rules through the CollectJS.configure options:
Code
Testing tokenization
In sandbox, use the pre-built test token instead of going through the full ZeroGateway.js flow:
| Field | Value |
|---|---|
Test paymentToken | 00000000-000000-000000-000000000000 |
| Simulates card | 4111 1111 1111 1111 |
Pass this directly as card.paymentToken in your server-side charge requests. See
Sandbox & Testing for the full list of test cards.
Next steps
- Surcharge Payments — if your account has surcharging enabled,
you must call
/ratebefore charging and show the customer the breakdown - Customer Vault — store a tokenized card so customers don't re-enter details on every purchase
- Quick Start — make your first charge end-to-end
- Code Examples — full integration examples in multiple stacks

