Key features 

Virtual card data type configurations 

Card issuers can select the format for the alternate data to be generated by the IDEMIA Virtual Card service. It includes the card data (token PAN, expiration date, CVV) or the dynamic CVV only.

Domain and usage parameters 

An issuer token could present restricted behavior and the IDEMIA Virtual Card service provides a flexible set of parameters to apply restrictions that can be set and validated during detokenization.

This domains restrictions can be set up by the issuers and by the cardholders directly from the issuer’s mobile app (cardholder initiated constraints will depend on constraints set up by issuer first).

  • Channel restrictions: This restriction limits a given token only to be used for type of transaction it is generated for (eCommerce for VCN) to avoid skimming,
  • Merchant Code Category restriction: Control in which type of merchants the given token can be used,
  • City/merchant/terminal restrictions: Control where this token can be used, it can be a city card, or a merchant card or it can be only available for a given list of terminals (online POS),
  • Data dynamicity: Issuers can select the data dynamicity configuration they wish to propose to their cardholders with the mobile banking application. Virtual card can be reusable or disposable, but in both cases, dynamic data are never stored on device.
    • Disposable virtual card: This configuration lets the consumer request the generation of a single-use virtual card for on-off payments. These cards (token) can only be used and charged once, and then stop to work.
    • Reusable virtual card: This configuration lets the consumer display a reusable virtual card (token) for several purchases or recurring payments.
  • Validity duration: Duration that the token will be made available. Validity can be on scale of hours, days or years,
  • Amount limit: Limit on maximum amount per transaction (multiple currencies supported),
  • Cumulative amount: Control of the card balance (in the case of multiple payments to reach the amount limit).

Issuer tokenization services 

The IDEMIA Virtual Card service relies on the IDEMIA Vault module ensuring the mechanism for card issuer token mapping with PAN and secure storage of associated data. It provides underlying security and the related processing controls, as defined by EMVCo such as data encryption data, PCI-DSS / PCI-TSP compliance... The IDEMIA Token Vault module stores the mapping of issuer tokens to associated PAN, the domain restriction profile for a specific issuer token, the lifecycle update for a specific issuer token and the transaction history per issuer token.

During payment transaction processing, IDEMIA proceed to the following steps (transaction authorization is the responsibility of the issuer):

  • Detokenization and counter-fraud checks: IDEMIA receives processing request for a specific issuer token from the acquiring chain of the merchant/PSP (based on PAN range). IDEMIA checks first if the token PAN is registered in the Token Vault, then checks the issuer token status and validity date. Then IDEMIA converts the issuer token to the associated PAN. It also proceeds to domain restriction checks (usage, amount …) and cross-channel checks as established during the issuer token profile set-up. Then the result of the detokenization and all the verification codes of the domain constraints are sent back to the issuers for their authorization decision process.
  • Cryptogram validation: The processing request also consists of IDEMIA validating the received cryptogram and checking if the Application Transaction Counter (ATC) value is within the allowed range to detect replay attacks. Based on the domain restriction profile different type of cryptograms can be verified (remote, CVVs…). Both the results of cryptogram(s) verification and ATC checks are sent to the issuers for the authorization decision process.

Card/token lifecycle management 

The IDEMIA Digital First services can propagate/support issuer’s cards and tokens lifecycle updates towards the different Token Service Providers and Token Requestors for a variety of use cases enabled. IDEMIA can support the following lifecycle events in the frame of the Virtual Card service:

Card life cycle management 

The issuer can initiate updates during the card's lifecycle. These changes can be:

  • Card update: In case of plastic card renewal - stolen or lost, the issuer might want to update a payment card by changing the card PAN or the card expiration date.
  • Card profile update: The issuer might want to update a payment card profile by changing the card product related properties like product description, Terms & Conditions, contact information, the card arts, color schemes...
  • Card suspension, resumption and termination: A card can be temporary, suspended then resumed, or definitely terminated. IDEMIA receives the request from the issuer and propagates the operation to all tokens deployed among the different Token Requestors.

Issuer token life cycle management 

Once an issuer token is created and bound to a specific PAN, a number of different events can affect the function of the issuer token:

  • Issuer token re-personalization: An issuer token contains keys and credentials but also some tags needed to personalize card data on all digital wallets. An issuer token re-personalization is performed when these tags need to be re-personalized throughout the card lifecycle. The issuer token re-personalization is automatically managed, transparently for the end-user and the issuer. The new card characteristics are updated on all devices.
  • Issuer token renewal: An issuer token is renewed when it reaches its expiry date. The TSP can generate a new expiry date and it is done transparently for the end-user and the issuer.
  • Issuer token reissuance: An issuer token might need to be reissued in case of a transfer from one device to another, a device restoration process, for security concerns or when the Application Transaction Counter (ATC) has reached its maximum value. The issuer token reissuance can be requested by the Token Requestor or by the issuer.
  • Issuer token suspension, resume and termination: These operations can be triggered by a request from the issuer in case of fraud suspicion, device lost or stolen. It can also be requested by the Token Request on behalf of the end-user or Merchant/PSP when the card is suspended or deleted from the wallet.

Campaign Manager sub-service 

For card lifecycle events (update, suspension, redemption, termination) and token lifecycle events listed above, IDEMIA can run these updates in a batch mode, also called a campaign. Each campaign will define its execution period, its operation process timeout and the required throughput. The service comes with on-demand status endpoints such as campaign id, status, number of items passed, number of items failed, number of items in progress, failures reasons…

Transaction notification to customer 

Payment transaction notification to customers can be pushed automatically by the issuer via the IDEMIA Virtual Card service. IDEMIA allows issuers to notify payment transactions to be forwarded to the customer wallet and for the wallet to retrieve the transaction details/history.

Activate new features 

By relying on the IDEMIA Digital First Platforms Suite and integrating the IDEMIA Virtual Card service, card issuers can easily access new services and make new features available via their mobile banking app to the cardholders. The IDEMIA Virtual Card service can be combined with the IDEMIA Secure Display service to display the alternate card data from the issuer’s mobile app. The IDEMIA Digital First Platforms Suite operate as a multi-tenant cloud system offering card issuers a unique interface to activate features from their mobile banking app and for connectivity to Token Service Providers and Token Requestors, for a variety of use cases.