Launching an Issuer bank’s own HCE based wallet can differentiate Issuers from their competitors and they can get a competitive edge for their wallet. With issuer wallets you can control the user payments experience, add the services as per your requirement and simplify the solution such as automatic provisioning of card tokens without entering card details.
Control over the solution – With HCE, the issuer builds the user interface and so they have the flexibility and control over how the cardholder interacts with the service. This gives issuers opportunity to innovate, simplify and evolve their products and services.
Security – SWIM security layer which HCE tokenisation uses incorporates end user security framework to a large extent. On top of the HCE tokenisation security, SWIM protects the HCE end-to-end solution using the Public Key Infrastructure (PKI) technology providing the highest level of security for the tokenised and cryptographic data, user and device authentication and credential delivery channel between the mobile and the host.
Devices – HCE works on all the Android OS which is a large part of the mobile population. We believe iPhones will soon enable HCE too rather than restricting to Apple Pay!
Support of Domestic card scheme – our solution can also connect banks (for tokenisation) to the domestic card schemes like RuPay.
OEM Pays (Google Pay/Apple Pay) provide an opportunity to the issuers to play in the mobile payments market. But at the same time issuers need to look at the bigger picture and identify the next wave of customer experience and decide where they want to be in next 1-3 years of time frame. And that requires the right decision to be made today to put yourself in the right position in future!
HCEWALLET enables Issuers to connect to Visa/MC/NPCI Token Services (VTS/MDES/RuPay) and enrol in the card scheme tokenisation framework automatically to participate in e-commerce, in-app and NFC tokenisation. Issuers have the option to manage and decision token provision to specific token requestors.
The consumer is the cardholder who is making e-commerce, card-on-file, and in-app purchases. Tokenisation is largely transparent to the consumer. HCE Service HCEWALLET SDK provides functions to control tokenisation for multiple modes (Proximity – NFC-HCE, In-App and E-commerce) and refers to the token with the consumer as a “digital account number”. By default all three modes are enabled for all consumers that use the HCEWALLET SDK in the merchant app. The user can control via the mobile app setup to disable any mode other than NFC-HCE. Note, the NFC-HCE mode will be auto-disabled if the phone does not support NFC.
HCEWALLET supports the following core services:
- Provisioning and Authentication Support; Purging PANs: Upon receipt of a token, all merchants of HCE Service must delete the associated PAN from its systems and not keep or reference the PAN in any way, except to display the last four digits on a cardholder receipt.
- Lifecycle Management Support: Cardholder-initiated and issuer-initiated requests including the update and modification of tokens and all other applicable lifecycle events (e.g., delete, resume, suspend, update).
- Token Processing: Token payment processing has integrated SWIM Digital ID based strong 2-factor authentication (SCA) via the cardholder mobile device and the SWIM Digital ID PIN.
3D Secure V2
3D Secure V2 (3DSV2) is not currently available for tokenised transactions. If an authorisation is made using a card account for which the cardholder has been authenticated using 3DSV2 services, the authorisation message must not be accompanied by a cryptogram that is associated with a token. Cryptograms associated with tokens are based on the token and not the card. Cryptograms associated with 3DSV2 correspond to the Cardholder Authentication Verification Value (CAVV) and are associated with a card. Cryptograms associated with tokens are not an equivalent of the CAVV, and the cryptogram issued with tokens must be used during authorisations with tokens. When a card that has been 3DSV2 submitted for authorisation, the accompanying CAVV must be that of the card as provided by the 3DSV2 service.
Account Verification Failure
Account verification failure is not an indicator of a token failure. Similar to 3DSV2, account verification is not available using token and cryptogram. Any current account verification procedures applied to cards do not work with tokens. As indicated above, an account verification failure does not imply token failure, and vice-versa.
Card Art Management
As a part of the tokenisation process, card schemes send the card art during the token provisioning flow. Card schemes recommend that the card art be shown in all cardholder-facing PAN display interactions. In a situation where the actual card art images are not available (e.g., due to technical issues that cause a failure to render the images), the card can be rendered using the colour scheme provided by card scheme (on behalf of the issuer).