Card on File (COF) Guide

Last updated:August 7, 2026

Card on File (COF) framework allows merchants to create a COF agreement with the cardholder during the initial payment (CIT), when he is present, and securely store his credit or debit card. Reference to this COF agreement in all the future merchant initiated (MIT) payments, is very important for the Issuer bank of the cardholder to validate the future payment requets as sanctioned by the cardholder, even though are initiated by the merchant without active cardholder presence.

Our Card on File framework consists of three types of COF agreements

CIT agreements

CIT agreement implies, that the cardholder is storing his card only for his own convenience of initiating payment by himself, as a single click payment later, without a need of entering his card data every time he visists the merchant's app or website.

MIT agreements

MIT agreement implies, that the cardholder has authorized the merchant to initiate multiple future payments on his behalf, based on a predefined recurring or unscheduled basis for a fixed or variable amount.

Industry Practice MIT agreements

Industry Practice MIT agreement is a type of agreement, where cardholder allows merchant to initiate a once-off payment later, when carholder will be off-session.

The Card on File agreement, a simple journey
Agreement starts
Cardholder-present CIT / INITIAL
→
Scheme ID returned
Stored for future use
→
Repeated charges
MIT/CIT · REPEATED, references Scheme ID
To consider
  • Store the Scheme ID from the initial CIT in your systems to support acquirer migrations and cross-connector continuity.

Use cases

One-click agreement

The merchant collects card data from the shopper during a cardholder-present purchase and stores it for future one-click payments. Every later purchase is still cardholder-initiated, so each one-click charge is sent the same way as the first, just switching standingInstruction.mode to REPEATED.

Use case: Anna stores her card at marketplace for quick purchases in future. When time comes, she makes an order and pays for it in a single click choosing the card she stored.

How it works

1

Store the payment data

Tokenize the card during the initial, cardholder-present purchase.

2

Send the payment

Use the stored registration for every later cardholder-initiated payment.

Optional
3

Review the agreement

Query the registration to confirm the stored one-click agreement.

Transactions created
RGCard registered
→
CIT · INITIALFirst payment
→
CIT · REPEATEDOne-click payment
Cardholder creates agreement (CIT · INITIAL)

		
Cardholder pays with stored card (CIT · REPEATED)

		

	


	

		
1. Store the payment data

		
Collect the customer payment information via COPYandPAY or Server-to-Server, adding the standingInstruction parameters that mark this as the initial leg of a CIT agreement.

		
Sample request:

		


		

			
What this creates

			
The response returns a registrationId. Carry that id into every future one-click request below, it is what links each payment back to this shopper's stored card.

		

	


	

		
2. Send the payment

		
When the customer checks out with One-Click, all you need to do is send a server-to-server request for a new payment with the respective registration.id (token) for which you want to make the payment. You can do this by sending a POST request to the /v1/registrations/{registration.id}/payments endpoint.

		
Sample request:

		

	


	

		
3. Review the agreement

		
Query the registration to confirm the stored card and the standing-instruction parameters used to create it.

		
Sample request:

		


		

			
See also

			
Walk through this flow step by step in the Integration guide or the Server-to-server guide.

		

	










	Section 1 of 2
	↑ Top
	Next: API Reference →




API Reference


The standingInstruction.* parameters below apply across all three use cases above.




    
    
ParameterDescriptionFormatRequired

    
    
    

        standingInstruction.type
        The category of the transaction.
            
    
				
  • RECURRING: Recurring Transactions are transactions that are processed on a regular fixed interval for a pre-agreed or advised amount, where applicable. Recurring Transactions don't have a fixed duration and will continue to be processed until the cardholder cancels the agreement.
    • 
				
  • INSTALLMENT: Installment Payments are transactions that are processed on a regular fixed interval for a pre-agreed amount for a single purchase of good or services. Unlike Recurring Transactions, Installment Payments do have a fixed duration and shouldn't continue to be processed after the end of the agreed installment period.
    • 
                
  • UNSCHEDULED: An unscheduled credential-on-file transaction is like a recurring transaction but differs in that it does not happen at pre-agreed intervals. The classic example of such a transaction is when it is triggered by an event such as an amount threshold to ensure that a pay-as-you-go account always has a minimum available reserve.
    • 
            

        		
        UNSCHEDULED|
INSTALLMENT|
RECURRING		
        Conditional
    

 

        standingInstruction.recurringType
        Indicates the type of a recurring MIT agreement.
            
    
				
  • STANDING_ORDER: value has to be provided in case the consumer agrees to store the credential-on-file and initiates the first transaction in a series intended to be for a variable amount and a fixed frequency. Example: The initial transaction to store the credential-on-file for a monthly utility payment.
    • 
				
  • SUBSCRIPTION: value has to be provided in case the consumer agrees to store the credential-on-file and initiates the first transaction in a series intended to be for a fixed amount and a fixed frequency. Example: The initial transaction to store the credential-on-file for a  monthly newspaper subscription.

				Note - This value is conditional, it is required for:


			
    
				
  • All Mastercard CIT and MIT
    • 
                
  • Visa Recurring transactions executed with cards issued in India
    • 

            

        		
        STANDING_ORDER|
