Mobile Payments: What is a Contactless Chip Card?

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

What is a Contactless Chip Card?

Contactless chip cards are standard credit cards with an embedded contactless chip. Optionally, a MagStripe is also provided for backwards compatibility. These cards require no physical contact with the point-of-sale (POS) terminal. To make a payment, the consumer holds the contactless card in close proximity (less than 2-4 inches) to the merchant POS terminal and the payment account information is communicated wirelessly via Radio Frequency (RF).

Radio frequency waves are the frequencies within the electromagnetic spectrum associated with radio wave propagation. Many wireless communications technologies are based on RF, including radio, television, mobile phones, wireless networks and now, contactless payment cards and devices. Don’t confuse this RF with RFID technologies used in manufacturing, shipping and object tracking. Those are designed to operate over long ranges (in the order of 25 feet) and typically don’t have built in security and privacy. On the other hand, the contactless cards that are used for payments are desgined to operate at a short range and come built-in with security and cryptography capabilities.

In the image above, the logo marked on the right hand side represents the universal contactless symbol. If you see this logo on your credit card, you can be sure that it supports contactless payments. Similarly, POS devices that support contactless payments prominently display the same logo to advertise their capability for the same.

Typically, when you make a payment with contactless cards, you are not required to enter a PIN or autograph your signature. This is intentional because, one of the most touted value-add features provided by a contactless card is fast checkout times. Consequently, they are sometimes also referred to as Tap & Go cards.

In the context of mobile payments, when you use a NFC mobile device (like Android or Blackberry) to Tap & Pay at the point of sale, you are actually using the same underlying technology as the Contactless Chip Card. The NFC controller chip inside the mobile device is put into card-emulation mode. In this mode, the NFC chip behaves like a Contactless chip card thereby transforming your mobile phone into a contactless credit card.

Since mobile phones are way more powerful than a plastic card, they can hold as many cards as you want and the NFC chip will be able to simulate any or all of them. This essentially turns your mobile phone into a virtual mobile wallet. Now you know where the concept of Mobile wallets origintated from.

Mobile Payments Blog Series

Welcome to the Mobile payments FAQ and not so FAQ series and you are on FAQ #7. 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 Contact Chip Card?

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

What is a Contact Chip Card?

Chip cards are standard bank cards that are embedded with a micro computer chip instead of or in addition to a Magstripe. It is an evolution in our payment system that will help increase security and reduce fraud in a card-present environment. A cardholder’s confidential account data is more secure on a chip-enabled payment card than on a MagStripe card, as the former supports dynamic authentication, while the latter does not. This prevents fraudsters from easily copying account information and creating counterfeit cards.

In United States, MagStripe cards are more common-place although a migration towards chip cards is currently underway from all major card networks and Issuing banks. In UK, Chip cards, more specifically the Chip-and-PIN variety is ubiquitous while MagStripe cards are almost extinct.

This post explicitly discusses contact chip cards, which requires direct contact with the reader to establish communication with each other during a payment transaction. There is also a contactless chip card variant that we will discuss in the next post.

Contact Chip cards may come as Chip-and-PIN or Chip-and-Signature cards. Chip-And-PIN cards are used to verify the cardholder by asking them to enter a PIN during transaction authorization whereas Chip-and-Signature cards use traditional signature for cardholder verification. PIN is generally considered a more secure method of cardholder verification than PIN. But, the credit card platform in United States is not built to support PIN. So, you would generally see only Chip-and-Signature cards in US.

Mobile Payments Blog Series

Welcome to the Mobile payments FAQ and not so FAQ series and you are on FAQ #6. 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 Magnetic Stripe Card?

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

What is a Magnetic Stripe Card?

The most commonly available type of credit and debit card in the United States is a Magnetic Stripe or MagStripe card. As shown below, the black band on the back of your card is the magnetic stripe. It stores information by modifying the magnetism of tiny iron-based magnetic particles. The stored data can be read by swiping past a magnetic reading head, which is what you do when you swipe your credit card in a point of sale terminal.

Credit_Card_Mag_Stripe

The MagStripe holds your account information encoded in the form of Tracks – Track 1 and Track 2. They both hold similar information. Given below are some details.

 Track 1 Data:

  • Primary Account Number (PAN) – This is your credit card number
  • Name
  • Expiration Date
  • Service Code
  • Discretionary data – Contains CVV code among other data

 Track 2 Data:

  • Primary Account Number – This is your credit card number
  • Expiration Date
  • Service Code
  • Discretionary data – Contains CVV code among other data

Other than the fact that Track 1 stores your name while Track 2 doesn’t, there are a few other technical details associated with each which is not important for our discussion. Point of sale card readers read either Track 1 or Track 2 or both depeding on how they are programmed. Rest assured, information in either one of the tracks is enough to complete a purchase transaction.

Mobile Payments Blog Series

Welcome to the Mobile payments FAQ and not so FAQ series and you are on FAQ #5. 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: Who is a Payment Network?

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

