π± Apple Pay Subsequent Transactions
π± Apple Pay Subsequent Transactions
Learn how to charge a customerβs saved Apple Pay card for subsequent purchases without re-presenting the Apple Pay sheet.
Overview
Coinflow supports Card on File (COF) transactions for Apple Pay. Once a customer completes an initial Apple Pay purchase, Coinflow securely saves their Apple Pay card so you can process subsequent, customer-initiated purchases without showing the Apple Pay sheet again β no re-authentication with Face ID or Touch ID required.
This uses the same Card on File Checkout endpoint as regular card payments. Coinflow automatically detects that the original payment was made with Apple Pay β no additional parameters are required.
Customer Initiated Only
Apple Pay subsequent transactions are supported for Card on File (Customer Initiated) transactions only. Merchant Initiated Transactions (MIT) β such as automated subscription renewals β are not supported with Apple Pay. The customer must be present and actively confirming each purchase.
How Apple Pay Cards Are Saved
When Card on File is enabled on your merchant account, every successful Apple Pay checkout automatically saves the customerβs card:
Customer Pays with Apple Pay
The customer completes a purchase through the Apple Pay sheet, authenticating with Face ID or Touch ID.
Coinflow Saves the Card
Coinflow tokenizes the card behind the Apple Pay payment and stores it securely in Coinflowβs PCI-compliant vault, attached to the customerβs profile.
Card Appears on the Customer Profile
The saved card is returned in the mobiles array of the Get Customer response, including a display alias (e.g. βVisa 1234β), the card token, and expiration details.
No Extra Integration Work for Saving
Card saving happens automatically on every successful Apple Pay purchase when Card on File is enabled β there is no separate βsave cardβ call.
Prerequisites
Before processing Apple Pay subsequent transactions, make sure:
- Apple Pay is implemented β See Implement Apple Pay
- Card on File is enabled on your merchant account β contact your Coinflow integration representative to enable it and configure your velocity limits
- An initial Apple Pay purchase is complete β you need either the
paymentIdfrom that purchase or the saved cardtokenfrom the customer profile
Processing Configuration
Apple Pay Card on File is not available on every processing configuration. If your requests return 403 - Card on file not available, contact your Coinflow integration representative.
Implementation Guide
Step 1: Complete the Initial Apple Pay Purchase
The customerβs first purchase must go through the standard Apple Pay flow, where they authenticate on their device. After a successful purchase, save either of the following identifiers:
- The
paymentIdfrom the checkout response or webhook - The card
tokenfrom themobilesarray on the Get Customer response
Step 2 (Optional): Verify the Card Is Authorized
Before starting a session that depends on subsequent transactions (for example, an auction or a tab), confirm the saved card can still be charged:
If authorized is false, direct the customer through a fresh Apple Pay purchase to create a new original payment reference.
Step 3: Process the Subsequent Transaction
Call the Card on File Checkout endpoint with either the original Apple Pay paymentId or the saved card token:
View Card on File Checkout API Reference
Using the Original Payment ID:
Using the Card Token:
Response:
Example Values
The IDs, tokens, and amounts above are examples only and do not reflect real production values. Use the identifiers returned by your own checkout responses, webhooks, and customer profiles.
Original Payment Must Be Apple Pay
The originalPaymentId must reference a successful Apple Pay purchase, and a token must belong to a saved Apple Pay card. You cannot mix payment sources β referencing a regular card payment for an Apple Pay saved card (or vice versa) returns a 400 error.
Step 4: Handle Chargeback Protection (If Enabled)
If chargeback protection is enabled on your account, include the Coinflow device ID header and chargebackProtectionData in the request, exactly as with regular Card on File transactions.
Handling Expired References (410 Errors)
Every integration must handle 410 responses
A 410 Gone response means the original Apple Pay payment can no longer be used as a Card on File reference. Unlike regular card payments, there is no CVV re-entry fallback for Apple Pay β the only way to recover is for the customer to complete a new purchase through the Apple Pay sheet, which creates a fresh original payment reference.
A 410 is returned when any of your Card on File velocity limits are hit:
Recommended flow:
Avoid 410s Mid-Session
Call POST /checkout/card-on-file-authorized before starting a session that depends on subsequent transactions (an auction, a tab, a table). It runs the same velocity checks with a zero-amount total, so you can route the customer through a fresh Apple Pay purchase before they are mid-session rather than failing at charge time.
Differences from Regular Card on File
Velocity limits (maxCount, period, maxMultiple, expiration) are shared with your regular Card on File configuration.
Error Handling
403 Forbidden - Card on File Not Enabled
Error Message:
Cause: Card on File is not enabled or not configured on your merchant account.
Resolution: Contact your Coinflow integration representative to enable Card on File.
403 Forbidden - Card on File Not Available
Error Message:
Cause: Your processing configuration does not support Apple Pay Card on File.
Resolution: Contact your Coinflow integration representative.
400 Bad Request - Different Payment Source
Error Message:
Cause: The originalPaymentId references a payment made with a different payment source β for example, a regular card payment when charging a saved Apple Pay card, or a mobile wallet other than Apple Pay.
Resolution:
- Only reference an original payment made with Apple Pay
- Google Pay payments cannot be used for subsequent transactions
400 Bad Request - Chained Card on File Payment
Error Message:
Cause: The originalPaymentId references a Card on File payment rather than the original Apple Pay purchase.
Resolution: Always reference the initial Apple Pay purchase β do not chain Card on File transactions.
410 Gone - Velocity Limit Errors
The original payment reference can no longer be used β a velocity limit was hit or the reference window expired. See Handling Expired References above for the recovery flow, and the Card on File error reference for the exact error messages.
Frequently Asked Questions
Does the customer need to re-authenticate with Face ID or Touch ID?
No. Subsequent transactions run against the saved card without presenting the Apple Pay sheet. The customerβs on-device authentication from the original purchase serves as the cardholder verification.
Is Google Pay supported?
No. Subsequent transactions are currently supported for Apple Pay only. Google Pay customers must authenticate through the Google Pay flow for every purchase.
Can I use a saved Apple Pay card for subscriptions or other Merchant Initiated Transactions?
No. Apple Pay saved cards support Customer Initiated (Card on File) transactions only β the customer must actively confirm each purchase in your application.
How do I show the customer which card will be charged?
Use the mobiles array on the Get Customer
response. Each saved Apple Pay card includes an alias (the cardβs display
name from Apple Pay, e.g. βVisa 1234β) you can show at confirmation.

