Apple Pay – An attempt to demystify

When Apple announced ApplePay as a service on September 9th, 2014 and subsequently in their press release, they mentioned a few key terms like Secure Element, Tokens, One time unique number, Device account number, dynamic security code and such. Take a look at the 4th paragraph in their press release to see what I mean. For the layman, this could mean that apple has used some complex security technology to make ApplePay secure; but for some people in the field of mobile payments and security, it was not very clear what Apple was trying to say. So, let’s try and dissect that, shall we?

For simplicity, we are only going to discuss about ApplePay in the context of a payment made at a physical POS and not the mCommerce version of the service. This is only an educated attempt to understand the underlying implementation while the reality could well, be different.

Let’s start with the Secure Element (SE). ApplePay stores the payment credentials inside the SE. It does not store them in the cloud and it does not store them within the host operating system. This means that none of the iOS apps will have access to the payment information stored within the SE.

What exactly is stored in the SE?

When, you as a customer add a credit card to your Passbook (Mobile Wallet), the simplest thing for the wallet to do would be to store the real payment credentials like the Primary Account Number (PAN) into the SE. But that is a naive implementation and Apple does not do that. ApplePay instead stores something called a token and some associated data inside the Secure Element.

What is a token?

Token is like a fake credit card number that looks and feels like a credit card number for most intents and purposes, but it is not the real deal. During transaction authorization the token would be de-tokenized into the real PAN before passing on to the Issuer for authorization. The entity that places a request to de-tokenize differs depending on the tokenization standard used. In proprietary tokenization technologies, an Acquirer would be responsible for tokenization and de-tokenization. But, ApplePay uses the latest in tokenization standard created by EMVCo. In this case, the payment network performs de-tokenization.

How is a token provisioned to the SE?

Now that we know that a Token is stored in the SE, the next step is to find out how it gets provisioned there in the first place. There are many ways in which this could have been implemented and we will not know for sure until Apple announces its implementation. But, here is an educated guess I would go with…

When a customer adds a credit card to their wallet, the PAN details are submitted to ApplePay servers. ApplePay sends the information over to the corresponding Issuer bank asking for a Token in return. The Issuer bank calls a Token Service Provider (TSP) and requests for a token. As far as I know, the payment network themselves play the role of TSP at present.

The TSP vaults the PAN, maps it to a token and returns the token and a token-key. This token-key will later be used to generate a dynamic cryptogram at the SE. The Issuer receives a token and token-key, and adds a cvv-key to the mix. The cvv-key will be later used to generate a dynamic security code at the SE. The Issuer returns the token, token-key and cvv-key back to ApplePay. ApplePay, acting as its own Trusted Service Manager (TSM) provisions the token, token-key, cvv-key and maybe other data into the Secure Element. It is the Token that Apple calls as “Device Account Number” in its press release.

What happens when a payment transaction is initiated?

When a customer taps or waves their iPhone in front of a point of sale terminal, a payment transaction is initiated. ApplePay uses EMVCo’s Contactless suite of specifications to communicate with the contactless reader terminal. When it is time for the Secure Element to send information to the terminal, it does two things. First, it generates a dynamic cryptogram using a combination of the token, token-key, transaction amount, transaction counter etc. Second, it generates a dynamic CVV value using the cvv-key. Finally, it passes the token, the dynamic cryptogram, the dynamic CVV and other payment and chip data elements to the terminal using the EMV specification.

Let’s stop for a moment here and review what just happened and compare that to Apple’s press release as quoted below.

“Each transaction is authorized with a one-time unique number using your Device Account Number and instead of using the security code from the back of your card, Apple Pay creates a dynamic security code to securely validate each transaction.”- From the press release

From the quote above, the Device Account Number represents the Token, the One-time Unique Number represents the dynamic cryptogram and the Dynamic Security Code represents the dynamic CVV.

What happens during a payment transaction?

The contactless terminal receives the token, dynamic cryptogram, dynamic CVV and other data elements according to the contactless EMV specification (or contactless MSD for backwards compatibility) and sends them over to the Acquirer. The Acquirer doesn’t know or care if the incoming PAN is a token PAN or the real PAN. They just identifiy the payment network based on the BIN and send it over the corresponding payment network.

