Saved Card Payments
Saved card payments let you charge a customer's card at a later date without them needing to be present. Use this when you need to charge a customer and save their card details all in one session.
How It Works
The first time a customer checks out, their card is captured and tokenised during the payment. Super handles 3D Secure authentication automatically. Once the payment completes, you receive a paymentMethodId via webhook - a secure token that represents the customer's saved card.
From that point on, you use the paymentMethodId to charge the customer whenever a payment is due. No checkout session, no redirect, no customer interaction required. These subsequent charges are merchant-initiated transactions (MITs) and are exempt from Strong Customer Authentication.
Saving a card is supported across all Super integration methods - Embedded Checkout, Hosted Page, and Payment Links. You can also save a card without taking a payment upfront.
📘 Subscription Scheduling
We do not manage billing schedules. Determining when to trigger each payment - renewal dates, retry logic, billing cycles - is handled by your system.
Guides
paymentMethodId via webhook for all future charges.
paymentMethodId.
paymentMethodId to charge the customer at any future point - no checkout flow, no redirect, no 3DS.
3DS & SCA
Strong Customer Authentication applies only to the initial payment where the customer is present. All subsequent charges via paymentMethodId are merchant-initiated transactions and are fully exempt from SCA.
| Transaction | Customer present | 3DS required |
|---|---|---|
| Save a Card & Take Payment | Yes | Yes - handled automatically by Super |
| Save a Card Only | Yes | Yes - handled automatically by Super |
| Charge a Saved Card | No | No - MIT exemption applies |
Updated about 6 hours ago
