> 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/payment-methods/cards/stored-credentials/customer-initiated-transactions-cit.md). # Customer-Initiated Transactions (CIT) Process payments while the customer is actively present – and establish the consent that enables stored credentials. A Customer-Initiated Transaction (CIT) is a payment initiated while the customer is actively interacting with your checkout. The customer participates in the payment session – entering card details, selecting a saved payment method, or completing authentication. Within the Visa and Mastercard Stored Credential Framework, the CIT plays a central role: it is the transaction in which the customer provides consent to store their payment credentials, and the reference point for all future payments made with those credentials. Every Merchant-Initiated Transaction (MIT) must be preceded by a valid initial CIT. The SEB Ecommerce Payment Gateway supports CITs both for first-time payments and for payments using previously stored credentials, such as one-click checkout. ### Capability Summary
CapabilitySupport
Payment MethodsPayment Cards (Visa, Mastercard)
Initial CIT (credential setup)Supported – creates a stored credential (token)
Subsequent CIT (stored credential use)Supported – one-click payments with a saved card
AuthenticationEMV® 3-D Secure (EMV 3DS), frictionless and challenge flows
Strong Customer Authentication (SCA)Supported where required by regulation
Authorization TypesFinal authorization (Purchase) or Pre-authorization (Authorization + Capture)
TokenizationInternal (gateway) and network tokens (Visa TMS, Mastercard SCOF)
Integration OptionsMerchant API, Hosted Checkout
Status NotificationsCallback notifications (webhooks)
Sandbox TestingAvailable
Availability of individual capabilities depends on your merchant agreement, enabled services, and acquiring configuration. ### CIT Categories The Stored Credential Framework distinguishes two types of Customer-Initiated Transactions. #### Initial CIT – Storing the Credentials The initial CIT is the first payment in which the customer explicitly agrees that their payment credentials may be stored for future use. During this payment: * The customer actively provides their card details at checkout. * You are responsible for obtaining the customer's explicit consent to store the card credentials, for example by providing a "Save my card" option or accepting subscription terms. * The gateway securely stores the credentials using tokenization and returns the token ID to you in the payment response. * The transaction establishes the customer’s consent that all future Merchant-Initiated Transactions must reference. Typical examples include the first payment of a subscription, a purchase during which the customer saves their card for faster checkout, and the customer adding or updating a stored payment method. #### Subsequent CIT – Using the Stored Credentials A subsequent CIT is a payment in which the customer is actively present and uses previously stored credentials instead of re-entering card details. The most common example is a one-click payment: the returning customer selects a saved card and confirms the purchase. Because the customer participates in the session, a subsequent CIT can include EMV® 3-D Secure authentication where required. This distinguishes it from a Merchant-Initiated Transaction, which is processed without the customer’s involvement. {% hint style="info" %} The distinction matters for authentication, scheme flagging, and regulatory treatment. If the customer is present and actively confirms the payment, it is a CIT – even when a stored credential is used. If the payment is triggered by your systems without the customer’s participation, it is an MIT. See [Merchant-Initiated Transactions (MIT)](/payment-methods/cards/stored-credentials/merchant-initiated-transactions-mit.md) for details. {% endhint %} ### Payment Flow – Initial CIT A typical initial CIT that establishes a stored credential follows these steps: 1. Create the payment. You initiate a new payment via the Merchant API, providing the amount, currency, shopping cart details, and other required payment information. 2. Customer checkout. The customer enters their card details using Hosted Checkout or your Merchant API integration. Sensitive card data is handled exclusively by the gateway and is not exposed to your systems. 3. Customer consent. The customer explicitly agrees that their payment credentials may be stored for future use. 4. Authentication. The gateway initiates the EMV® 3DS flow where required. Depending on the issuer’s decision, the customer completes a frictionless or challenge authentication. 5. Authorization. The payment is authorized as a final authorization (Purchase) or a pre-authorization, depending on your configuration. 6. Token creation. The gateway stores the credentials in its PCI DSS compliant token vault and returns the token ID to you together with the other payment details. If configured, a callback notification informs your systems of the payment status. Store the returned token ID against the customer profile in your systems. It is the reference you will use for all subsequent CIT and MIT payments with this credential. {% hint style="info" %} If the initial CIT is declined or abandoned, no valid consent is established and no stored credential should be used. Merchant-Initiated Transactions may only follow a successful initial CIT. {% endhint %} ### Payment Flow – Subsequent CIT (One-Click) A payment with a previously stored credential, while the customer is present, follows these steps: 1. Customer selects a saved card. The returning customer selects a saved payment method at checkout. 2. Create the payment. You initiate the payment referencing the stored token ID instead of card data. 3. Authentication. Where required, the customer completes EMV® 3DS authentication. Many subsequent CITs proceed through the frictionless flow, based on the issuer’s risk assessment and applicable exemptions. 4. Authorization. The gateway resolves the token and processes the transaction through the standard authorization, capture, reversal, and refund flows. For implementation details, see [One-Click Payments](/payment-methods/cards/stored-credentials/one-click-payments.md). ### Authentication and SCA Because the customer is present during a CIT, authentication can be performed when it is required. * Initial CIT. Storing payment credentials is subject to Strong Customer Authentication (SCA) under PSD2. The initial CIT is therefore typically authenticated with EMV® 3DS, and the authentication also covers the setup of the stored credential. * Subsequent CIT. SCA applies unless an exemption is available – for example, low-value transactions or Transaction Risk Analysis (TRA). The issuer makes the final decision and may enforce a challenge or approve the payment through the frictionless flow. Successful EMV® 3DS authentication may also provide a liability shift for fraud-related chargebacks, in accordance with card scheme rules. See EMV® 3-D Secure (EMV 3DS) for details. ### Customer Consent Before storing payment credentials during an initial CIT, you must obtain the customer’s explicit consent. The consent should clearly describe: * The purpose of storing the payment credentials. * The payment frequency, where applicable. * The amount or billing model. * The cancellation process. * Your Terms and Conditions. Consent must be an active choice – for example, an unticked checkbox the customer selects – and you are responsible for retaining evidence of the consent. The stored consent is referenced by all future Merchant-Initiated Transactions. ### CIT vs. MIT at a Glance
AspectCustomer-Initiated Transactions (CIT)Merchant-Initiated Transaction (MIT)
Customer presentYes – the customer actively participates in the payment sessionNo – the payment is triggered by the merchant’s systems
Typical examplesFirst subscription payment, one-click checkout, updating a stored cardMonthly subscription charge, usage-based billing, delayed charge
AuthenticationEMV® 3DS where required; SCA with possible exemptionsNo customer authentication; 3DS Requestor-Initiated (3RI) where applicable
ConsentEstablishes or confirms consentMust reference the consent established during the initial CIT
PrerequisiteNoneA successful initial CIT with stored credentials
### Scheme Compliance and Transaction Flagging The gateway supports the Visa and Mastercard Stored Credential Framework. Transactions are identified to the card schemes with the appropriate stored credential indicators – distinguishing the initial storage of credentials from their subsequent use, and customer-initiated from merchant-initiated payments. Correct classification matters: it affects the issuer’s authorization decision, approval rates, liability, and compliance with card scheme rules. Always initiate payments using the payment type that matches the actual scenario – do not process a merchant-triggered charge as a CIT, or vice versa. In the Merchant Portal, the transaction detail view indicates whether a transaction represents an initial Customer-Initiated Transaction (CIT) or a Merchant-Initiated Transaction (MIT), supporting reconciliation and operational follow-up. ### Merchant Best Practices We recommend that merchants: * Obtain explicit, active customer consent before storing payment credentials, and retain evidence of the consent. * Clearly communicate what the customer is agreeing to – billing model, frequency, amounts, and how to cancel. * Store the token ID returned by the initial CIT and use it for all subsequent payments with that credential. * Use the correct transaction type: CIT when the customer is present, MIT when the payment is triggered by your systems. * Handle declined or abandoned initial CITs correctly – do not initiate MITs without a successful initial CIT. * Allow customers to view, update, and delete their saved payment methods. * Update your order status based on the confirmed payment status returned by the gateway. ### Testing Complete all development and validation in the Sandbox environment before processing live transactions. Before requesting Production activation, verify: * An initial CIT with the customer consent step, including successful token creation. * The token ID is received in the payment response and stored correctly in your systems. * A subsequent CIT (one-click payment) using the stored token. * EMV® 3DS frictionless and challenge scenarios. * Declined and abandoned payment scenarios, and that no stored credential is used after a failed initial CIT. * Callback or webhook notifications and order status updates. ### Frequently Asked Questions #### Does the customer need to complete 3-D Secure on every CIT? Not necessarily. The initial CIT that stores credentials is typically authenticated with SCA. Subsequent CITs may qualify for exemptions or proceed through the frictionless flow, depending on the issuer’s risk assessment and applicable regulations. The gateway initiates the 3DS flow whenever it is required. #### Can I charge a customer later without a new CIT? Yes – that is a Merchant-Initiated Transaction (MIT). It requires a successful initial CIT in which the customer consented to storing their credentials, and each MIT must reference that consent. See Merchant-Initiated Transactions (MIT). #### What happens if the initial CIT fails? No stored credential relationship is established. The customer can retry the payment or select another payment method. Do not initiate merchant-initiated payments until an initial CIT has completed successfully. #### Is a one-click payment a CIT or an MIT? A one-click payment is a Customer-Initiated Transaction: the customer is present, selects the saved payment method, and confirms the purchase, completing authentication where required. #### Can the customer change the payment method during a CIT? Yes. If a payment attempt is unsuccessful, the customer can retry the same payment method or select any other available payment method until the payment is completed. Note that after a pre-authorization has been placed, the payment method can no longer be changed. ### Related Documentation Continue with the following topics: * [Stored Credentials](/payment-methods/cards/stored-credentials.md) * [EMV® 3-D Secure](/payment-methods/cards/emv-r-3-d-secure-emv-3ds.md) (EMV 3DS) * [Tokenization](/payment-methods/cards/tokenization.md) * [One-Click Payments](/payment-methods/cards/stored-credentials/one-click-payments.md) * [Merchant-Initiated Transactions](/payment-methods/cards/stored-credentials/merchant-initiated-transactions-mit.md) (MIT) * [Strong Customer Authentication (SCA)](/compliance/strong-customer-authentication-sca.md) * [Merchant API](/integration/merchant-api.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/payment-methods/cards/stored-credentials/customer-initiated-transactions-cit.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.