The payment network identifies that it is a tokenized PAN and not a real PAN based on BIN tables. Consequently, they send a request out to the TSP to de-tokenize passing in the Token and the dynamic cryptogram. The TSP, among other things, validates the cryptogram using the token-key that it shared earlier during the provisioning process. If the cryptogram is valid, the TSP de-tokenizes and returns the real PAN back to the payment network. The payment network attaches the real PAN to the authorization request and sends it over to the Issuer for authorization.

The Issuer validates the dynamic CVV based on the cvv-key it shared earlier during the provisioning process. Then it authorizes the transaction depending on the customer’s account status. The authorization status flows back from the Issuer to the Payment network, back to the Acquirer and back to the Merchant where your receipt gets printed.

In conclusion, we saw how ApplePay does provisioning and how a payment transaction is processed. For some of us this is good enough information to understand the security strategy used by ApplePay. But some others may have more questions. What happens when the Card is lost? What happens when the phone is lost? What happens when the merchant is compromised? How does ApplePay handle these challenges? These are all very good questions, but this post has already become too big. So, I will address those follow-up questions in my next post. Stay tuned!

Reprinted from my own article here

Mobile Payments: What is HCE?

http://www.gmarwaha.com/blog/mobile-payments-faq/

What is HCE?

Previously, we discussed about Secure Element and how it enables payment transactions in card-emulation mode. We also briefly discussed that SE is not the only choice available. Today, we also have HCE as an alternative. HCE stands for Host-based Card Emulation. As its name suggests, it has something to do with card-emulation mode. But what does host-based mean? Before we talk about what host-based means, let’s review how things were before HCE.

Prior to HCE, the only way to emulate a card using a mobile NFC device was to use a Secure Element. Let’s take the Android platform as an example. Here, the host operating system (Android in this case) and its apps do not get involved with a payment transaction at all.

se-ce

When a consumer holds the device over an NFC terminal, the NFC controller in the device routes all data from the reader directly to the Secure Element. The Secure Element itself performs the communication with the NFC terminal, and no Android application is ever involved in the transaction. After the transaction is complete, an Android application can query the Secure Element directly for the transaction status and notify the user. This is the approach used by ApplePay as well

This SE based approach is inherently secure and that is a very big advantage. But, there are some downsides too. The SE owner owns the key to the kingdom. All others will have to go through complex business models, partnerships, and dependencies to gain access and it makes the whole process that much more complex and expensive. Moreover, the SE itself has only limited storage capacity and processing speed.

The alternative is to use Host-based Card Emulation. Here, the host operating system (Android) and its apps gets involved with a payment transaction.

hce-ce

When a consumer holds the device over an NFC terminal, the NFC controller in the device routes all data from the reader directly to the Host CPU on which Android applications are running directly. Then, an Android application (a Mobile Wallet) that deals with a particular payment application can do its magic and provide for the card emulation requests and responses.

Since the host CPU is inherently insecure, any mobile wallet worth its salt will not store the real payment credentials inside the phone. Google Wallet for example moves all such data to a hosted cloud environment, and that is where the secure storage and secure processing takes place. In essence, we have moved the Secure Element from inside a chip to a cloud environment (HCE Cloud) instead.

This approach has its downsides – like security and a need for data connection. This does not mean that your private information is vulnerable. We can still have a very high degree of security using other technologies. Payment card Tokenization is one of them and we will discuss it in an upcoming post. On the bright side, the complex business models, partnerships and access restriction to SE can be dramatically simplified. This enables payment application issuers to easily provision to the cloud and get it over with.

Using SE-based Card Emulation and Host-based Card Emulation is not an either-or scenario though. Android allows both to co-exist in the same NFC enabled device and offers tools and technologies to work with both of them as shown in the diagram below.

se-hce-dual-ce

All the above diagrams were taken from Android developers website.

Mobile Payments Blog Series

Welcome to the Mobile payments FAQ and not so FAQ series and you are on FAQ #15. The idea behind this series is to share and learn as much as possible about the field of mobile payments. If you like, you can read all of the FAQs on the Mobile Payments category or by visiting the Table of contents page.

Mobile Payments: What is a Secure Element?

http://www.gmarwaha.com/blog/mobile-payments-faq/

What is a Secure Element (SE)?

GlobalPlatform defines Secure Element (SE) as a tamper-resistant platform capable of securely hosting applications and their confidential and cryptographic data in accordance with the rules and security requirements set forth by a set of well-identified trusted authorities. Put simply, a Secure Element can be considered to be a chip that offers a dynamic environment to store data securely, process data securely and perform communication with external entities securely. If you try to mess with it by tampering in any form, it may self-destruct, but will not allow you to gain unauthorized access.

