Stored Credentials & Recurring Charges
Two kinds of transaction
Card schemes and direct debit rules distinguish who initiated a charge:
- Customer-initiated (CIT) — the customer is present and actively paying: a checkout, a one-off payment, the moment they save their details.
- Merchant-initiated (MIT) — you charge a stored method later, under a prior agreement: subscription renewals, usage bills, payment plan instalments, repeat phone orders.
The rules require that an MIT be traceable back to a properly established agreement. Done right, merchant-initiated charges are approved more often, disputed less, and processed at the best available scheme treatment. Done wrong, they degrade silently — more declines, weaker dispute standing.
What “properly established” means
For cards, the stored credential must be created during a real, customer-present transaction — either a verification (Setup Intent) or the customer’s first purchase. That founding transaction produces a network transaction reference that every later merchant-initiated charge must cite, along with stored-credential flags identifying the charge as an MIT under an existing agreement.
For BECS, the equivalent is the direct debit mandate: electronic acceptance of a Direct Debit Request, with evidence retained.
What ElasticPay does automatically
When you use the standard flows — Setup Intent or the store-on-first-purchase flag — ElasticPay:
- establishes the credential with a genuine verification or purchase transaction (never a bare “store this number”)
- captures the network transaction reference from that founding transaction
- flags every later charge against that
pm_xxxcorrectly as customer-initiated or merchant-initiated, and threads the original reference through each MIT - generates, stores, and retains the BECS mandate and its acceptance evidence
None of this appears in your API calls. It’s why the saved-method flows are the only supported way to store a credential.
What you’re responsible for
ElasticPay can prove how a credential was stored; only you can prove what the customer agreed to. Before charging a stored method:
- capture the customer’s agreement to the charges you’ll make — amount or amount basis, frequency or trigger, and how to cancel
- keep that agreement; it’s your evidence in a dispute
- charge only within its terms, and stop when the customer cancels
- attach saved methods to a
customer_idso every charge is traceable to the person who consented
Where this shows up in the docs
| Flow | Guide |
|---|---|
| Establishing the credential | Save a Payment Method |
| One-off MIT | Charge a Saved Payment Method |
| Your own billing schedule | Recurring Without a Plan |
| Platform-managed billing | Recurring With a Payment Plan |
| Single future-dated charge | Scheduled Payments |