Digital Cards

Digital cards can be viewed as the digital twin of a physical card. They can be fulfilled independently of or alongside a physical counterpart. Assuming the relevant XPay wallet has been enabled, as soon as a digital card is successfully requested and activated, it can be used by cardholders to make online or contactless payments without having to await the arrival of a physical card.

Advantages of digital cards:

  • Can be added to digital wallets through Apple Pay, Google Pay, or Samsung Pay (where the relevant wallet has been enabled).
  • Card details can be saved on e-commerce platforms like Amazon or Uber without the need to update them once a corresponding physical card arrives.
  • No requirement to separately activate a physical card, so cardholders can use their card straight away.
  • Share the same card identifier as any physically issued counterpart, meaning the two can be treated by partners as a single record.
Card identifier

The Solaris API makes no distinction between the digital and physical version of a card - both the digital card and any physical counterpart will be assigned the same identifier (CardID), and are considered the same card.

Differences between virtual cards and digital cards

Although digital cards are similar in certain respects to virtual cards, please note the following differences between the two:

Virtual Cards Digital Cards
Physical Counterparts Not linked to any physical card. They only exist virtually. Can be linked to a physical card. Sharing the same PAN, CVV2, and expiry date as the physical card.
Usage and Lifecycle Can be issued on-demand, for limited uses and days (depending on the config chosen). Exist for as long as the physical card exists as the two are interlinked.
Accounts and Funds Not always linked to a main account. Funds must be transferred from the main account to the virtual account to enable payments. Linked to the main account. They provide a seamless experience to the cardholder as all the funds are in one place.
PIN Retrieval Intended primarily for e-commerce use, virtual cards do not have a PIN. Card PIN can be retrieved from the API.

Notes and pre-requisites for partners wishing to enable digital cards on a program

PCI-DSS

PCI-DSS certification is a mandatory requirement before digital cards can be enabled for programs in the production environment. Testing and integration of this functionality can be conducted in other environments without requiring certification.

  • It is recommended that partners have in place a KYC process involving additional customer verifications such as identity and address checks, as until the relevant anti-impersonation and fraud mitigation checks are complete, daily cardholder spending will be limited (currently limited to £50/€50 per day). In the absence of these checks successful use of Chip + PIN by the cardholder is required to remove the lower daily spending limits, therefore necessitating the requirement for a physical card.
  • As digital cards are available for use immediately following fulfillment, partners should ensure that card details (PAN, CVV2, expiry date) can be shared with the customer in app, along with any activation or confirmation instructions that may be required in the workflows outlined below.
  • As physical cards on a digital card enabled program can be issued as active, these programs can be configured to issue numberless cards as an additional fraud prevention measure. These are physical cards where the printing of certain sensitive card information (PAN, CVV2, expiry date) on the card interface can be suppressed, with card information only available from within a secure app, to minimize the risk of tampering, interception or copying of card details during transit or at the point of sale. Please note that due to this suppression of key information on the physical card, numberless cards are only available on digital card programs.

Digital Card Workflows and API Integration

Aligning existing card ordering flows

The workflows outlined below assume the relevant program configuration has been conducted. Once the desired program configuration is in place, existing card ordering flows should be checked, and where relevant amended, to ensure they align with the new configuration.

Workflows overview

There are two primary workflows for digital card issuance, both of which can be enacted on the same program. In all cases, any digital cards fulfilled are available for immediate use once they have been activated via the API.

  • Simultaneous issuance - In this workflow, when a digital card is requested, a physical counterpart is automatically issued to the consumer at the same time.
  • Optional physical card on request - In this workflow, the consumer is by default provided a digital card only, with no physical card automatically issued. If required, a physical counterpart of the digital card can be requested via API. The advantages of this workflow include:
    • Lower cost per card issued.
    • Reduced dependency on physical card stock, further lowering costs and overheads.
    • The option to request a physical card after digital card fulfillment, providing flexibility and potential consumer incentivization.
Creating new consumers on digital card enabled programs

For programs earmarked for digital cards, when creating new consumers using the Consumer/AddConsumers method, the IsSkipCardIssuance parameter must be set to true. This is to ensure that following a request for a new card, when card details are retrieved from the API via the Cards/GetSpecificNameOnlyCard method, the details will have already been generated and be available for immediate use.

