> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.coinflow.cash/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.coinflow.cash/_mcp/server. # Subsequent Transactions > Understanding the difference between initial payments and subsequent transactions This section covers how to process transactions after a customer has initially saved their card. Understanding the distinction between initial payments and subsequent transactions is critical for compliance and optimal approval rates. --- ## Initial Payments An initial payment is any transaction where the cardholder is actively present and entering their card details or confirming a saved card. > **Info** > > **CVV is always required** for initial payments. This is a card network requirement that cannot be bypassed. Initial payments include: | Type | Description | | ------------------------------ | ------------------------------------------------------------- | | **\$0.00 Authorization** | A zero-dollar auth to validate and save a card for future use | | **Purchase with a new card** | Customer enters card details for the first time | | **Purchase with a saved card** | Customer selects a saved card and confirms the transaction | > **Success** > > **Prebuilt UI Supported** > > All initial payment types are fully supported by Coinflow's prebuilt UI components. No custom API integration required. --- ## Subsequent Transactions Subsequent transactions occur **after** an initial payment has been made. These are charges against a card that was previously saved during an initial payment. > **Warning** > > **API Only** > > Subsequent transactions are **not supported** by Coinflow's prebuilt UI. You must use the API directly to process these transactions. There are two types of subsequent transactions: ### Card on File (Customer Initiated) Use Card on File transactions when the **customer is actively involved** in the transaction flow. #### CVV Not Required No need to collect CVV for returning customers #### 3DS Eligible Supports 3DS challenges for added security #### No Reference Required Does not require a reference to the original payment #### Customer Present Customer is actively initiating the transaction **Common Use Cases:** * Customer-initiated billing * Repeat purchases where customer clicks "buy" * One-click reorder functionality [Learn more about Card on File transactions](/guides/checkout/payment-scenarios/subsequent-transactions/card-on-file) > **Info** > > **Apple Pay Support** > > Card on File transactions are also supported for Apple Pay — charge a customer's saved Apple Pay card without re-presenting the Apple Pay sheet. See [Apple Pay Subsequent Transactions](/guides/checkout/payment-scenarios/subsequent-transactions/apple-pay). --- ### Merchant Initiated Transactions (MIT) Use Merchant Initiated Transactions when the **customer is not involved** in the transaction flow. #### CVV Not Required Automated charges don't need CVV #### 3DS Not Eligible Cannot trigger 3DS challenges #### Reference Required Must reference the original payment #### Customer Not Present Fully automated, no customer interaction > **Warning** > > **Original Payment Reference Required** > > MIT transactions **must** include a reference to the original payment where the customer entered their CVV and completed any 3DS authentication. This proves the customer authorized future charges. **Common Use Cases:** * Automated subscription renewals * Recurring billing cycles * Scheduled payment plans [Learn more about Merchant Initiated Transactions](/guides/checkout/payment-scenarios/subsequent-transactions/merchant-initiated-transactions) --- ## Quick Comparison | Feature | Card on File (CIT) | Merchant Initiated (MIT) | | -------------------------- | :-------------------------: | :------------------------: | | CVV Required | No | No | | Customer Present | Yes | No | | Original Payment Reference | Not Required | **Required** | | 3DS Eligible | Yes | No | | Typical Use Case | Customer clicks "buy again" | Automated recurring charge | --- ## 3DS Authentication Card on File transactions support 3DS (3D Secure) authentication, which can trigger a challenge for the customer to verify their identity. This provides liability shift protection for the merchant. > **Info** > > **Handling 3DS Challenges** > > Since Card on File transactions are eligible for 3DS, you need to implement challenge handling in your application. See our recipes for implementation guides: > > * [Complete Checkout with 3DS Challenge (React)](/recipes/recipes/complete-checkout-with-3-ds-challenge-react) > * [Add 3DS Challenge (Angular)](/recipes/recipes/add-3-ds-challenge-angular) > > For more details on 3DS verification, see [How to Interpret 3DS Verified Transactions](/guides/checkout/payment-security-risk-management/fraud-protection/3-ds/how-to-interpret-3-ds-verified-transactions). Merchant Initiated Transactions are **not eligible for 3DS** because the customer is not present to complete the challenge. The original authorization (with any required 3DS) must have already occurred. --- ## Velocity Limits > **Tip** > > **Independent Configuration** > > Velocity limits for Card on File and Merchant Initiated Transactions are **configurable independently**. This allows you to set appropriate limits based on your specific use case and risk tolerance for each transaction type. > > Contact support to adjust your velocity limits. --- ## Zero Authorization Zero authorization (\$0.00 auth) is a method to validate and save a card without charging the customer. This is commonly used as the **initial payment** before subsequent Card on File or Merchant Initiated Transactions. > **Info** > > Zero authorization is considered an **initial payment** (not a subsequent transaction) because the customer is present and must provide their CVV. [Learn more about Zero Authorization](/guides/checkout/payment-scenarios/subsequent-transactions/zero-authorization)