HCE Heightens Security Responsibility for Issuers

Host Card Emulation (HCE) offers virtual payment card issuers the promise of removing dependencies on secure element issuers such as mobile network operators (MNOs). HCE allows issuers to run the payment application in the operating system (OS) environment of the smart phone, so the issuing bank does not depend on a secure element issuer. This means lower barriers to entry and potentially a boost to the NFC ecosystem in general. The issuer will have to deal with the absence of a hardware secure element, since the OS environment itself cannot offer equivalent security. The issuer must mitigate risk using software based techniques, to reduce the risk of an attack. Considering that the risk is based on probability of an attack times the impact of an attack, mitigation measures will generally be geared towards minimizing either one of those.

To reduce the probability of an attack, various software based methods are available. The most obvious one in this category is to move part of the hardware secure element’s functionality from the device to the cloud (thus creating a cloud based secure element). This effectively means that valuable assets are not stored in the easily accessible device, but in the cloud. Secondly, user and hardware verification methods can be implemented. The mobile application itself can be secured with software based technologies.

Should an attack occur, several approaches exist for mitigating the Impact of such an attack. On an application level, it is straightforward to impose transaction constraints (allowing low value and/or a limited number of transactions per timeframe, geographical limitations). But the most characteristic risk mitigation method associated with HCE is to devaluate the assets that are contained by the mobile app, that is to tokenize such assets. Tokenization is based on replacing valuable assets with something that has no value to an attacker, and for which the relation to the valuable asset is established only in the cloud. Since the token itself has no value to the attacker it may be stored in the mobile app. The principle of tokenization is leveraged in the cloud based payments specifications which are (or will soon be) issued by the different card schemes such as Visa and MasterCard.

HCE gives the issuer complete autonomy in defining and implementing the payment application and required risk mitigations (of course within the boundaries set by the schemes). However, the hardware based security approach allowed for a strict separation between the issuance of the mobile payment application on one hand and the transactions performed with that application on the other hand. For the technology and operations related to the issuance, a bank had the option of outsourcing it to a third party (a Trusted Service Manager). From the payment transaction processing perspective, there would be negligible impact and it would practically be business as usual for the bank.

This is quite different for HCE-based approaches. As a consequence of tokenization, the issuance and transaction domains become entangled. The platform involved in generating the tokens, which constitute payment credentials and are therefore related to the issuance domain, is also involved in the transaction authorization.

HCE is offering autonomy to the banks because it brings independence of secure element issuers. But this comes at a cost, namely the full insourcing of all related technologies and systems. Outsourcing becomes less of an option, largely due to the entanglement of the issuance and transaction validation processes, as a result of tokenization.

 

Posted in Best Practices for Merchants, Credit Card Security, EMV EuroPay MasterCard Visa, Near Field Communication, Visa MasterCard American Express Tagged with: (MNOs), (OS), assets, bank, card, card issuers, cloud, cloud based payments, cloud based secure element, cloud-based, hardware secure element, Host Card Emulation (HCE), issuing bank, MasterCard, mobile, mobile app, mobile application, mobile network operators, mobile payment, mobile payment application, nfc, operating system, payment application, payment transaction, payments, platform, risk, secure element, smart phone, software, software based technologies, token, tokenization, transaction, virtual payment, visa

Present or Not Present Card Transactions?

When plastic cards become digital tokens, they become virtual. So how do you say that the Card is Present or Not Present.  The legendary regulatory difference that the cards industry has relied on to differentiate between interchange fees for Card Present and Card Not Present transactions.

Apple secured Card Present preferential rates for transactions acquired by iTunes on the basis that the card’s legitimacy is verified with the issuer at the time of registration and the token minimizes probability of fraud. If an API call to the issuing bank is sufficient to say that the Card is Present, who is to say that the same logic can’t apply to online merchants who also verify the authenticity of Cards on File when they tokenize them? How can one arbitrarily say that the transaction processed with token from an online merchant is Card Not Present, but the one processed with Apple Pay is Card Present even though both might have made the same API call to the bank to verify the card’s validity?

In the Apple case, a physical picture of the card is taken and used to verify that the person registering the card has it. It is not that hard for an online merchant to verify that the Card on File converted as a token does belong to the person performing an online transaction.

As we move towards chip and pin the card present merchants will spend substantial money upgrading their hardware and POS systems. That expense will be offset by that savings in losses due to fraud. MOTO and e-commerce transactions ( card NOT present ) will always have a higher cost because the nature of processing is NON face to face transactions. Of course the fraud and losses are higher when the card is manually entered or given to someone over the phone……Face to face will always have the lowest cost per transaction because it is usually the final step in the sale. Restaurants are low risk because you had the transaction AFTER you eat. If there is a dispute it happens before the merchant even sees the credit card.

