# 

A payment token is a meaningless identifier that stands in for a card number. It
is worth nothing to anyone who steals it, because it only works against your
merchant account.

The practical effect: you can charge a returning customer without ever storing
their card number.

## Why it matters

Storing card numbers puts your systems in PCI DSS scope — every server that
touches one, every backup, every log. Tokens do not carry that weight, because a
token is not cardholder data.

```mermaid
---
config:
  theme: 'neutral'
---
flowchart LR
    A[Card number] -->|first transaction| B[Gateway vault]
    B -->|returns| C[payment_token]
    C -->|you store| D[Your database]
    D -->|later charges| B
```

Your database holds the token. The card number stays with us.

## How you get one

**Not from a tokenization endpoint — there isn't one.** A token is issued as a
side effect of a transaction: send real card details, and an approved response
carries `payment_method.payment_token`.

Send that token as `payment_method.type` of `Token` next time.

[Save and reuse a payment method](/docs/payments/save-and-reuse-a-payment-method)
has the mechanics, including the check to do before you store the value.

## What a token is not

* **Not a card number.** It cannot be used anywhere else, by you or anyone else.
* **Not reversible by you.** There is no detokenize call. The gateway resolves it
internally when you charge it.
* **Not a customer record.** A token identifies an instrument, not a person. Your
application owns the relationship between the two.
* **Not permission to bill.** Storing a token is not the same as having consent
for a recurring charge. See [Recurring payments](/docs/payments/recurring-payments).


## Next steps

* [Save and reuse a payment method](/docs/payments/save-and-reuse-a-payment-method)
* [PCI DSS and your scope](/docs/concepts/pci-dss)