Retrieving sensitive details for an existing card

For each workflow a primary requirement for partners is to retrieve details for an existing card, either to display these to the consumer in-app or for purposes of card activation. Passing the relevant CardID to the Cards/GetSpecificNameOnlyCard method will return card details including the PAN, CVV2 (both in encrypted format) and expiry date.

Issuing a physical and digital card for a consumer simultaneously

Use this workflow to issue both a digital card and physical counterpart to the consumer simultaneously.

  1. Request a new card by calling the Card/RequestNewCard method with the relevant CardDesignCode and IssuePhysicalCard parameter set to true .
  2. Pass the CardId of the newly created card to the Card/GetSpecificNameOnlyCard method to retrieve the key details for the card.
  3. Activate the newly created card by calling the Card/ActivateCard method with the relevant card details.

Fulfilling a digital card for a consumer, optionally issuing a physical card on request

Use this workflow to fulfil a new digital card, with the option to issue a physical counterpart if requested at a later date.

  1. Request a new card by calling the Card/RequestNewCard method with the relevant CardDesignCode and IssuePhysicalCard parameter set to false .
  2. Pass the CardId of the newly created card to the Card/GetSpecificNameOnlyCard method to retrieve the key details for the card.
  3. Activate the newly created card by calling the Card/ActivateCard method with the relevant card details.
  4. If or when a physical counterpart for the card is required, the CardId of the existing digital card can be passed to Card/IssuePhysicalCardForDigitalCard method, which will issue the physical counterpart of the card.

Notes for issuing a physical card for an existing digital card

Following fulfillment of a digital card, it is possible to configure the time after which requests for a physical counterpart will instead issue a new card (that is a new PAN, CVV and expiry date). This configuration is designed to help avoid excessive depletion of physical card stocks and potential costs to both the partner and cardholder. Consider for example the following scenario:

  1. A cardholder has had their digital card for 30 of the 36-month lifespan of the card.
  2. The cardholder decides to request a physical counterpart, which is issued to them.
  3. After the remaining 6 months have elapsed, the card (including the physical counterpart) expires, and a new card is issued.
  4. The cardholder subsequently requests a new physical counterpart for the new card.

In this example scenario two physical cards have been issued in relatively quick succession, which has resulted in depleted card stock and associated costs. The configurable cut off period is used to determine whether a physical counterpart of the currently active card, or a brand-new card - with corresponding physical counterpart, will be issued. These scenarios are detailed below:

A physical card is requested within the configured period following digital card fulfillment

  • A physical card with the same PAN, CVV2 and expiry date as the currently active card will be issued.

A physical card is requested outside the configured period following digital card fulfillment

  • A brand-new card will be issued, with a new PAN, CVV2 and expiry date.

Card activation is at this point dependant on the status of the consumer's existing physical card (if one has been issued).

  • If no physical counterpart for the existing card has been issued previously, the new card can be activated immediately.
  • If the existing physical card has been marked as lost or stolen , the new card should be activated immediately, both for security reasons and to allow it to be used/the new details displayed in-app.
  • If the existing card has been marked as damaged , the card activation workflow is at the discretion of the partner. Two possible activation journeys are:
    • The new card is activated immediately following the request. The new card details will be available to the consumer in app, their existing physical card will however no longer work.
    • Alternatively, the existing card details, including physical card continue to be used. Once the consumer confirms receipt of the new physical card (e.g., via the app UI) the new card is activated and the old physical card will no longer work.
Card activation confirmation

In this scenario, as new card details are being issued it is recommended that confirmation is received from the consumer that they are happy to proceed.

Card tokenization following card activation

For any card that was previously tokenization by a consumer, the token will automatically be transferred to the new card once it is activated.

Notification of digital card renewal

Partners can be informed of when a digital card has expired and been renewed via the Card Action Notification. This notification will include information regarding the expired digital card, the renewed digital card and whether a new physical card has also been issued following expiry.

Solaris is the brand name for the regulated entities Contis Financial Services Ltd and UAB „Finansinės paslaugos „Contis“, which are part of the Solaris Group.