Card Integration Process (Recurring payments)
Recurring card payments (also referred to as tokenized card payments) are transactions initiated directly from a backend client, and usually don't involve any redirects to a hosted user interface. This model is typically used in cases where the user is not necessarily present for repeated transactions on a card, such as subscription, collection or one-click payments.
A RecurringPaymentConsentRequest
tracks a user's consent for their payment method to be tokenized and charged in the future, wheather or not they are present for subsequent transactions.
Authentication
All API requests require Client Authentication. The client_consentrequest
scope will be needed for tokenization.
Flow
1. Card collection and granting consent
Cards are tokenized by creating a RecurringPaymentConsentRequest
and moving it into a GRANTED
state.
This flow may be completed via
- Stitch-hosted UI. This is used when the client is not PCI-compliant and would like Stitch to tokenize the card details on their behalf.
- Secure API. This is used when the client has their own UI to collect card details and is already PCI-compliant.
The resulting token is the ID of a RecurringPaymentConsentRequest
(in GRANTED
state).
2. Initiating payments
The token collected above may be used to initiate payments directly with the Stitch API.