Mobile Payments: Who is a Merchant?

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?

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?

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

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…

Tomcat & IntelliJ – Deploy war files outside webapps folder

At present I am working on developing an Android application that needs to be supported by a slew of REST services hosted in the cloud. I chose Google App Engine based on its support for Java, Groovy and most importantly Spring. I developed a Spring MVC based REST application and used ContentNegotiatingViewResolver to negotiate content based on request URL extensions. For example, an XML response will be returned if the request URL ends with .xml, a JSON response for .json and an HTML response if he URL doesn’t have any extension. Don’t get me started on Accept Header versus URL extension based content negotiation. That is a rant for another day.

I was attempting to Serialize a Map<Enum, List<Model>>. All was well and I was able to retrieve both HTML and JSON representations, but when I tested retrieving the XML representation, JAXB complained that it cannot handle a Map instance in the root although Jackson was totally cool about it. As usual, Googling revealed that JAXB expected a Container class at its root which I didn’t want to create. I didn’t want to give up either. So, I tried my luck using XStreamMarshaller. This time GAE complained that XStream used a restricted API. WTH?

Just out of curiosity, I wanted to check if XStreamMarshaller would work as expected when used outside of GAE. So, I created a Tomcat context file “myapp.xml” with the following definition and carefully placed it inside TOMCAT_HOME/conf/Catalina/localhost. I could have just started Tomcat from TOMCAT_HOME/bin/startup.bat to check if it works, but being an IDEA addict, I created a Run Configuration for the IDEA Tomcat plugin and started the server from inside IDEA. But the app refused to even be discovered, let alone be deployed. After a few frustrated attempts, I tried starting Tomcat directly outside IDEA. Thankfully the app got deployed successfully and to my surprise, the XStreamMarshaller skillfully streamed out the serialized XML. Problem Solved!

<?xml version='1.0' encoding='utf-8'?>
<Context docBase="PATH_TO_MY_APP"
         reloadable="true"
         path="/myapp">
</Context>

But, why didn’t the app get deployed when I started Tomcat from inside IDEA? After all, I have linked IDEA to my local Tomcat installation and the script it executes is clearly in my TOMCAT_HOME/bin folder. Then, why why why in the world does the app refuse to be discovered? The solution came in the form of CATALINA_BASE. It seems that IDEA copies the contents of TOMCAT_HOME/conf folder into its HOME folder with some name like Unnamed_MyApp and sets this folder to be the CATALINA_BASE. That explains why “myapp.xml” is so totally ignored by Tomcat. Then, I navigated to “Tomcat Run Configuration -> Startup/Connection -> Environment Variables” and added CATALINA_BASE as an environment variable and pointed it to your local TOMCAT_HOME folder. After this configuration change IDEA started Tomcat as expected and my app was both discovered and deployed. Another Problem Solved!

But the real problem – JAXB complaining about Map and GAE rejecting XStreamMarshaller as restricted – is yet to be solved. Maybe I should try one of the CastorMarshaller, XmlBeansMarshaller or JibxMarshaller.

Any ideas?

No hadoop-env.sh in Hadoop 0.23

The first thing to do after downloading and extracting Hadoop is to set JAVA_HOME in the $HADOOP_HOME/conf/hadoop-env.sh file. Almost all documentation on Hadoop site expects the above configuration but I guess that was for version 0.20. When I downloaded Hadoop 0.23 today and looked for the hadoop-env.sh file, I could not find it anywhere in the extracted archive.

After a bit of Googling I realized that things have changed in 0.23 version and now I will have to look for the file in the $HADOOP_HOME/etc/hadoop directory instead. Unfortunately I couldn’t find the file there either.

As a last resort I created a file named hadoop-env.sh in the $HADOOP_HOME/etc/hadoop directory and set my JAVA_HOME there. The one and only line in that file is given below. Fortunately after that addition, the hadoop command started working and everything went normal again.

export JAVA_HOME=/usr/lib/jvm/java-6-openjdk/

jQuery UI: Calling widget methods directly

