The following is a list of services and use cases supported by Visa Card Program Enrollment (VCPE) API. Please refer to the Client Implementation Guide for an overview on the process of how to use VCPE.
Instant Issuance
Supports attributes assignment to new account numbers for any card:
Across the following use-cases:
Instant Digital Reissuance
Supports attributes reassignment to replacement account numbers:
Instant Card Attribute Change
Supports changing attributes for existing account numbers when:
The VCPE API accepts various data elements and processes, some of them processed in near real time while others are processed during the batch cycle. Card enrollment in RPIN or in VCES and cardholder enrollment information is processed in near real time, while card replacement and linking information and card spend assessment information is processed in batch, as outlined in the above table.
Except as provided below, any transactions performed by cards received and successfully processed through VCPE will receive the RPIN products as interchange, when the “rpinEnrollment” object is included in the VCPE API call. The exceptions to this are as follows:
1. A card that falls in a forced RPIN spend rule will be assigned the interchange product ID per the forced RPIN rule.
2. A card that falls in the grace period per the account open date passed in the API will be assigned the grace period interchange.
3. A card enrolled in a spend assessed group, when the group was processed in the last batch cycle, and if the card is subject to spend rules, will be evaluated based on the group aggregate spend and group account open date.
VCPE calls that do not contain the “rpinEnrollment” object will not affect the interchange for the incoming card. During the batch cycle, the following functions will be performed on the API enrollments:
1. Linking information will be processed, and the VCPE API will accept a linking relationship in a request only if ALL linking groups sent in the request are successfully processed.
2. Any card RPIN enrollments will be processed, and cards will be spend assessed taking into account their spend and replacement/linking relationships.
3. Any upgrades or downgrades as part of the spend assessment will be communicated to the cardholder database at the end of each batch cycle.
4. All card RPIN enrollment information will be sent to downstream systems like loyalty, reporting, etc. post the batch process.
Start a Project
API Overview
API Reference