Who is a Payment Network?

If credit card payments was a software project, then payment network is the project manager. The logo that you see on your credit card that says Visa or MasterCard is nothing but the name of a Payment Network. They are also otherwise called as card network or payment brand or just network. It is important to remember that card networks do not issue cards to the layman. Issuers issue cards.

When we discussed about Acquirers, I mentioned that the Acquirers don’t directly maintain a link to every other Issuer under the sun; instead they maintain a link to every major card network. Card networks in-turn maintain a link with every Issuer that issues their network branded cards. In essence, they are the intermediary between Acquirers and Issuers for authorizing credit card transactions.

There are various other functions that a card network performs. They manage the brand reputation and marketing. They facilitate clearing and settlement. They set rules that govern payment transactions within their network and enforce them. They set standards for security, compliance and certification. And much much more…

Out of the major card networks, Visa has the largest market share, followed by Master Card, American Express and Discover in that order.

Mobile Payments Blog Series

Welcome to the Mobile payments FAQ and not so FAQ series and you are on FAQ #4. 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: Who is a Merchant?

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

Who is a Merchant?

 The retailer store that you walk-in to shop is called a Merchant in payment speak. You can broadly categorize them into two types based on channel.

Brick & Mortar merchants, also called as physical merchants, have a physical store. You would walk in to the store and purchase items by swiping a card at the physical point of sale (POS) device. In the context of mobile payments, they may also allow you to Tap & Pay using your mobile NFC device. In a restaurant kind of setup, you would typically hand over your card to the waiter instead of walking up to the counter. In such establishments, you may also scan a QR code to pay using your mobile. We will discuss Tap & Pay and QR code based mobile payments in upcoming posts.

Online merchants – both eCommerce and mCommerce, do not have a physical store. To make a purchase, you would visit their website and use a virtual shopping cart. Depending on how much you frequent that merchant, you may choose to type in your credit card details every time you purchase, or choose to store your card on their file, so that you can just select a stored card to pay. In addition to the above, you may also use a digital wallet (or mobile wallet) to make a purchase without entering your card details everytime and without storing your card with the merchant themselves.

These days, almost all physical merchants also have an online presence and mobile presence thereby transforming themselves into omni-channel merchants.

Mobile Payments Blog Series

Welcome to the Mobile payments FAQ and not so FAQ series and you are on FAQ #3. 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: Who is an Acquirer?

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

Who is an Acquirer?

A merchant or a retailer store cannot just accept cash. They have to accept credit cards and debit cards to get your business. In order for them to get paid for a credit card transaction, they have to first authorize your transaction with the corresponding Issuer bank every time you swipe. But there are just thousands of such Issuer banks. You may be holding a credit card from any one of the thousands of banks. If every merchant had to establish a direct link and relationship with every other Issuer bank in the country, the system would have fallen apart long time ago.

An Acquirer is the entity that helps a Merchant to accept credit card and debit card payments. They are sometimes referred to as the Merchant Acquirer or the Acquiring Bank as well.

In this setup, a merchant establishes connectivity and relationship only with their Acquirer and nobody else. The Acquirer will in-turn maintain their own link to every other bank. To be accurate, the Acquirer doesn’t maintain a link with every other bank either; instead they connect only to the major payment networks like Visa, MasterCard, American Express, Discover and so on. The payment networks in-turn maintain a link with all their respective Issuers.

Acquirers do a lot more than just assist in authorizing transactions. They help with clearing and settlement. They manage chargebacks, refunds and disputes. They own the responsibility if a merchant goes belly-up. This list goes on, but you get the idea. Bank of America, Chase Paymentech and Wells Fargo are examples of Acquirers.

Often times an Acquirer outsources their work to external entities called Acquirer Processors. They process transactions on behalf of the acquirers by connecting merchant transactions to payment networks. They also provide the POS device, securely route transactions from the POS to the payment network, manage authorization, clearing and settlement. They may also have tie-ups with sub-processors, ISOs and other partners to get the job done. First Data, Elavon and TSYS are examples of Acquirer Processors.

Mobile Payments Blog Series

Welcome to the Mobile payments FAQ and not so FAQ series and you are on FAQ #2. 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: Who is an Issuer?

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

Who is an issuer?

An Issuer is the bank who issues you the credit card, debit card or any payment card for that matter. They are sometimes referred to as the Issuing Bank as well. For example, if you have a Chase Freedom card, then your Issuer is Chase bank. If you own a Capital One Platinum card, then your Issuer is Capital One bank.

What if you have a Marriott Rewards credit card? No, Marriott is not your issuing bank. In general, when you get a credit card from an establishment other than a bank, maybe from a merchant like Marriott, it is only because they have tied up with some bank. It is the bank that manages the back-end work, while the branding is done with the merchant’s name on it. In the case of Marriott, the issuing bank is Chase.

Also, remember that Visa and Master Card are not issuers. They are called Card Networks, or more generally, the Payment Networks. We will discuss them in another post.

