Charge a customer later

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.

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	The customer’s first purchase, flagged recurring: true. Once it’s completed, read the order for its recurring_token.	Create a customer token
2. Charge it	POST /customer-token/v1/tokens/{customerToken}/order	Every charge after the first. Creates a real order, with no checkout and no customer present.	Charge a customer token
3. Capture, if needed	POST /ordermanagement/v1/orders/{order_id}/captures	Only for charges made without auto_capture: true.	Capture an order

Every token call is in the Customer Token API reference, 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 — the first purchase
• Charging a token & retries — every purchase after it
• Saved payment methods — the same idea from the customer’s side, for one-click repeat purchases
• Order lines and tax — what Kustom validates on every line
• Migrating from Vipps Recurring — moving Vipps MobilePay agreements to customer tokens