In the long run, as cards become digital and virtual through tokens, we are all going to wonder if card is present or not present. May be some will say. Card is a ghost.

Posted in Best Practices for Merchants, Credit card Processing, EMV EuroPay MasterCard Visa, Visa MasterCard American Express Tagged with: (POS) systems, API call, Apple secured Card Present, bank, Card Not Present transactions, card present, card present merchants, cards, cards industry, chip, credit-card, digital and virtual, digital tokens, e-commerce transactions, fees, fraud, hardware, industry, interchange, interchange fees, issuer, issuing bank, low risk, Merchant's, moto, NON face to face transactions, online, online merchants, online transaction, PIN, Processing, Rates, token, transactions

Payment Processor and Payment Processing

A payment processor is a company often a third party appointed by a merchant to handle credit card transactions for merchant acquiring banks. They are usually broken down into two types: Back and Front-End.

Back-End Processors accept settlements from Front-End Processors and, via The Federal Reserve Bank, move the money from the issuing bank to the merchant bank.

Front-End Processors have connections to various card associations and supply authorization and settlement services to the merchant banks’ merchants. In an operation that will usually take a few seconds, the payment processor will both check the details received by forwarding them to the respective card’s issuing bank or card association for verification, and also carry out a series of anti-fraud measures against the transaction.

Additional parameters, including the card’s country of issue and its previous payment history, are also used to gauge the probability of the transaction being approved.

Once the payment processor has received confirmation that the credit card details have been verified, the information will be relayed back via the payment gateway to the merchant, who will then complete the payment transaction. If verification is denied by the card association, the payment processor will relay the information to the merchant, who will then decline the transaction.

Modern Payment Processing

Due to the many regulatory requirements levied on businesses, the modern payment processor is usually partnered with merchants through a concept known as software-as-a-service (SaaS). SaaS payment processors offer a single, regulatory-compliant electronic portal that enables a merchant to scan checks “often called remote deposit capture or RDC”, process single and recurring credit card payments (without the merchant storing the card data at the merchant site), process single and recurring ACH and cash transactions, process remittances and Web payments. These cloud-based features occur regardless of origination through the payment processor’s integrated receivables management platform. This results in cost reductions, accelerated time-to-market, and improved transaction processing quality.

Payment Processing Network Architecture

Typical network architecture for modern online payment systems is a chain of service providers, each providing unique value to the payment transaction, and each adding cost to the transaction. Merchant>Point-of-sale SaaS> Aggregator >Credit Card Network> Bank. The merchant can be a brick-and-mortar outlet or an online outlet. The Point-of-sale (POS) SaaS provider is usually a smaller company that provides customer support to the merchant and is the receiver of the merchant’s transactions. The POS provider represents the Aggregator to merchants. The POS provider transaction volumes are small compared to the Aggregator transaction volumes. The POS provider does not handle enough traffic to warrant a direct connection to the major credit card networks. The merchant also does not handle enough traffic to warrant a direct connection to the Aggregator. In this way, scope and responsibilities are divided among the various business partners to easily manage the technical issues that arise.

Transaction Processing Quality

Electronic payments are highly susceptible to fraud and abuse. Liability to merchants for misuse of credit card data creates a huge expense on merchants, if the business were to attempt mitigation on their own. One way to lower this cost and liability exposure is to segment the transaction of the sale from the payment of the amount due. Some merchants have a requirement to collect money from a customer every month. SaaS Payment Processors relieve the responsibility of the management of recurring payments from the merchant and maintain safe and secure the payment information, passing back to the merchant a payment token. Merchants use this token to actually process a charge which makes the merchant system fully PCI-compliant. Some payment processors also specialize in high-risk processing for industries that are subject to frequent chargebacks, such as adult video distribution.

 

Posted in Best Practices for Merchants, Credit card Processing, Electronic Check Services, Electronic Payments, Internet Payment Gateway, Merchant Services Account, Payment Card Industry PCI Security, Point of Sale, Visa MasterCard American Express Tagged with: aggregator, aggregator transaction volumes, back end, card associations, card data, chargebacks, credit card transactions, electronic portal, front end, front-end processors, issuing bank, merchant, merchant bank, network architecture, online payment systems, payment gateway, payment processing, payment processor, payment transaction, pci-compliant, point of sale, POS, SAAS