# 

A payment token stands in for a card or a bank account. Charging a token instead of a number keeps the number out of your systems, which is the single biggest thing you can do to narrow your PCI scope.

**There is no endpoint that creates a token.** No `POST /v1/payment_tokens`, no vault to manage, nothing to update or delete. A token is issued to you as a side effect of a transaction, and that is the only way to get one.

## How you get a token

Run any transaction with real card or bank details. If it is approved, the response carries a token for the instrument you sent.

```json
{
  "result": "APPROVED",
  "payment_method": {
    "type": "CARD",
    "truncated_pan": "****-****-****-5439",
    "payment_token": "CARD_TOKEN-01KFDKXMQ637EKEAY410MSQSXB"
  }
}
```

Store `payment_method.payment_token` against your customer record. Store the `truncated_pan` too if you want to show the customer which card is on file — it is the only part of the number you will have.

**The prefix says what a token stands for.** A token for a card begins with `CARD_TOKEN-`, and one for a bank account with `BANK_TOKEN-`. Tokens issued before 2026-10-16 begin with `PAYMENT_TOKEN-` and still work, so their prefix does not tell you which kind they are. Keep the response's `payment_method.type` beside the token if you need to know. Send the value back exactly as you received it.

**Check the value before you store it.** The response to the transaction never reports a missing token as `null`. A declined payment returns an empty string, and an approved one that could not be tokenized returns the sentence `Payment method could not be tokenized.` A later read of the transaction reports both as `null`. A token always begins with `CARD_TOKEN-`, `BANK_TOKEN-` or `PAYMENT_TOKEN-`; anything else is an error message, and storing it will fail the next charge.

## Charge a saved token

Send `payment_method.type` of `TOKEN` and the stored value. No PAN, no expiry, no CVV.

The gateway resolves the token back to the instrument behind it before it does anything else. So a token issued for a card behaves exactly like that card, and a token issued for a bank account behaves like that account — including which transaction types it accepts. The response reports that instrument too: `payment_method.type` comes back `CARD` or `ACH`, never `TOKEN`.

**A card token's expiry year comes back as two digits.** On the response to a payment charged to a card token, `payment_method.expiry.year` reads `"30"` for a card that expires in 2030. The card payment that issued the token returned `"2030"`, and a later read of either transaction returns four digits too. Read a two-digit year as 20YY.

| Token was issued for | Accepts |
|  --- | --- |
| A card | `SALE`, `AUTH` |
| A bank account | `SALE`, `PAYOUT` |


A token the gateway cannot resolve returns `400` with `INVALID_REQUEST_DATA`, and `details` names `payment_method`.

## Send a SEC code with a bank account token

A token holds the bank account and nothing about any one payment. The Standard Entry Class (SEC) code says how the customer authorized this particular debit or credit, so it goes on the request, beside the token.

* **Send it on every payment with a bank account token.** Leave it out and the request returns `400` with `REQUIRED_DATA_MISSING`, and `details` names `payment_method.standard_entry_class`. There is no default, the same as for a bank account sent in full.
* **The token does not keep the code** from the payment that issued it, so send the one that matches this payment.
* **With a card token, the code is ignored.** The card payment goes ahead as if you had not sent it.


The response and every later read of the transaction report the code it ran under. [Choosing a SEC code](/docs/payments/accept-an-ach-payment#choosing-a-sec-code) lists the codes and when each one applies.

## There is nothing to manage

Because tokens are issued rather than created, the operations you might expect do not exist:

* **No update.** A card's expiry changing does not give you a way to edit the token. Take the new details and run a transaction to get a new one.
* **No delete.** Stop using a token and stop storing it. There is no call to make.
* **No list.** The gateway does not offer a token directory. Your customer record is the index.


If a saved token stops working — a reissued card, a closed account — the next charge fails and you collect fresh details.

## Charging a saved card on a schedule

Storing a token is not the same as having permission to bill it again. Card network rules ask you to record consent when the card is first stored and to flag later charges as merchant-initiated.

[Recurring payments](/docs/payments/recurring-payments) covers the fields that do that, and they matter: getting them wrong raises your decline rate.

## Next steps

* [Recurring payments](/docs/payments/recurring-payments)
* [Tokenization](/docs/concepts/tokenization)
* [PCI DSS and your scope](/docs/concepts/pci-dss)