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.
CVV is always required for initial payments. This is a card network requirement that cannot be bypassed.
Initial payments include:
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.
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.
No need to collect CVV for returning customers
Supports 3DS challenges for added security
Does not require a reference to the original payment
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
Merchant Initiated Transactions (MIT)
Use Merchant Initiated Transactions when the customer is not involved in the transaction flow.
Automated charges don’t need CVV
Cannot trigger 3DS challenges
Must reference the original payment
Fully automated, no customer interaction
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
Quick Comparison
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.
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:
For more details on 3DS verification, see How to Interpret 3DS 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
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.
Zero authorization is considered an initial payment (not a subsequent transaction) because the customer is present and must provide their CVV.
