Visa ID & Credential API (VICA) lets you manage consumer identities and payment credentials, and enroll them into multiple Visa products, through one fixed set of endpoints. You select which product an operation applies to using a request attribute — you never call a different endpoint per product.
This page explains the building blocks that are shared across every product. For how the unified APIs sit in front of Visa services, see Overview. For the complete request/response schemas and field constraints, see API Reference.
VICA exposes a single, product-agnostic set of operations. The same operation works across products; the product is chosen in the request body (see Request Patterns).
Supported operations may differ by product; refer to the product-specific documentation for availability.
| Operation | Purpose | Processing |
|---|---|---|
| Enroll Issuer Data | Create a consumer | Asynchronous (202) |
| Enroll Existing Issuer Data with Payment Instrument | Enroll a consumer already registered in another Visa product (e.g. Click to Pay) into an additional product, providing a full payment instrument object | Asynchronous (202) |
| Enroll Existing Issuer Data with Payment Instrument Reference | Enroll a consumer already registered in another Visa product into an additional product, referencing an existing payment instrument by ID — no payment instrument data required | Asynchronous (202) |
| Enroll Payment Instruments | Add payment instrument(s) to an existing consumer | Asynchronous (202) |
| Manage Consumer Information Data | Update consumer profile fields | Asynchronous (202) |
| Manage Payment Instruments Data | Update payment instrument details | Asynchronous (202) |
| Delete Consumer Information Data | Remove a consumer and all associated payment instruments | Asynchronous (202) |
| Delete Payment Instruments Data | Remove a single payment instrument | Asynchronous (202) |
| Get Issuer Data | Retrieve a consumer's enrolled data and payment instruments | Synchronous (200) |
| Request Status by Request Trace ID | Retrieve the outcome of an asynchronous request | Synchronous (200) |
Two variations of enrollment let you add an already-known consumer (or consumer + payment instrument) to an additional product without resubmitting full details — see Implementation Guides.
VICA also sends two outbound notifications to a registered issuer endpoint: a Request Status Notification when an async request completes, and a Click to Pay Enrollment Attempt Notification - see Core Concepts > Asynchronous Processing Model.
For each operation's HTTP method, path, and request/response samples, see Implementation Guides; for the authoritative schema, see API Reference.
Every VICA request combines target product(s) with consumer and/or payment-instrument data. Individual products extend or constrain these objects, but the shape is shared.
| Object | What it represents | Key elements |
|---|---|---|
| products | Which Visa product(s) the operation targets |
An array of { "productCode": … } entries — CLICK_TO_PAY, ADDRESS_VERIFICATION_SERVICE, ACCOUNT_NAME_INQUIRY, ALIAS_DIRECTORY_SERVICE. See Request Patterns. |
| intent | (legacy) Which Visa product the operation targets | Object containing { "type": "PRODUCT_CODE", "value": "CLICK_TO_PAY" } |
| consumerInformation | The person whose data is being enrolled or managed | identity (externalConsumerID, externalConsumerIDOwnerBID), profile (firstName, lastName, countryCode, locale), contact (email, phone), status, consent |
| paymentInstruments | One or more payment credentials linked to the consumer | type (CARD or BANK_ACCOUNT), the type-specific fields, and an optional preferredFor |
A consumer in VICA is uniquely identified by the combination of two fields:
Together they uniquely identify a consumer across the VICA and Click to Pay systems and link enrollment to all later data-management operations, so updates apply to the correct record. Data is siloed per product - enrolling a consumer in one product (e.g., Click to Pay) does not enroll them in another (e.g., AVS).
Start a Project
API Overview
API Reference
"consumerInformation": {
"externalConsumerID": "829662xw-54pl-50tr-c127-5368r18701",
"externalConsumerIDOwnerBID": "10098765",
"firstName": "John",
"lastName": "Doe",
"countryCode": "USA"
}
externalConsumerIDOwnerBID identifies the BID of the entity to which an externalConsumerID belongs. When multiple issuers or processors share a VICA integration, this field tells Visa which entity owns a given consumer record.
Phased Requirement
| Integration date | Requirement |
|---|---|
| Integrated before 3 April 2025 | Optional; existing integrations that omit it continue to work without error |
| All other integrations | Required for Enroll Data and Enroll Payment Instruments requests, recommended to always provide it |
Format
| Constraint | Value |
|---|---|
| Type | String |
| Pattern | Numeric digits only (^\d*$) |
| Min length | 1 |
| Max length | 8 |
| Example | 10098765 |
Table 1: externalConsumerIDOwnerBID field constraints
Choosing the right BID. An issuer may have several BIDs associated with a PAN (e.g., the PAN's Issuer BID or its Holding Company BID). Send the BID of the entity that manages the customer profile:
Include this field wherever consumerInformation is accepted — it applies to all products (CTP, AVS, ANI, ADS). For the correct value for your integration, contact your Visa Representative.
Does VICA process requests synchronously or asynchronously? Both - and which one applies depends on the operation. VICA splits operations into two processing modes. Understanding this model is essential - most write operations do not report their final outcome in the HTTP response.
Writes are asynchronous. Enroll, Manage, and Delete return HTTP 202 Accepted to acknowledge receipt, along with a requestTraceId.
The final outcome arrives one of two ways:
Get Data is synchronous. It returns HTTP 200 with the consumer's current data in the response body.
Outcomes are per-product, not per-request. When a request targets more than one product, each product is processed independently. A failure in one product does not fail the others or reject the request at the HTTP level:
Note: The same VIDC- reason code can mean different things depending on context (synchronous validation vs. Get Data item-level results). See Errors and Troubleshooting for the authoritative, context-scoped code tables.
VICA also pushes a Click to Pay Enrollment Attempt Notification when a consumer self-enrolls and the issuer is enabled for Issuer Offered Click to Pay (IoC). See Click to Pay with VICA.
How do I target one or more products in a request? You tell VICA which product(s) an operation targets using one of three patterns. The choice affects which fields are required and how results are keyed in responses.
| Pattern | When to use |
|---|---|
| products only | Preferred for all new integrations. Targets one or more products in a single request. Codes: CLICK_TO_PAY, ADDRESS_VERIFICATION_SERVICE, ACCOUNT_NAME_INQUIRY, ALIAS_DIRECTORY_SERVICE. |
| intent only | Legacy. Targets Click to Pay only; retained for backward compatibility with integrations that predate products. |
| Intent + products | For integrations originally built on intent for CTP that are being extended - CTP stays addressed by intent, additional products go in products. |
// products only (preferred)
"products": [
{ "productCode": "CLICK_TO_PAY" },
{ "productCode": "ALIAS_DIRECTORY_SERVICE" }
]
Up to four products can be included in one request; each is processed independently.
How the pattern affects responses. In Get Data, Request Status, and Request Status Notification, items are keyed differently depending on the pattern used:
| Request pattern | CTP item keyed by | Other product items keyed by |
|---|---|---|
| intent only | intent | n/a |
| product only | productCode | productCode |
| intent + product | intent | productCode |
Parse the data / details array accordingly: an item is a CTP result if it carries the intent key, and a non-CTP result if it carries the productCode key. (intent-keyed CTP failures use a top-level error string; product-keyed failures use the structured errorDetails object — see Errors & Troubleshooting.)
Not every operation is available for every product. This matrix is the quick orientation; each product hub documents its own specifics.
| Operation | CTP | AVS | ANI | ADS |
|---|---|---|---|---|
| Enroll Consumer | YES | YES | YES | YES |
| Enroll Payment Instrument (type=CARD) | YES | YES | NO ¹ | YES |
| Enroll Payment Instrument (type=BANK_ACCOUNT) | NO | NO | NO | YES |
| Manage Consumer Information Data | YES | NO² | NO | YES |
| Manage Payment Instruments Data | YES | YES | NO | YES |
| Delete Consumer Information Data | YES | NO² | NO | YES |
| Delete Payment Instruments Data | YES | YES | YES | YES |
| Get Data | YES | NO³ | NO ³ | YES |
¹ ANI requires consumerInformation; it does not support standalone card enrollment.
² Consumer-level operations on AVS return HTTP 422.
³ Get Data on AVS/ANI returns item-level error VIDC-1003; other products in the same request are unaffected.