TokeniTokenEx /v2/Pci
Keep tx-tokenex-id and tx-apikey headers. Point the base URL at Tokeni.
If you already call TokenEx PCI endpoints, Tokeni exposes the same path shapes on the gateway. Auth is the TokenEx headers, mapped to a Tokeni merchant and API key.
Headers
| Header | Tokeni mapping |
|---|---|
tx-tokenex-id | Merchant ID |
tx-apikey | API key |
Do not send Authorization: Basic on these routes. Use the tx-* headers.
Routes
| Method | Path |
|---|---|
| POST | /v2/Pci/Tokenize |
| POST | /v2/Pci/AssociateCvv |
| POST | /v2/Pci/DetokenizeWithCvv |
| POST | /v2/Pci/GetBINAndLastFour |
| POST | /v2/Pci/ValidateToken |
| POST | /v2/TransparentGatewayAPI/Detokenize |
Base URL: https://sandbox-api.tokeni.io then https://api.tokeni.io.
Hosted fields on Tokeni also speak the TokenEx iframe auth key format (HMAC-SHA256 over merchantId|origin|timestamp|tokenScheme). See Hosted fields.
What this is not
This is a compatibility surface for tokenize, CVV associate, BIN/last four, validate, and transparent-gateway detokenize. It is not a claim that every TokenEx product, network token, or 3DS flow exists on Tokeni. If a path is not in the API reference, it is not implemented.
When you can, use /api/v1/tokenize and hosted fields with Basic auth. The /v2/Pci routes are for moving an existing integration without rewriting every call at once.