# Create a tokenization session, tokenize card details client-side, then mint a reusable secure token.

Create a tokenization session, tokenize card details client-side, then mint a reusable secure token.

1. Create a Hosted Fields session for the terminal by POSTing to /processing-terminals/{processingTerminalId}/hosted-fields-sessions with scenario `tokenization`. The returned session token (expires after 10 minutes) is placed in the Hosted Fields JavaScript config in the browser. To UPDATE an already-saved card, also send the existing secureTokenId in this request. Requires an Idempotency-Key header and the libVersion.
 [createSession](/api/create-session)
2. OFF-API, client-side: the Hosted Fields JavaScript library renders the embedded fields using the tokenization-scenario session token from the previous step, the customer submits their card details, and the client receives a single-use token in a `submissionSuccess` event. The token is single-use and expires ~30 minutes after issue; it is the `singleUseToken` input consumed by the next step.

3. Convert a single-use token (from a session created with scenario `tokenization`) into a REUSABLE secure token by POSTing to /processing-terminals/{processingTerminalId}/secure-tokens with a source of type singleUseToken. Because a single-use token can be used only once, this consumes the token. The response `token` value — not secureTokenId — is what a later payment's paymentMethod.token expects. mitAgreement is required when saving card details. Requires an Idempotency-Key header.
 [createSecureToken](/api/create-secure-token)

## Workflow diagram

```mermaid
flowchart TD
  step0["1. session request · API"]
  step1["2. hosted fields submit · Manual"]
  step0 --> step1
  step2["3. secure token request · API"]
  step1 --> step2
```