While not all NFC applications require security, those that involve financial transactions do. The Secure Element resides in highly secure cryto chips. It also provides delimited memory for each application stored in it and other functions that can encrypt, decrypt and sign the data packet.

In today’s smartphones, a Secure Element can be found as a chip embedded directly into the phone’s hardware, or in a SIM/UICC card provided by your network operator or in an SD card that can be inserted into the mobile phone.

To put things into context, when you are using an NFC enabled mobile device to Tap & Pay, the NFC controller goes into card-emulation mode. The NFC controller itself does not deal with the data or processing associated with the payment transaction. It is just an interface that allows communication using standard protocols.

It is the Secure Element that actually emulates the contactless card. It performs handshake with the terminal, sends the right responses to the right queries, generates dynamic cryptograms, authenticates the stored card and so on.  To take it a step further and be even more accurate, it is not the Secure Element that emulates the card. The software that emulates a contactless card is the one that is stored inside the secure element in the form of payment applications or applets. The Secure Element provides secure storage and execution environment for the payment applications to do its job.

Secure Element is not a necessity to emulate contactless cards although it is the most secure to date. An alternative is to use Host-based Card Emulation (HCE) which moves the secure storage and execution environment to the cloud instead of the Secure Element. We will discuss HCE next.

Mobile Payments Blog Series

Welcome to the Mobile payments FAQ and not so FAQ series and you are on FAQ #14. The idea behind this series is to share and learn as much as possible about the field of mobile payments. If you like, you can read all of the FAQs on the Mobile Payments category or by visiting the Table of contents page.

Mobile Payments: What is NFC Card Emulation Mode?

http://www.gmarwaha.com/blog/mobile-payments-faq/

What is NFC Card Emulation Mode?

An NFC enabled device can operate in three different modes – reader/writer mode, peer-to-peer mode and the all important card-emulation mode.

In Reader/Writer mode, an NFC device behaves as a reader for NFC tags, such as the contactless smart cards and RFID tags. It detects a tag immediately in close proximity by using collision avoidance mechanism. Once detected, it can either read data from or write data to the detected tag. Smart posters are an important application for this mode.

In Peer-to-Peer mode, two NFC enabled devices can exchange information between each other. This is the mode used by Android Beam technology. Exchanging photos, business cards and money transfer between friends are some of the applications for this mode.

In Card-emulation mode, an NFC device behaves like a contactless smart card. In this mode, the mobile phone does not generate its own RF field; the NFC reader creates this field instead. So, as long a mobile platform supports the emulation of protocols surrounding ISO/IEC 14443 that regular contactless cards use, we should be good. Both Android and Blackberry does that and can therefore be used to emulate contactless cards. In this mode, we can use our mobile phone in place of credit cards, debit cards, transit cards, access cards and so on.

Mobile Payments Blog Series

Welcome to the Mobile payments FAQ and not so FAQ series and you are on FAQ #13. The idea behind this series is to share and learn as much as possible about the field of mobile payments. If you like, you can read all of the FAQs on the Mobile Payments category or by visiting the Table of contents page.

Mobile Payments: What is NFC?

http://www.gmarwaha.com/blog/mobile-payments-faq/

What is NFC?

NFC stands for Near Field Communication. It is a standard defined by the NFC Forum, a global consortium of hardware, software, credit-card, banking, network-providers and others who are interested in the advancement and standardizing this technology. As the name implies, it’s a set of short-range wireless communication standards used in mobile phones and other electronic devices. It operates on the frequency of 13.56 MHz with data transfer of up to 424 kilobits per second.

NFC and RFID (Radio Frequency Identification) are sometimes used interchangeably, but NFC is really a newer version or extension of RFID. RFID waves can have very long ranges as they are generally used in manufacturing, inventory and object tracking. In contrast, NFC limits the range of communication to within 2 to 4 inches. This makes NFC more suitable for secure applications like payments.

NFC allows you to share small payloads of data between an NFC tag and an NFC enabled phone or between two NFC enabled phones. This may sound more like Bluetooth because it is also a communication technology between two bluetooth enabled devices over a short range. Yes, they are similar in that aspect, but they are also different in other aspects. For instance, NFC doesn’t need a pairing process; it can read from passive NFC tags; it consumes low power; it connects to its target very quickly ( one tenth of a second) etc. These qualities make NFC a good candidate for mobile payments. Bluetooth has other advantages that makes it a better choice for a different set of use cases. We will discuss about Bluetooth, BLE and Beacons in a different post.

 

