This endpoint allows issuers to get a list of merchants storing the cardholders' card information. This includes transactions initiated by the cardholder or the merchant in the last 13 months.

The "Card-on-File (COF) Data Service" request requires the Primary Account Number (PAN), which is the cardholder's account number. The "COF Data Service" response includes the PAN, cleansed merchant name, last transaction date and amount, total number of transactions, token requestor ID, VAU update flag, and the last 4 digits of old PAN, besides other fields.

Features

Key points are:

1. This endpoint is based on VDP standards to provide merchant details, without the duplication of merchant names, from the transaction data, VAU requests, and VTS COF tokens for a given issuer.
2. The Visa PAN, or mapped tokens, are used to submit COF transactions (authorization, full financial, or account verification) in the last thirteen months.
3. Apply the criteria for both PAN and token to identify where the PAN or mapped token credentials may be stored on file, which identify merchant names and corresponding Merchant Category Codes.
4. The Visa Account Updater (VAU) status provides an update indicator and update date in the endpoint response to show whether the merchant has pulled VAU for the PAN update.
5. The Token PAN Replacement Status indicates whether an account update has been applied to the token's underlying credential, allowing it to process as normal.

The "Card-on-File Data Service" endpoint gives issuers information about the card-on-file merchants where cardholders have either transacted or stored their PAN/token credentials for merchants to initiate payments, in the last 13 months.

The merchants would have done either of these:

• Tokenized the cardholder’s PAN, through COF token provisioning.
• Initiated transactions using PEM 10 for that card.
• Initiated recurring and bill pay transactions.
• Performed VAU update for that card.

The endpoint allows issuers to enhance their mobile or online banking applications to show the list of merchants and other COF data attributes to provide visibility into where a cardholder's card credentials are stored. In the event of card reissuance, the issuer can also display information about merchants that received the updated card details.

The most transparent way to flag card-on-file transactions is by identifying transactions initiated with “Point of Sale Entry Mode 10 (PEM 10).” Until PEM 10 gains full industry adoption, Visa will use a combination of techniques to identify merchants for a given cardholder that have likely stored cardholder’s credentials.

This endpoint returns the data layer aggregated at the raw merchant name level.

The fields, including raw merchant name, enable cardholders to have visibility into which services under the broader merchant brands are transacting using stored credentials. In addition, the raw merchant name details enable interoperability with the Stop Instruction end points, which require raw merchant name as one of the input values.

This API allows issuers to add stop instructions for a specific merchant.

A merchant-level stop instruction stops all eligible matching Card-On-File payments, against a specific merchant, for as long as the stop instruction is active. The decline reason code for a declined authorization request is R0 / R1 and the return reason code for returning clearing transactions is C0 / C1.

Stop Instructions for Multiple Merchants

You can add multiple stop instructions using this API. The system creates a separate stop instruction for each merchant identifier that you include in the request, except for suspected shared Card Acceptor IDs (CAIDs), which may be dropped in favor of an alternative merchant identifier provided.

You can include up to 10 groups of merchant identifiers. This is useful if the cardholder wishes to stop payments against multiple merchants. Each group is treated separately when assessing and acting upon a suspected shared CAID, even though the groups have been included in the same " VSM Add Merchant " request message. For example, merchant identifiers from groups 1 and 2 are not affected by a suspected shared CAID found in group 3.

Alternatively, you can restrict a VSM Add Merchant request message to include no more than one of each type of identifier (effectively a single group) and submit separate request messages for different merchants or merchant variations. In such cases, for the suspected shared CAID functionality to be applied in VSM, you must still use the grouping attribute.

Information Submission

This information is required to create a merchant-level stop instruction:

• Primary Account Number (PAN).
• Merchant Identifier for merchant-level stop instructions.
• Start Date. In the absence of a future start date, the stop instructions will start immediately.
• Duration. The number of months for which the stop instruction will be active. The end date will be set to be the startDate + duration and rounded to the end of the final month.

Optional information can be added:

• Further matching information to identify the intended transaction, such as minimum or maximum transaction amounts.
• Additional non-matching information such as case numbers etc.

Stopping payments with VSM can only be as effective as the stop instruction details provided. Visa recommends reviewing the accuracy of stop instructions, including the use of relevant mandatory and optional identifiers. Incomplete VSM stop instructions are rejected, but Visa does not verify the accuracy of stop instructions.

This API allows you to search for existing stop instructions.

The request uses the PAN, which is the card number. The response includes the stop instruction ID and summary information for each active stop instruction. This information can later be used to cancel an active stop instruction and restart previously stopped payments..

This API allows you to cancel a single or multiple stop instructions for a PAN, which is a card number.

The API request must include the stop instruction IDs. You can send one Stop ID for a single instruction or up to ten Stop IDs in the cancellation message.

At this point your access request should have been approved  to the VSM APIs.

Note: You will need to continue using the developer account that has been granted access to the API. If additional developers in your organization require access they are required to make their own request to [email protected].

Create a project : 

1. To create a new project, go to your Dashboard and choose "Add new project". Provide a project name, a short description, and choose VCA Data Exchange API from the 'trials' section.
2. You will be prompted to choose to generate a CSR or submit one. 
3. A private key will be provided by the portal which you must download and store securely.

Explore a walkthrough of project creation

Once the above steps are complete, you can start making requests in the sandbox using the endpoint.

API Testing in Sanbox:

1  Download certificate from credentials section of the project created.

2  Encrypt the payload for payload encryption and response decription details, refer to the Message Level Encryption Documentation.

3. You can contact Visa team for payload details.

3  Use postman to test the product.

For more details on certificate download refer to our Developer Tools Blog .