Saved cards and recurring payments

For subscriptions and returning customers, asking for card details every time kills conversion. Saved cards fix that. Here's how they work.

What gets saved

When a customer pays by card, the processor returns a reusable authorization — a token representing that card. We store it (never the raw card number) against the customer's email. You get an authorization_code you can charge again.

Reusable only

Only cards that the processor marks reusable are saved. One-time channels like bank transfer aren't — there's nothing to re-charge, so they're correctly excluded.

Re-charging

To bill a saved card, call the charge-authorization endpoint with the authorization_code, the customer's email, and the amount. It's synchronous — you get success or a decline right away. Perfect for subscriptions, top-ups, and one-click checkout.

Building subscriptions

1. Take the first payment normally; the card gets saved.
2. On your billing schedule (a cron job), charge the saved authorization.
3. Handle declines gracefully — retry, then notify the customer.

Keep authorizations safe

Treat an authorization_code like a secret: anyone holding it can charge that card through your account. Store them server-side only.

Listing saved cards

You can list the saved cards for a customer to power a "pay with a card on file" experience.

Saved cards turn every repeat purchase into a single tap — the foundation of recurring revenue.