Contactless cards, that we discussed in an earlier post, behave like NFC tags and emit NFC style radio frequency signals when provoked by a contactless reader terminal. So, in theory, a mobile phone with an NFC controller can do the same as long as they conform to the protocols defined by payment networks. And that is exactly what is happening when you use a Google or Isis wallet. We will discuss how this happens in practice in an upcoming post on card-emulation mode for NFC.

So, can you just replace all of your contactless credit and debit cards with Google wallet or Isis wallet and call it a day. Not yet. There are a couple of reasons for that.

First and foremost, today, contactless terminals/readers are not plentiful. There are just over 200K contactless terminals across US. The advantage of using your contactless plastic card is that it also comes with a magstripe for backward compatibility with traditional terminals. We do not have that luxury with an NFC enabled phone.

Second, provisioning a contactless application to an NFC enabled phone is a much more complicated process involving a larger ecosystem of participants like SP TSM, SE TSM, MNO, Issuing banks and the complexity involved with security, key management and over-the-air provisioning cannot be discounted either. Technically, these have been solved, but not all Issuing banks are ready to invest in it yet. That said, the industry is slowly, yet steadily moving towards a digital wallet. So, it is going to happen sooner rather than later, but don’t hold your breath.

Mobile Payments Blog Series

Welcome to the Mobile payments FAQ and not so FAQ series and you are on FAQ #12. The idea behind this series is to share and learn as much as possible about the field of mobile payments. If you like, you can read all of the FAQs on the Mobile Payments category or by visiting the Table of contents page.

Mobile Payments: What is a Mobile Wallet?

http://www.gmarwaha.com/blog/mobile-payments-faq/

What is a Mobile Wallet?

Mobile Wallet, like Mobile Payments, is an overloaded phrase. It means different things to different people. For the sake of simplicity, let’s define the mobile wallet as an app or a set of apps that helps us to get rid of the physical wallet. That was a pretty slick definition, wasn’t it? To make the above definition a reality, what items should the mobile wallet hold? Let’s make a list.

  • Credit cards & Debit cards
  • Gift Cards
  • Loyalty Cards
  • Driver’s License or any Identity proof
  • Receipts
  • Cash
  • Business Cards
  • Coupons, Offers
  • Transit passes / tickets
  • Movie tickets
  • A mechanism to use all of the above everywhere

If a mobile wallet gives us all the above, then we can conveniently get rid of our fat physical wallets. We are not there yet, but sooner rather than later, we will get there. Today, many of the large tech and financial giants are focussing their efforts on the mobile payment side of things – Google and Paypal are good examples. Other giants are focussing on the non-financial aspect of wallets – Apple’s passbook comes to mind. As time passes, the industry will mature, concepts will merge, new innovations will take place, and before we know it we won’t be carrying our physical wallets anymore. Did we ever think that we will never wear a watch again, or never carry a point-and-shoot camera to our next pleasure trip?

Mobile Payments Blog Series

Welcome to the Mobile payments FAQ and not so FAQ series and you are on FAQ #11. The idea behind this series is to share and learn as much as possible about the field of mobile payments. If you like, you can read all of the FAQs on the Mobile Payments category or by visiting the Table of contents page.

Mobile Payments: What is Mobile Payment?

http://www.gmarwaha.com/blog/mobile-payments-faq/

What is Mobile Payment?

Mobile Payment is one the overly hyped phrases in the industry today. It could mean a lot of different things in different contexts. In general, Mobile Payment means that as a consumer you can use your mobile device to make payments instead of paying by Cash, Check, Credit Card, Debit Card or any other payment mechanism. It could also mean that you could use your mobile device to accept payments from others; or, it could mean that you can use your mobile to pay a friend back; or just pay a bill. You get the idea.

