--- title: "Payment methods & consent" description: "Subscriptions only support card payment methods. This page explains how recurring-charge consent works and how a consumer updates the card on an existing..." source: "https://docs.tokenz.one/en/v2/subscriptions/payment-methods" api_version: "v2" locale: "en" version_status: "current" docs_stage: "prod" --- # Payment methods & consent Subscriptions only support card payment methods. This page explains how recurring-charge consent works and how a consumer updates the card on an existing subscription. ## Why consent matters Renewal charges are billed automatically, without the consumer present to enter a card or complete a challenge. To do this safely, Tokenz uses **merchant-initiated transaction (MIT) consent**: when a consumer first provides a card for a subscription, Tokenz records their permission to charge that card again in the future. Every subsequent renewal and dunning retry is charged as an MIT using this stored consent — the consumer is not asked to re-enter their card or pass a 3D Secure (3DS) challenge on every cycle. Consent is captured automatically by the Tokenz-hosted flow the first time a card is attached to a subscription: - **No trial**: Consent is captured as part of the initial checkout payment. - **Trial period**: Consent is captured when the consumer starts the trial, since there's no initial charge to piggyback on. - **Updating the card later**: Consent is captured again for the new card, following the same flow described below. ## Updating the payment method A consumer can update their card at any point while the subscription is trialing, active, or unpaid — for example, when their card is about to expire, or to recover from a declined renewal. This is done by directing the consumer to Tokenz's hosted payment method update flow for that subscription, the same way they're directed to the hosted checkout page when the subscription is first created. The flow: 1. The consumer is redirected to the hosted flow for their subscription. 2. They enter their new card. If the issuer requires it, they complete a 3D Secure challenge. 3. Tokenz captures a new consent record for the card. 4. If consent is **granted**, the subscription's payment method is swapped to the new card immediately. If it's **denied**, the existing card stays in place and nothing changes. 5. Tokenz notifies your backend with a `subscription.payment_method_updated` webhook once the update is confirmed. ```mermaid sequenceDiagram; autonumber; participant C as Consumer; participant TC as Tokenz-hosted Payment Flow; participant T as Tokenz API; participant I as Card Issuer; participant W as Merchant Webhook Handler; C->>TC: Enter new card details; TC->>I: Request MIT consent (may require 3D Secure); alt Consent granted I-->>TC: Consent granted; TC->>T: Update subscription payment method; T->>W: webhook: subscription.payment_method_updated; else Consent denied I-->>TC: Consent denied; TC->>TC: Existing payment method stays unchanged; end ``` ## Using a saved payment method If the consumer already has a saved, previously-consented payment method on file (for example from an earlier subscription or purchase), the hosted flow lets them reuse it directly instead of entering card details again, skipping a new consent step entirely. ## Recovering from a declined renewal When a renewal charge fails, the subscription moves to `unpaid` and Tokenz emails the consumer a recovery checkout link (see [Lifecycle & billing](https://docs.tokenz.one/en/v2/subscriptions/lifecycle#dunning-(failed-payment-recovery))). The consumer can either let the existing card retry automatically, or use the recovery checkout session to provide a new card, which updates the subscription's payment method and immediately attempts to pay the unpaid order.