CODE 10
February 17th, 2016 by Elma Jane

Helping customers protect and safeguard their payment data is one of NTC’s top priorities. Experts agree that a layered approach is the most effective way to combat evolving security threats and unauthorized access to payment data.

Implementation of best practices and the latest protection technology is needed to ensure of cardholder data protection from increasingly complex and evolving security threats.

EMV is a good start to enhance data security with card authentication, cardholder verification, and transaction authorization. But a multi-layered security approach that includes encryption and tokenization provides complete data protection to both merchants and their customers.

EMV alone is not enough because EMV authenticates the validity of the card and the cardholder, but it does not secure the data. With encryption and tokenization without EMV, as a merchant, you are liable for fraudulent transactions. Encryption and tokenization are a process or system to protect sensitive cardholder data but do not authenticate the data.

EMV is a key component to a multi-layered security approach. It secures the payment transaction with enhanced functionality, by combining EMV, encryption and tokenization merchants can have a complete data protection that they need.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Posted in Best Practices for Merchants, Credit Card Security, EMV EuroPay MasterCard Visa Tagged with: , , , , , , , , , , , , ,

September 17th, 2014 by Elma Jane

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: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

March 31st, 2014 by Elma Jane

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: , , , , , , , , , , , , , , , , , , , , , ,