Card on File

Securely store a customer's card, then charge that saved card for later payments — unlocking use cases like subscriptions, instalments, or charges that happen after the customer has left, such as a no-show or cancellation fee.

Card on file lets you securely store a customer's card details during an initial payment so you can charge the same card again later, without asking them to enter their details each time. Teya stores and tokenises the card on your behalf: you keep a reference to the saved card — a token_id — and the raw card details never touch your systems, which helps reduce your PCI scope.

Every card-on-file arrangement involves two kinds of payment:

  • Customer-initiated — the customer is present and actively agrees that you can store the card and charge it again in future.
  • Merchant-initiated — you charge the stored card on the customer's behalf, without them being present, following the terms they agreed to up front.

The first payment is always customer-initiated. Later charges are usually merchant-initiated, but not always — a one-click checkout is customer-initiated too, even though the card is already saved.

Consent comes first
Before you store a card, you must obtain and record the customer's agreement to save it and charge it again. That agreement — often called a mandate — defines when, how often, and for how much you can charge the card. It is what makes the later merchant-initiated payments valid.

Use cases

Card on file supports three common patterns. They differ mainly in how many times you charge the card, how much each charge is, and when those charges happen.

Recurring payments
Charge the saved card automatically every billing cycle, until the customer cancels.
Ongoing · same amount
Instalments
Split one purchase into a fixed series of scheduled charges, until the total is paid off.
Fixed count · known total
Charges on saved payment methods
Charge the card later, only if and when a defined event happens — a no-show, a cancellation, or a final bill.
On event · variable

How it works

Whichever pattern you use, the shape of the flow is the same: collect and store the card once, then charge it later.

1 Initial payment (customer-initiated)
2 Teya stores the card and returns a token
3 Charge the token later

1. Initial payment. The customer enters their card during checkout and agrees that you can store it. This can be a real first payment, or a zero-amount verification that confirms the card without charging it.

2. Store the card. Teya tokenises and securely stores the card. The payment.succeeded.v1 webhook delivers a token_id that you store against the customer, along with the card brand and last four digits for display.

3. Charge later. When the next cycle, instalment, or event arrives, you charge the stored token_id for the agreed amount. Merchant-initiated charges return a final result immediately; customer-initiated charges may require a 3D Secure challenge that you present.

Storing the card

How you capture and store the card during the initial payment depends on your integration. Each Customize guide covers the fields to send and what you get back.

Pay By Link
Store the card from a payment link, with no website of your own.
View docs
Hosted Checkout
Store the card on the Teya-hosted checkout page you redirect to.
View docs
Embedded Components
Store the card from the checkout element embedded in your own page.
View docs

What happens when the saved card expires?

Teya automatically updates the saved-card token when the underlying card expires. You can continue using the same token_id to process payments; you do not need to update the token or collect the card again solely because it has expired.

Ready to charge a saved card?

The charge guide covers customer-initiated and merchant-initiated payments, 3D Secure handling, and decline responses.

Charge a Saved Payment Method