Let’s start a list of things we can do with mobile and payments in this post. We will keep adding to the list as we find more.

  • Mobile at the Point of Sale
    • Tap & Pay using your Mobile NFC device – Google Wallet, Isis
    • Scan a QR code using your mobile’s camera to make a payment – Paydiant
    • Show a QR code displayed on your mobile at the POS – Starbucks Wallet
    • Pay using Mobile BLE and iBeacon technology and the Cloud – Paypal
    • Simulate Magnetic Stripe signals – LoopPay
  • Mobile Point of Sale (mPOS)
    • Mobile card reader dongle to accepts payments – Square
    • Fully integrated tablet based POS system – ROAM
  • P2P payments – Person to Person
    • Pay a friend using their phone number – PayM
    • Pay a friend using their email address – PayPal
    • Pay a friend by bumping the phones together – BumpPay
    • Transfer money between different bank accounts – Bank apps
  • mCommerce
    • Pay in apps using digital wallet – Pay with Paypal
    • Pay across apps – Venmo Touch
    • Pay in mobile web sites – Regular mobile checkout
    • Pay utility bills using your mobile device
  • Old Fashioned
    • Pay using SMS – Premium SMS or MMS
    • Direct carrier billing

Mobile Payments Blog Series

Welcome to the Mobile payments FAQ and not so FAQ series and you are on FAQ #10. The idea behind this series is to share and learn as much as possible about the field of mobile payments. If you like, you can read all of the FAQs on the Mobile Payments category or by visiting the Table of contents page.

Mobile Payments: What is EMV?

http://www.gmarwaha.com/blog/mobile-payments-faq/

What is a EMV?

EMV is defined by EMVCo as, “a global standard for credit and debit payment cards based on chip card technology”. It was named after its original developers – Europay, MasterCard and Visa. EMVCo is the organization that manages, maintains and enhances the EMV specifications.  Today, EMVCo is owned by American Express, Discover, JCB, MasterCard, UnionPay, and Visa. Other organizations from the payments industry also participate as technical and business associates from time to time.

EMV chip cards contain embedded microprocessors that provide strong authentication, security and cryptography features not possible with traditional magnetic stripe cards. In addition to storing payment information in a secure chip rather than a magnetic stripe, using EMV improves the security of a payment transaction by adding 3 important features:

Card Authentication:

Card authentication protects the payment system against counterfeit cards. Card authentication methods are defined in the EMV specifications and the associated payment network chip specifications. Card authentication can take place online, offline or both.

Cardholder Verification:

Cardholder verification authenticates the cardholder. Use of a PIN is a common cardholder verification method (CVM) that authenticates the cardholder and protects against the use of lost or stolen card. EMV supports Online PIN, Offline PIN, Signature and No CVM as part of its specifications. As mobile payments grow new CVMs, in the form of finger-print, voice and device PIN may also get added to the list

Transaction Authorization:

For an online transaction authorization, EMV supports the notion of a dynamic transaction cryptogram. The presence of the dynamic component completely eliminates replay style attacks. EMV supports both online authorization and offline authorization based on rules and risk-parameters set by the Issuer

The Contact chip cards and Contactless chip cards that we discussed in earlier posts can comply to the EMV specification and reap its security advantages. In fact, all of the contact and contactless chip cards in Europe are created using the EMV specification. At present, contact chip cards are in very limited use in US, but the good news is that they are migrating towards it and they are using EMV as the underlying specification.

In contrast, many US banks did offer contactless chip cards over the last few years. These cards did not follow the EMV specification. They instead used a complementary Contactless MSD specification which is an equivalent to regular magenetic stripe data, but a bit more secure. They chose to use MSD because US does not have the EMV infrastructure setup yet. As and when the migration towards EMV matures, these existing contactless MSD cards will also be migrated to Contactless EMV cards or that is what I think.

Mobile Payments Blog Series

Welcome to the Mobile payments FAQ and not so FAQ series and you are on FAQ #9. The idea behind this series is to share and learn as much as possible about the field of mobile payments. If you like, you can read all of the FAQs on the Mobile Payments category or by visiting the Table of contents page.

Bring Your Own Wallet

Today, the mobile wallet is an overused buzzword discussed and debated by a variety of industries. Payment companies, financial institutions and merchants of all sizes are all vying for consumer attention. Technology companies, mobile network operators (MNOs), start-ups and even marketing companies are joining forces to innovate in this space. Though many are talking about it, asking a simple question like what is a mobile-wallet? brings surprisingly different answers depending who you ask.

The competition heats up

A question often asked is who could win the ‘wallet wars’ in the years to come? Isis Wallet was launched just a few weeks ago and is heavily backed by three of the top MNOs (Verizon, AT&T and T-Mobile). Google Wallet has finally escaped the clutches of MNOs by introducing Host-Card emulation in Android Kit-Kat. Are they in a position to reverse their wallet downfall? PayPal has started piloting their in-store beacon payment experience. With over 100 million credit-cards on file, is PayPal going to be the winner again? Will MCX wallet, with its support from all major retailers, be the Holy Grail for merchants? Can Square re-create their m-POS success in the wallet world? Apple’s passbook shows huge potential by itself. With the subsequent introduction of finger-print biometric and iBeacon in iOS7, is Apple in a better position than others?