In the context of a payment transaction, an Issuer is the entity that authorizes the transaction when you swipe your card at a point of sale. They pay the merchant from their customer’s account through a process called Clearing and Settlement. They also charge Interchange fees, which is generally collected from the merchant. Bank of America, Chase and Wells Fargo are a few of the largest Issuers.

Sometimes Issuers outsource card processing activities to external entities called Issuer Processors. Issuer Processors may take on some or all the activities of card processing from the Issuer depending on their contract. First Data, FIS and TSYS are examples of Issuer Processors.

Mobile Payments Blog Series

Welcome to the Mobile payments FAQ and not so FAQ series and you are on FAQ #1. 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: FAQ and not so FAQ

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

I have been working in the field of payments, specifically mobile payments for quite sometime now. If you haven’t noticed, a lot is happening in that area. The players in this field keep coming up with new stuff all the time; the field keeps coming up with new players all the time. Some of them just make sense, but some just don’t regardless of how hard we think. It is not their mistake. They are trying out new and innovative ideas hoping that one of them will click.

Mobile payments come with a lot of variables and not everyone has the knowledge or patience to understand all of them equally well. For instance, a credit card expert may not understand how HCE (Host Card Emulation) is affecting the SE (Secure Element); while an NFC expert may not understand how a Card network gets involved in tokenized transactions.  Apparently, it is not a surprise that many questions come to our mind that needs an answer – a short and simple answer.

My goal here is to try and answer these FAQs and not so FAQs for my benefit and reference. I plan to use a question/answer format where each question is answered in one short and simple blog post. As a general rule, I will prefer simplicity to absolute accuracy, because i don’t like my learning to be limited by some fine-print details. In many cases, I will restrict the details to the context of mobile payments to avoid information over-bloat.

I am confident that this will benefit me and hopefully it will benefit others too. I am also hoping that any expert stumbling across these blogs will offer their valuable thoughts thereby helping the rest of us.

Welcome to Mobile Payments FAQ and not so FAQ series. View all posts from the Table of Contents page

SQLite Auto Increment

In SQLite, the primary key column get auto-incremented by default. So, my thought was that there was no necessity to set the autoincrement flag explicitly in the create table DDL. Then I discovered a hard truth. When I don’t set the autoincrement flag explicitly, it does auto-increment, but there is a minor issue. It so happens that SQLite has two algorithms to perform auto-increment in primary keys – a default one where you don’t explicitly set the flag and an other one where you explicitly set the flag.

To understand the glitch, let’s consider an example. Assume that you have a table with 5 rows with IDs 1, 2, 3, 4 and 5. The default algorithm increments the highest value in the ID column by 1. If you add a new row to this table, it automatically gets an ID of 6. Now, let’s delete the row with ID #6. You are left in the same state you started – 5 rows with IDs 1, 2, 3, 4 and 5. Let’s add a new row once again. This new row again gets an ID of 6.

This may have disastrous consequences or no consequences at all depending on your scenario. Generally, the autoincrement behavior that is expected out of a database is not this. I would expect the last row to get an ID of 7 instead since the PK column will not be reused. That brings us to the other algorithm. If I explicitly set the autoincrement flag in the create table DDL, the row that was added last correctly gets an ID of 7 instead of 6. This behavior is consistent with other databases. Not a big issue at all depending on your scenario. But, just be warned.

Android: Remove activity from history stack

In most Android REST-Client applications, the first screen a user sees is either a Login or Registration screen. Once the user logs in, the user is generally taken to a Dashboard screen or to some other Home screen. Now, What do you think will happen if the user presses the back button? Won’t they be taken back to the Login Screen? That is not good design, Is it? The issue is no different even when we show a Blank/Splash screen while automatically logging the user in based on their saved credentials. In fact in the second case it is worse. The user gets to see a Blank screen when they press the back button.

To avoid this behavior, we have to tell android to remove the Login screen from the display/history stack once its job is complete. There are a variety of ways to do this. The easiest way is to give the LoginActivity a “android:noHistory = true” attribute in the manifest file. That instructs Android to remove the given activity from the history stack thereby avoiding the aforementioned behavior altogether.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
          package="com.example.activity"
          android:versionCode="1"
          android:versionName="1.0">

  <application android:name="MyApp" android:label="My Application">

    <activity android:name=".LoginActivity" android:noHistory="true">
      <intent-filter>
        <action android:name="android.intent.action.MAIN"/>
        <category android:name="android.intent.category.LAUNCHER"/>
      </intent-filter>
    </activity>

  </application>
</manifest>

In other similar circumstances, we may want a similar but dynamic behavior where we would like to choose at runtime, if an activity should be removed from the history stack or not. In those cases we can use Intent.FLAG_ACTIVITY_NO_HISTORY intent flag to achieve the same feature dynamically.

There is a cornucopia of other Intent flags available and documented here for our usage pleasure. They may render themselves useful under other circumstances. Have fun learning them all…