Skip to main content
On this page

Recurring Commerce separates the customer-approved setup from later merchant-initiated charges. A safe implementation preserves consent and credential lineage, distinguishes the initial customer interaction from subsequent charges, and gives operations teams a complete subscription and payment history.

Separate setup from recurring execution#

Sequence diagram
1Customer2Merchant3DEUNA4ProviderApprove terms and credential useTokenize through a supportedexperienceReturn a reusable referenceCreate the supported recurring chargeSubmit with configured recurringcontextReturn processing stateNotify or expose authoritative outcome
Merchant or customerDEUNAProvider or processor

The exact first-payment, token, network, authentication, merchant-initiated transaction, and retry requirements depend on the provider, market, method, and account configuration.

Operational requirements#

  • Record the customer, terms version, consent time, credential reference, and permitted use.
  • Keep credential status separate from subscription and individual charge status.
  • Apply a unique business reference and supported idempotency behavior to each scheduled charge.
  • Define retry eligibility, spacing, maximum attempts, customer communication, and cancellation rules before production.
  • Reconcile a timeout or unknown state against the original attempt before resubmitting.
  • Support credential expiry, replacement, revocation, customer deletion, plan change, pause, and cancellation.

For account-specific batch optimization of scheduled charges, see Acceptance Agent. It is an agreed file interface, not a public API contract.

Continue with Subscriptions, Payment Vault, and Reconciliations.