Wirecard adds HCE to mobile wallet platform

Wirecard has integrated support for host card emulation (HCE) into its mobile wallet platform, “enabling telecommunications companies, financial service providers, banks and also retailers to quickly enter the mobile payment market through near field communication.”

Wirecard

“In order to encrypt sensitive card data, Wirecard emulates a one-off token per transaction, which is used in the EMV transaction,” the company explains. “This replaces the original card data, which is saved in a PCI-compliant database in a secure server environment.

“It is not necessary to change either the sensitive authorisation system of banks or the POS terminal of retailers for this Wirecard solution and no data connection to the internet is required for payments.”

NFC payments via HCE can be combined with other mobile payment technologies — Wirecard already supports traditional NFC payments, Bluetooth LE and QR codes — as well as loyalty, voucher offers and other services, the company adds.

Wirecard mobile wallet customers include mobile network operators Orange, Vodafone, Deutsche Telekom, Telefonica and E-Plus.

Next: Visit the NFCW Expo to find new suppliers and solutions

3 comments on this article

  1. Interesting but it is not just about hiding PAN during the transaction. The EMV transaction must also be properly signed by Application Cryptogram using the key known to the issuer.

    It is not clear what key is used and how in order to produce the EMV Application Cryptogram (TC or ARQC) and where is that key kept and how it is protected.

    If it is kept in the HSM device on the server does that mean that the phone owner must have constant online connectivity and what is the performance of such contactless transaction? Card tearing comes to mind immediatelly

    1. Dear Milos ,
      The Wirecard solution consists of a secure server which is creating one-time payment tokens which will be transferred to the Mobile Device. The Mobile Device then holds a configurable amount of encrypted one-time payment tokens which could be used for payments without requiring a data connection at the mobile device.

      1. Dear Maren

        thanks for clarifying, but it still doesn’t sound like the transaction at POS follows the standard EMV contactless protocol. That being said my impression is that what you described would require modifications to the existing POS infrastructure potentially and as such may present itself as a deployment challenge.

        What I have described in couple of my Finextra blogs is to have fully EMV compatible HCE solution which includes the following at high level:

        For example consumer can connect their HCE enabled mobile payment app to the ‘EMV payment credentials’ provisioning cloud before they go out to the mall, and obtain temporary ‘payment token’ (PAN + expiry date ‘alias’) together with necessary temporary EMV DES key (to be able to produce EMV ARQC for proper online EMV authorization).

        These cloud provisioned temporary payment credentials are nothing else but temporary ‘alias’ to their real payment card info stored inside issuer systems. The ‘payment credential’ life-time can further be potentially tailored / fine tuned based on the risk (closed loop vs. open loop payment, consumer risk tolerance, etc).

        The ‘provisioning cloud’ should ideally be also integrated with the issuer side and provide to them the exact same data to them as part of the whole HCE cloud provisioning process.

        With such provisioned HCE enabled phone, consumer at POS terminal would use it as part of a normal standard contactless EMV payment transaction.

        That transaction would be properly signed (with previously provisioned temporary DES key) and would look exactly as normal EMV contactless transaction to POS and Acquirer and payment scheme. ‘Payment token’ would be used in place of the real payment card data and temporary EMV keys would be used for signing the ARQC cryptogram – that’s the only difference

        The ‘payment token’ ideally should have a BIN which Acquirer clearly understands, and is able to route to the issuer.

        Issuer then would have to recognize that it is a ‘payment token’ (maybe based on BIN) and resolve it to the real payment card info / account with the data already provided by the provisioning cloud, before it can finalize authorization.

        Something like that can work quite nicely in many use payment cases without reliance on MNOs and SIM card availability and what’s even more important without changes required in the existing payment infrastructure.

Comments are closed.