> ## Documentation Index > Fetch the complete documentation index at: https://docs.dintero.com/llms.txt > Use this file to discover all available pages before exploring further. # Set up recurring payments > Charge customers on a recurring basis using tokenized cards. Collect payment details once, then bill automatically for memberships, SaaS, or any repeating service. Sell memberships, subscriptions, or any service that bills on a schedule. The customer pays once through a normal checkout, Dintero tokenizes their card, and you use the token to charge them again without requiring another checkout. You manage the billing schedule on your server. Dintero handles the secure card storage and recurring charges. ```mermaid theme={null} sequenceDiagram participant Merchant as Your server participant API as Dintero API participant Checkout as Checkout page participant Customer as Customer Merchant->>API: Create session (request token) API->>Checkout: Display checkout Customer->>Checkout: Enter card details & pay Checkout->>API: Payment authorized + token created API->>Merchant: Callback with transaction + token Note over Merchant,API: Recurring charge (days/weeks/months later) Merchant->>API: Create session with stored token API-->>API: Charge card (no customer interaction) API->>Merchant: Callback with transaction status ``` ## Integration steps Contact your Dintero account manager to enable card tokenization on your account. This is required before you can store card details for future use. Create a checkout session with `generate_payment_token: true` or `generate_recurrence_token: true`, depending on your payment provider and token type. The customer goes through the normal checkout flow, entering card details and completing the first payment. On success, Dintero returns a **recurrence token** or **payment token** alongside the transaction. The token type depends on your payment provider. See [Create a token](/docs/checkout/tokenization-create-token) for the session configuration. Save the token ID on your server, associated with the customer. This token represents the customer's stored card and is used for all future charges. See [Fetch and store tokens](/docs/checkout/tokenization-fetching-storing) for how to retrieve tokens from the transaction. Tokens are sensitive credentials. Store them securely on your server. Never expose them to the client. When a billing cycle is due, create a new checkout session with the stored token. The payment is processed server-to-server. The customer does not need to interact with a checkout page. If the charge fails (e.g., expired card, insufficient funds), you can notify the customer and prompt them to update their payment method through a new checkout session. See [Use a stored token](/docs/checkout/tokenization-use-token) for the recurring charge payload. Subscription changes are managed on your server. To change the billing amount, adjust the `order.amount` in the next recurring session. To cancel, stop creating new sessions. See the [Subscription example](/docs/checkout/subscription-example) for a complete walkthrough with tiered memberships. ## Token types | Token type | Provider | Use case | | --------------------- | ---------------------------------- | ----------------------------------------------------------------- | | **recurrence\_token** | Swedbank Pay | Merchant-initiated recurring charges without customer interaction | | **payment\_token** | Swedbank Pay, Bambora, Dintero PSP | One-click payments and stored card charges | ## What's next How card tokenization works, supported providers, and token types. Configure the first session to request a token. Charge a customer using their saved token. End-to-end example with tiered memberships and upgrades.