jTS: Tokenization on the jPOS Control Plane

Tokenization is useful when it changes where card data has to live. Replacing a PAN with another number achieves little if every application holding that number can exchange it for the original card.

The jTS integration in the jPOS Control Plane makes that distinction explicit: a token requestor can tokenize a card, but resolving the token back to card data requires a separate station permission.

A token belongs to a requestor

Each token requestor has a stable identity, its TRID, bound to a business entity. A web shop, for example, can use its requestor credential to create tokens, retrieve their metadata, and revoke them. It cannot detokenize them.

The token is a randomly generated, sixteen-digit, Luhn-valid reference under the entity’s configured token BIN—not an encrypted PAN. The same card presented again by the same requestor returns its existing token; a different requestor receives a different token. Rotating a requestor’s signing key does not change its identity or its tokens.

Behind that reference, jTS stores the card data encrypted through the platform’s crypto-service. Metadata can provide the last four digits and expiry for display without returning the PAN. CVV is not stored and cannot be recovered by detokenization.

Resolving the token at the station

The new ss-rest integration accepts card.token instead of the card details in a purchase request. The station uses its own JTS_STATION credential to resolve that token through jTS, then builds the ISO 8583 authorization for jCard.

That placement matters. The merchant-facing application can retain the token, while the station handles the PAN needed for authorization. jCard continues to process the card message through its existing participant chain; it does not acquire a synchronous dependency on the Control Plane to resolve tokens itself.

The PAN therefore does leave the vault when an authorized station needs it. The boundary is about controlling who can obtain it, not pretending it disappears from payment processing. An unknown or revoked token, or an unavailable tokenization service, stops the request before it reaches the issuer.

Exercising the boundary

The video demonstrates this with the e-commerce simulator, jTS, ss-rest, and a live jCard issuer. The useful comparison is not just a purchase with card details followed by a purchase with a token. It is the same detokenization operation attempted under two different identities: refused for the web shop, permitted for the station.

The DevTools tokenizer calls the real jTS API. Its requests are signed for the selected TRID and sent without the browser’s session cookie, so being logged into the Control Plane does not substitute the administrator’s session permissions for the requestor’s API permissions.

The transaction inspector, station logs, and jTS dashboard let us follow the result across those components: token creation, permission checks, resolution at the station, and authorization at the issuer. The optional AI explanation adds a readable account of the transaction and ledger activity; the underlying records remain available for inspection.

This is the part worth watching: how a token becomes a payment without giving every application along the way permission to recover the card.