# Charge a customer later

Charge a customer after they have left the checkout, on a schedule you run or on demand. How the first purchase creates a customer token, what the token can be charged for and which API each step calls.

You can charge a customer again after they've left the checkout — on a schedule you run,
such as a subscription, or whenever your own logic calls for it. Both work in two halves, and
they're further apart than they look. The first is an ordinary Kustom Checkout order, flagged
`recurring: true`. Completing it creates a **customer token** tied to the payment method the
customer chose. The second is every charge after that — a server-side call against that token,
with no checkout rendered and no customer present.

The flag is called `recurring`, but the token it creates isn't tied to a schedule. It's the
same token whether you charge it monthly or once, next year.

Nothing connects the halves except the token you stored, which is why the failure that
matters isn't a declined card but a token that has quietly stopped working.

**Why the customer is never asked to authenticate.** Strong customer authentication happens
once, at the checkout where the token is created, with the customer present. Every later charge
is initiated by you rather than by them and runs under that original authentication — which is
why a charge needs no interface and no redirect, and why a token that loses its standing
can't be repaired by asking the customer to try again. It's also why the failures worth
retrying and the ones that are permanent are different things: see [Charge a customer
token](/checkout/recurring/charging-a-token/).

## What a token is charged for

One token serves every shape of repeat purchase, and nothing in the token itself records
which one you intended:

- **A schedule you run** — a fixed commitment billed on your own cadence.
- **On-demand** — a charge whenever your own logic calls for one: a top-up, a usage
  overage, a re-order.

The cadence lives in your system, not in the order. Kustom charges what you send, when you
send it.

## Which API does what

| Step | Call | What it does | Guide |
|---|---|---|---|
| **1. Create the token** | [`POST /checkout/v3/orders`](/api/checkout/create-order-merchant/) | The customer's first purchase, flagged `recurring: true`. Once it's completed, [read the order](/api/checkout/read-order-merchant/) for its `recurring_token`. | [Create a customer token](/checkout/recurring/minting-a-token/) |
| **2. Charge it** | [`POST /customer-token/v1/tokens/{customerToken}/order`](/api/customer-tokens/charge-token/) | Every charge after the first. Creates a real order, with no checkout and no customer present. | [Charge a customer token](/checkout/recurring/charging-a-token/) |
| **3. Capture, if needed** | [`POST /ordermanagement/v1/orders/{order_id}/captures`](/api/order-management/capture-order/) | Only for charges made without `auto_capture: true`. | [Capture an order](/order-management/capture/) |

Every token call is in the [Customer Token API reference](/api/customer-tokens/), including
reading a token and disabling it.

## What this costs you at the checkout

Two constraints are worth knowing before you build, because both are visible to the
customer and neither can be worked around later:

- **Flagging an order as recurring removes the financing payment methods.** The customer sees a smaller set of options than on an ordinary order.
- **A token belongs to the merchant ID that created it.** You can't create a token under one MID and charge it under another.

Recurring also has to be enabled on your merchant account before any of this works — without
the entitlement, creating an order with `recurring: true` is rejected with `400` and
`error_code: BAD_VALUE`. Contact Kustom merchant support.

## Treat the token as a credential

A customer token can charge a real person, and nothing in the Customer Token API can tell
you that you charged the wrong one. It's a secret with a blast radius, so store it the
way you would store a card token: encrypted at rest, never in a log, never in a URL and
bound in your own database to exactly one customer.

## Related

- [Create a customer token](/checkout/recurring/minting-a-token/) — the first purchase
- [Charging a token & retries](/checkout/recurring/charging-a-token/) — every purchase after it
- [Saved payment methods](/checkout/saved-payment-methods/) — the same idea from the customer's side, for one-click repeat purchases
- [Order lines and tax](/checkout/tax-and-order-lines/) — what Kustom validates on every line
- [Migrating from Vipps Recurring](/checkout/recurring/migrating-from-vipps-recurring/) — moving Vipps MobilePay agreements to customer tokens