A typical jQuery plugin is just another function attached to the jQuery object. As a plugin developer you write a function, attach it to jQuery.fn (just an alias for its prototype) and your plugin method is magically available to all jQuery instances. As a plugin user, you normally execute the plugin by calling a method on the jQuery object. Something like 

// jCarouselLite is the plugin in this case
$("#carousel").jCarouselLite(options);

The above call returns the jQuery object on which the plugin was originally invoked. That way you can chain method calls and marvel at the beauty of our wide one-liner solution. But not for long!!!

What if you would like to control the behavior of the plugin after initialization? What if you want to stop() what the plugin is doing, maybe add() something to it or maybe even destroy() it? There was no easy answer to that question and every plugin developer was left to his own creativity to come out with a solution.

var $carousel = $("#carousel").jCarouselLite(options); 
$carousel.stop();  // You cannot do this
$carousel.run(); // Nope! You cannot do this either
$carousel.destroy(); // Nope! You get the idea...

While developing jQuery UI, the team there recognized this as a generic problem and came up with a generic solution. They called it the Widget Factory and popularized it as a way to develop Stateful plugins as opposed to traditional Stateless plugins. Take a look here to know more about how to develop jQuery plugins using the Widget Factory Pattern. All jQuery UI widgets are examples of plugins developed using the Widget Factory. Lets take one interaction with the jQuery UI 

var $accordion = $(“#accordion”).accordion(options);
$accordion.accordion(“enable”); // Enable the accordion
$accordion.accordion(“activate”, 1); // Activate the second tab

As can be seen above, now you can interact with the Accordion after initialization by passing a method name as string. For instance, “enable” is a method that takes zero arguments and enables the accordion and “activate” is another method that takes one argument (an index) to be activated and opens up the accordion tab at that index.

It works, but wouldn’t it be cool if we don’t pass in method names as strings and would get to call the methods directly on $accordion – like $accordion.enable()?

It so happens that the $accordion is not an instance of the widget itself, but a jQuery object that wraps the DOM element representing the accordion. In most situations that is what you will need and so that is what is given to you.

The good news is that, the actual widget instance is stored with the corresponding DOM element using jQuery.data(). The plugin’s name is used as its key. Therefore, you can call $accordion.data(“accordion”) and enjoy direct access to all its plugin methods without retorting to indirect, string based approach anymore.

var $accordion = $(“#accordion”).accordion(options).data(“accordion”);
$accordion.enable(); // Enable the accordion
$accordion.activate(1); // Activate the second tab

Now you can have your cake and eat it too…

JQuery: Wait for multiple animations to Complete – Take 2

In an earlier blog post, I stated the need for a technique that helps determine when multiple animations have completed running, so that we can execute some code at that point. I also examined a technique using a combination of setInterval() based polling and checking for the :animated pseudo-class to achieve the result.

With the release of version 1.5, jQuery introduced the concept of Deferred Objects. It’s a pretty useful beast. You can find the full explanation here. In jQuery 1.5, the $.ajax() was enhanced to return a Deferred Object, but $.animate() was cheated without being given that honor. That was corrected with the release of jQuery 1.6 and now you receive a Deferred Object as a return value for $.animate() and its higher-level cousins.

Using the returned Deferred Object, and another useful utility function named $.when() we don’t have to stoop down to using poll-based techniques to wait for multiple animations to complete. Take a look at the code below and you will agree that it can be done much more cleanly now. 

var animatingFoo = $("#foo").slideUp(1000);
var animatingBar = $("#bar").slideDown(3000);

$.when(animatingFoo, animatingBar).done(function() {
  // Do something useful
});

Here, both the slideUp() and slideDown() methods return a Deferred Object. Although we can attach the done() event-handler to the animatingFoo and animatingBar separately (which will get fired separately when the individual animations are complete), that is not what we are after. We want to execute our code after both the animations are complete. For this purpose we call in the help of a utility function $.when().

$.when() aggregates multiple deferred objects and returns a single deferred object. Now, if we attach our done() event-handler to the aggregated deferred object, it will get fired only after both the animations are complete, which solves our requirement.