Unscheduled Card on File

Charge a saved card when an agreed event happens. Typical uses are account top-ups, usage-based billing, and charges that come after a service is delivered.

Unscheduled card on file lets you take a payment from your customer's saved card without them being present (e.g., when something you both agreed to in advance takes place). Your customer agrees once during a normal checkout. Thereafter, you charge them when the agreed event occurs.

It complements Card on file, which covers payments the cardholder starts.

---

How it differs from recurring payments

Where you would use it

• Account top-ups and wallet reloads. Reload a customer's balance automatically when it falls below a level they set (for transit cards, gaming wallets, telecom credit, etc.).
• Usage-based and pay-as-you-go services. Bill for what the customer actually used (e.g., cloud computing, metered utilities, the fare at the end of a ride).
• Post-service and incidental charges. Charge for something found after the customer has left — minibar items, vehicle damage or tolls, a freight surcharge.
• One-click reorders. Take payment for a repeat order placed under terms the customer has already accepted.

How it works

There are two stages, and they are different kinds of payment.

Stage one — your customer agrees (a customer-initiated transaction). The customer is with you at checkout. They agree to save their card for the charges you have described, and they approve the payment with their bank through 3-D Secure. You can either verify the card without taking any money, or take a first payment at the same time. N-Genius Online stores the card and gives you a token: a reference that stands in for the card number.

Stage two — you charge the card (a merchant-initiated transaction). The customer is not there. Your system sends the charge using the stored token. There is no authentication step for the customer to complete, because they already completed it in stage one.

flowchart LR
  A[Customer agrees at checkout] --> B[3-D Secure check]
  B --> C[Card stored and token returned]
  C --> D{Agreed event happens}
  D --> E[You charge the saved card]
  E --> F[Receipt sent to customer]
  E --> G{Payment fails}
  G --> H[See what to do below]

What you need to have in place

Card schemes set conditions on storing and reusing a customer's card. They are your responsibility as the merchant.

• A record of the agreement. Keep a record of what the customer agreed to — what triggers a charge, that the amount will vary, and how they can cancel. Keep it for as long as the agreement is active. If a payment is ever disputed, you will be asked to produce it.
• A receipt after every charge. Send an itemised receipt or invoice every time you charge the card, including the first time. You can send these yourself or use N-Genius Online notifications.
• No card details on your systems. Never store card numbers or security codes. The security code is used once, during the initial checkout, and never again.

Turning it on

When a payment does not go through

Three things can happen, and they call for different responses:

For developers

Endpoints, requests, responses and decline handling are in the API reference:

• Unscheduled card on file — overview
• Set up the agreement
• Receive the stored-card token
• Charge a stored card
• Declines and retries