SUBSCRIPTION		
        Conditional
    

	

        standingInstruction.mode
        Indicating the mode of subsequent payment transaction.
            
    
                
  • INITIAL: The payment is the first of a series of payments. This first payment must contain additional data like the CVV code or 3D parameters to enable an initial authentication of the request.
    • 
                
  • REPEATED: The payment is a subsequent payment. It may not contain shopper authentication data like the CVV code or 3D parameters - the shopper is not present anymore.
    • 
            

        		
        INITIAL|
REPEATED		
        Conditional
    

	

        standingInstruction.source
        Indicating the type of subsequent payment transaction.
            
    
                
  • CIT: Cardholder initiated transaction.
    • 
                
  • MIT: Merchant initiated transaction.
    • 
            

        		
        CIT|
MIT		
        Conditional
    

	    

        standingInstruction.initialTransactionId
        The field represents the reference ID generated by the scheme (in some integrations, the processor provides its own internal ID instead of the scheme value) for the transaction, and is returned by the processor/acquirer as part of the CIT transaction response.
        
The ID is received in one of below OPP response fields, depending on the integration (refer to respective Connector Integration sheet):
    
                
  • 'standingInstruction.initialTransactionId'
    • 
                
  • 'resultDetails.CardholderInitiatedTransactionID'
    • 
            

The field is required in the MIT transactions, when the card isn't tokenized by our platform.		
        AN or N
(No specific format-
Depends on acquirer)		
        Conditional
    

	

        standingInstruction.industryPractice
        The MIT types defined under this category are performed to fulfill a business practice as a follow-up to an original cardholder-merchant interaction that could not be completed with one single transaction.
            
    
                
  • INCREMENTAL_AUTH: Incremental authorizations can be used to increase the total amount authorized. Incremental authorizations do not replace the original authorization — they are additional to previously authorized amounts — the sum of all linked estimated and incremental authorizations represent the total amount on hold in the cardholder's account for a given transaction.
    • 
                
  • RESUBMISSION: When a merchant attempts to authorize a transaction after the service has been used but the issuer declines it for insufficient funds, they may attempt to re-authorize to recover the debt. These authorization requests are considered resubmission authorizations and must carry the new "re submission" indicator.
    • 
				
  • REAUTHORIZATION: Re-authorization occurs when a merchant has a need to submit an authorization request after the cardholder has left the point of interaction and there is no possibility of re-authenticating the card or the cardholder. A merchant may need to do this if they intend to split the shipment into multiple deliveries and will only authorize as goods come into stock. If the need to re-authorize occurs, the subsequent authorization requests carry the new "re-authorization" marker and the scheme reference data from the initial interaction.
    • 
				
  • DELAYED_CHARGES and NO_SHOW: Such transactions occur largely in the rental and hospitality sectors. These transactions also carry the scheme reference data provided in the initial authorization at the start of the rental or stay agreement as well as in the settlement record.
    • 
            

        		
        INCREMENTAL_AUTH|
RESUBMISSION|
REAUTHORIZATION|
DELAYED_CHARGES|
NO_SHOW		
        Conditional
    

    

        standingInstruction.expiry
        Date after which no further authorizations will be performed. Used for authentication request during EMV 3D.
            
    
				
  • For MasterCard - : If the parameter is not sent by the customer, the platform adds a default value of 9999-12-31 within the authentication request.
    • 
				
  • For other brands -:  if the parameter is not sent by the customer, the platform sends an authentication request with indicator "payment" (not "recurring").
    • 

            

	    Note: This parameter is conditional (mandatory when processing 3D Secure on recurring or installment transactions).

        		
        yyyy-mm-dd
        Conditional
    

    

        standingInstruction.frequency
        Indicates the minimum number of days between authorizations.
            
    
				
  • For MasterCard - : If the parameter is not sent by the customer, the platform adds a default value of 0001 within the authentication request.
    • 
				
  • For other brands -: if the parameter is not sent by the customer, the platform sends an authentication request with indicator "payment" (not "recurring").
    • 
            

		Note: This parameter is conditional (mandatory when processing 3D Secure on recurring or installment transactions).
        		
        N4
        Conditional
    

    

        standingInstruction.numberOfInstallments
        Indicates the maximum number of authorizations permitted for installment payments. Required if the Merchant and Cardholder have agreed to installment payments, and EMV 3D authentication is configured i.e. if standingInstruction.type=INSTALLMENT. Omitted if not an instalment payment authentication.
		Note: This parameter is conditional (mandatory when processing 3D Secure on installment transactions).

        
        N3
        Conditional
    

	

		standingInstruction.agreementId
		 Used for Mastercard transactions to transmit the Economically Related Transaction ID (TLID), which identifies and links transactions associated with the same standing instruction agreement (for example, Merchant Initiated Transactions and refunds). During a transitional period, both standingInstruction.initialTransactionId and standingInstruction.agreementId will be returned by Mastercard and are expected to be provided in MIT requests. After the transition period, only standingInstruction.agreementId will be returned in responses and expected in requests.
		
		AN35
		Optional
	

    





	Section 2 of 2
	↑ Top
	




See also