Skip to main content
The card method supports stored credentials (the card brands’ COF mandate): your payer saves their card with explicit consent on the first payment, and afterwards you can offer one-click payment without re-typing the number — or charge subscriptions and unscheduled amounts yourself without the payer present. The card number never exists in your integration or on the platform: only an opaque processor reference plus display data (brand, last 4 digits, expiry) is stored.
1

Seed: offer to save the card on the first payment

Create the card payin with save_card: true and your payer reference:
The hosted page shows a “Save this card for future payments” checkbox. The credential is stored ONLY if the payer ticks it and the 3-D Secure payment is approved. On credit you receive the card_stored webhook and the card appears in your list.
2

List the payer's cards

3

Pay with a saved card (payer present)

Create the card payin with stored_card_id: the page skips card entry, shows the saved card (VISA •••• 2701) and 3-D Secure still runs — the payer only confirms with their bank. The billing details the payer entered when saving the card are also kept on file: the page applies them automatically and shows only a masked summary (name, partial email, city) with a “use different details” link in case they want to change them — nothing is retyped. This server-to-server path needs no extra verification: you already know your customer.Don’t know which card they have saved (or whether they have one)? Don’t pass stored_card_id: the payment page lets the payer discover their cards by verifying their email with a code — see the payer discovers their cards.
4

Recurring / unscheduled charge (payer not present)

Charge the card directly — subscriptions (recurring: true) or unscheduled amounts your customer agreed to:
Response 201 — an approved charge credits your balance automatically (payin_credited webhook, same path as any card payin):
An issuer decline responds 422 with the payin in failed and a failure_reason. A retry with the same idempotency_key returns the original payin and never charges twice.
To revoke a saved card (at the payer’s request or on suspicion): DELETE /v1/stored-cards/{stored_card_id} — charges stop working immediately and you receive stored_card_revoked (422 stored_card_revoked if you try to charge it afterwards).
Charges without the payer present travel without 3-D Secure by definition of the mandate: the chargeback risk is yours. Charge only what your customer explicitly agreed to — the platform persists the seed’s consent evidence (checkbox, IP and timestamp) for disputes.

​
The payer discovers their cards on the payment page

Every card payment page — the payment_url of a card payin and the card option of the universal checkout — asks for the payer’s email as the first field. If that email has saved cards with you, the page sends a verification code (branded with your organization’s identity) and only once they enter it correctly does it reveal their cards: brand, last 4 digits and expiry, never the full number. Picking one pays with 3-D Secure without re-typing it; they can also choose “use another card” and pay with a new one.
1

The payer types their email

If you already sent it in customer.email (or a payer_reference holding an email), the page shows it pre-filled. If the email has no saved cards, the new-card form carries on — nothing is revealed.
2

They verify it with the code (once per device)

When cards are found, the page emails a code and asks for it. The “Remember this device” checkbox (checked by default) trusts the device for 30 days: later payments with that email in that browser show the cards without asking for a code.
3

They pick the card and pay

With the email verified, the payer sees their masked cards, picks one and only completes 3-D Secure. The verified email becomes the payer identity of the charge — it wins over any email typed into the form.
Trust is per device and lasts 30 days; each payer can have up to 10 remembered devices (the oldest is forgotten past the cap). If a payer loses a device, support can revoke their remembered devices and they will get a code again on their next payment.

​
Subscriptions (scheduled recurring charges)

Instead of charging manually every month, let the platform run the schedule: create a subscription on the saved card — the first period is charged on creation (unless start_at is in the future) and the rest fire automatically per interval.
Response 201 (first_charge is present when the first period was charged on creation):
  • interval: daily, weekly, monthly or yearly. The day of month is kept and clamped to the last day in short months (a plan on the 31st charges on Feb 28/29 and returns to the 31st in March).
  • start_at (optional, future RFC3339): defers the first charge (trial / start date); without it, it charges on creation.
  • Dunning: on an issuer decline the platform retries every 24h up to 3 times; exhausted, the subscription becomes past_due and you get the subscription_status_changed webhook. resume reactivates it with a fresh attempt.
  • Each successful charge credits your balance like any card payin (payin_credited webhook, carrying subscription_id to link it to the plan).
Lifecycle management:
Revoking the saved card (DELETE /v1/stored-cards/{id}) automatically cancels its subscriptions (cancel_reason: card_revoked).

​
Subscription states

​
Errors

The general error catalog lives in Errors.

​
FAQ

Never. Saving a card stores an opaque network token — the PAN never touches the platform. Revoking the credential invalidates the token.
Merchant-initiated transactions (MIT) run without 3DS by card-network mandate: the payer authenticated with 3DS on the initial consented payment, and every MIT references that transaction.
They are canceled automatically (card_revoked). The payer must save the card again and you create a new subscription.
No — there is no catch-up: periods elapsed while paused advance the counter without charging. Resuming charges from the next due period only.
The scheduler retries up to 3 times, 24 h apart. If all fail the plan moves to past_due and you receive subscription_status_changed — no more charges until you resume.
Synchronously at creation, unless you pass a future start_at (trial): then the first charge waits for that date.
To show their saved cards without letting anyone who knows their email see them: the list is only revealed after the email is verified with the code (or on an already remembered device). If the email has no cards, the page carries straight on to the new-card form.
No: with “Remember this device” (checked by default) the browser stays trusted for 30 days and later payments with that email show the cards without a code. After that — or on another device — they verify again.
Last modified on August 4, 2026