> For the complete documentation index, see [llms.txt](https://docs.ecommerce.seb.ee/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ecommerce.seb.ee/features/recurring-payments-and-subscriptions.md). # Recurring Payments & Subscriptions Charge your customers automatically – subscriptions, memberships, usage-based billing. The gateway executes every payment securely; your systems decide when and how much. The SEB Ecommerce Payment Gateway supports recurring and subscription-based payment processing: the secure setup of the payment relationship, the storage of credentials, and the execution of every charge – initial and subsequent – with the authentication and compliance handling built in. One thing to understand up front: the gateway is a payment execution engine, not a billing platform. Billing plans, invoicing, customer communication, dunning strategy, and subscription business logic remain in your systems – the gateway executes the charges your systems initiate and tells you, in real time, what happened. This division keeps you in full control of your subscription model while the gateway carries the payment security and compliance load. *** ### What the Gateway Provides * Secure processing of the initial transaction, including Strong Customer Authentication (SCA) where required – the payment that establishes the customer’s consent. * Generation and management of secure payment tokens in accordance with PCI DSS – no card data in your systems. * Execution of Merchant-Initiated Transactions (MITs) using stored credentials, including 3DS Requestor-Initiated (3RI) authentication where applicable. * Recurring transaction execution via the Merchant API. * Account-based recurring payments, where supported by the customer’s bank and the applicable mandate model. * Real-time status handling and callback notifications, so your systems can manage retries and subscription state. * Visibility of every subscription transaction in the Merchant Portal, with CIT/MIT indication. What stays with you: scheduling (the gateway does not independently schedule payments – your systems call the API when a charge is due), billing plans and proration, invoicing, customer notifications, retry and dunning strategy, and cancellation handling. The full split is described in [Merchant-Initiated Transactions › Division of Responsibilities](/payment-methods/cards/stored-credentials/merchant-initiated-transactions-mit.md). *** ### How a Subscription Works End to End 1. Signup – the initial CIT. The customer subscribes and pays the first charge as a regular Customer-Initiated Transaction, explicitly agreeing to recurring billing – amount or billing model, frequency, and how to cancel. SCA applies. See [Customer-Initiated Transactions (CIT)](/payment-methods/cards/stored-credentials/customer-initiated-transactions-cit.md). 2. The credential is stored. The gateway stores the credentials in its token vault and returns a token ID – your subscription record now holds the key to future charges. See [Tokenization](/payment-methods/cards/tokenization.md). 3. Your scheduler triggers each charge. When a renewal is due, your billing logic initiates the charge via the Merchant API as a Merchant-Initiated Transaction referencing the token – no customer interaction. See [Merchant-Initiated Transactions (MIT)](/payment-methods/cards/stored-credentials/merchant-initiated-transactions-mit.md). 4. You react to the outcome. The result arrives in the API response and via callback notifications. Successful – extend the subscription; declined – your retry and dunning logic takes over. See [Webhook Notifications](/integration/merchant-api/webhooks.md) and [Payment Statuses](/payment-methods/cards/payment-statuses.md). 5. The credential maintains itself. With network tokenization, reissued and renewed cards update automatically – subscriptions survive card replacement without asking the customer for new details. Token status notifications tell you when a stored credential needs the customer’s attention. *** ### Which Payment Methods Support Recurring
Payment MethodRecurring SupportNotes
Cards (Visa, Mastercard)FullMIT with 3RI where applicable; network token auto-updates reduce involuntary churn
Apple Pay/Google PaySupportedStored-credential scenarios work as for regular cards, subject to your configuration – see the wallet pages
Pay by Bank (A2A)Where supportedAccount-based recurring depends on the customer’s bank and the applicable mandate model – contact your SEB representative
PayPalNot currentlyPayPal payments are processed as customer-initiated payments through the PayPal checkout flow
*** ### Keeping Subscriptions Alive Most subscription revenue is lost not to cancellations but to payment failures. Three platform capabilities work against that: * Automatic credential updates. Card reissuance and expiry updates are applied to stored tokens automatically by the card schemes – the charge that would have failed on a stale card succeeds instead. * Token status notifications. A suspended or deactivated token triggers a notification before the next renewal fails silently – pause charging and ask the customer to update their payment method. * Real-time outcomes. Every decline reaches your systems in real time with the payment status, giving your retry and dunning logic accurate triggers instead of guesswork. *** ### Compliance Essentials * Obtain explicit consent to recurring billing during the initial CIT – an active choice, with the billing model, frequency, amounts, and cancellation process clearly described – and retain evidence of it. Every recurring charge references this consent. * Notify customers before recurring charges where required by applicable regulations or card scheme rules. * Keep charges within the scope of the consent – amounts, frequency, and conditions the customer agreed to. * Provide a simple cancellation path, and stop charging immediately when the customer cancels. *** ### Where to Start 1. Read [Stored Credentials](/payment-methods/cards/stored-credentials.md) – the framework: how consent, tokens, CIT, and MIT fit together. 2. Implement the signup payment with the consent step and token storage – [Customer-Initiated Transactions (CIT)](/payment-methods/cards/stored-credentials/customer-initiated-transactions-cit.md). 3. Implement the renewal charge and wire your scheduler to the Merchant API – [Merchant-Initiated Transactions (MIT)](/payment-methods/cards/stored-credentials/merchant-initiated-transactions-mit.md). 4. Close the operational loop – process callbacks, handle declines and token notifications, and test the full journey in the [Sandbox](/guides/sandbox.md). *** ### Related Documentation * [Stored Credentials](/payment-methods/cards/stored-credentials.md) * [Customer-Initiated Transactions (CIT)](/payment-methods/cards/stored-credentials/customer-initiated-transactions-cit.md) * [Merchant-Initiated Transactions (MIT)](/payment-methods/cards/stored-credentials/merchant-initiated-transactions-mit.md) * [Tokenization](/payment-methods/cards/tokenization.md) * [Callback Notifications](/integration/merchant-api/webhooks.md) * [Payment Statuses](/payment-methods/cards/payment-statuses.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.ecommerce.seb.ee/features/recurring-payments-and-subscriptions.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.