Developer guide
Payment tokenization lets applications operate on references instead of raw card data.
Tokenization is a payment-security pattern where the merchant application uses a processor-provided token or reference instead of handling the customer's raw card number. The details and scope are determined by the payment provider.
Hosted collection first
A hosted payment field or checkout component keeps the sensitive card-entry interaction in the processor's environment. The merchant application receives a tokenized payment reference that can be used in the approved integration flow.
Tokens do not remove operational responsibilities
A tokenized integration still needs access controls, secure server-side API calls, idempotency, signed webhooks, merchant-account gating, and careful logs. Tokens should be handled according to the processor's requirements and the merchant's data policy.
What tokenization does not mean
A token is not permission to process any merchant, product, currency, or payment method. It is not a replacement for partner approval, and it does not make an integration safe if the server exposes secrets, accepts unsigned events, or retries a payment without idempotency.
The useful question is not whether a system uses tokens. It is whether the entire payment path keeps sensitive collection upstream, limits references to the approved merchant, and produces enough evidence to reconcile what happened.
- Tokenized references remain scoped to an approved merchant and capability
- Signed event verification and replay protection are still required
- Logs and support tools must avoid turning references into sensitive payloads