Generic vs. merchant

These questions, however, are based on an assumption that a multi-purpose generic wallet will emerge as the winner. Considering that the mobile payments revolution is still in its nascent stages, it’s too early to assume that a single generic wallet will triumph over a merchant-specific wallet such as a Starbucks wallet. Starbucks claims that more than 10% of store sales are driven by its mobile wallet app and is the only success story in this space. The generic wallet fails to provide any credible proof to challenge this. So, the real question is: who will win the generic wallet vs. merchant-specific wallet war?

As far as merchants are concerned, this question need not be fully answered before they dive into their mobile wallet initiative. Here’s why: most of the wallets mentioned above try to solve the mobile payment challenge. But payment is just one part of the larger wallet ecosystem. Until other ambitious players solve the mobile payment challenge, merchants can use stop-gap payment solutions while focusing on the rest of the wallet ecosystem.

Bring Your Own Wallet

The most practical approach then would be for a merchant to follow the mantra, ‘your app is your mobile wallet.’ By building your own-brand mobile wallet, you can access customer profile information (demographics, purchase behavior, spending patterns) and track transactions which would otherwise be sold to competitors. Combining such valuable information with unique capabilities that smartphones offer, new and innovative solutions can be created to boost your sales, up-sell, cross-sell and elevate customer experience to a whole new level in several different ways:

  1. Improve the in-store shopping experience and customer engagement: staff can be equipped with mobile POS devices; in-store navigation can assist customers to the exact location of a particular product; access to store inventory can identify if a particular product is in stock; product comparison and user reviews can strengthen customer confidence; mobile ordering, smart-checkout and in-store pickup can reduce queue wait times.
  2. Increase customer loyalty and invite repeat-visits: access to digital loyalty/reward cards from the wallet; real-time rewards information access; creating badges and rewards gamification to increase customer spend; geo-fencing, to check-in customers and offer a personalized experience.
  3. Increase customer base using innovative offers: offering location based offers when the customer is in vicinity of the store; iBeacon technology to identify if a customer is checked into the store and leveraging that for targeted sales to motivate in-store purchases. This can also be used to bring your mobile wallet to the forefront without getting hidden in the fourth home screen.
  4. Support a payment solution that works today: use a stored-value digital card that the customers can refill with their linked bank accounts; or use a white-label mobile payment provider like Paydiant if you prefer to support all card networks from your mobile wallet. Regardless of payment option chosen, integrate it with your rewards program; offer additional incentives for consumers who use your mobile-wallet; ensure tight integration between the mobile payment system and the rest of the mobile-wallet ecosystem.
  5. Support generic mobile payment providers when they finally figure it out: eventually, the generic wallet providers will figure out a standardized way to make a payment at the physical or virtual POS. Design your mobile strategy to be flexible to support them so you don’t lose generic wallet customers. Your own loyal customers can be appropriately incentivized to continue using your mobile wallet.

Remember, the existing magnetic-stripe based card payment experience is not broken. It works, customers understand it and more importantly, they are happy with it. So, payment is not the problem you need to solve. Neither should you wait for generic wallet providers to solve the m-Commerce challenge for you. By placing your bet on your own unique mobile wallet today, you can focus on creating what adds value – a new and improved relationship with your customer and rewarding them with a pleasurable shopping experience.

The article was originally published on bobsguide on May 8, 2014 and is re-posted here by permission.

Mobile Payments: What is Tap & Pay?

http://www.gmarwaha.com/blog/mobile-payments-faq/

What is Tap & Pay?

 

When we use a Contactless Card to tap on the Contactless reader to make a payment, instead of swiping a magstripe card, we are essentially using Tap & Pay technology. The same goes for any NFC enabled mobile device that support Card Emulation Mode – like Android and Blackberry. Tap & Pay is just a marketing terminology. You may also see it referred to as Tap-n-Pay, Tap to Pay, Tap & Go, Wave & Pay and so on.

Mobile Payments Blog Series

Welcome to the Mobile payments FAQ and not so FAQ series and you are on FAQ #8. The idea behind this series is to share and learn as much as possible about the field of mobile payments. If you like, you can read all of the FAQs on the Mobile Payments category or by visiting the Table of contents page.