Mobile Private Label Cards

credit cards in smart wallet

In my last post I wrote about major scheme credit cards (Visa, MasterCard etc.) on mobile phones. But what about private label cards? I believe that mobile private label cards provide  compelling added value to both merchants and cardholders.

From a merchants perspective, at the top of the wish list for such an app is probably a fully branded experience for the shopper. This experience begins with targeted ads before a sale, then to browsing around online or in store, and finally to the conversion and possibly an award for the shopper. For example one really interesting idea I heard recently is a fast food chain funneling customers to lesser frequented stores by providing coupons valid only for these lesser frequented stores. All in real time of course. What a great way to provide a better experience for your client. All the data collected during this process is valuable to the merchant, as it is mostly loyal and top clients that would use such an app. Therefore controlling this data, at least to a certain degree, is an important factor. However, loyalty programs will probably need a fresh approach in order to truly benefit both the merchant and the customer.

I think this is one of the main challenges for major card scheme mobile wallets. Broadly speaking, these wallets are either provided by issuers and offer no benefit to the merchant, or they are provided by larger corporations (Apple, Google, maybe soon by Samsung) who control the data and provide little opportunity for good merchant system integration. The reasons why these big companies are doing this are many.  From rules and regulations to business cases and protecting their best interests. So there is no real benefit for the merchant without a tradeoff.  I wonder if and how Apple Pay will move towards the merchants.

From a personal perspective, I see the convenience and benefits that a wallet with issuer only functionality has. These would be that the wallet contains a card, shows the latest transactions, etc. At this stage though, most of my friends wouldn’t bother with a mobile wallet. Mainly because credit cards are a very simple way of payment that they’re already used to. However, if they would benefit from using the app by saving money in one way or another I bet some of them would seriously consider it.  As a side note, my banking app here in Australia provides the option to register a card but when I tried to do this it said that my mobile phone model is not yet supported by the app, even though the phone has a secure element.

Looking at private label cards, a scenario that is beneficial to both the merchant and cardholder becomes much simpler. The reason for this is that private label cards don’t have to adhere to the rules and regulations of the major card schemes. Rules and security controls can therefore be freely chosen by the scheme owner, which is the merchant or a service provider.  Anything is possible, from no rules and security to highly regulated and secure. It would come down to weighing up security, convenience and cost.

For example a merchant could decide to issue a plain text card number as a bar code to each app user, which is relatively insecure. Alternatively, a solution based on tokenization and contactless EMV (NFC) can provide a secure process and seems to be a natural choice, at least here in Australia and in Europe.

By taking control of the payment rules, the merchant or solution provider can focus on creating the desired shopper experience. The actual process of payment becomes just one part of the app, instead of being a major hurdle.

So, will merchants all over the world now implement these kinds of apps? It probably makes more sense for existing players in the market to provide these kinds of solutions and white label them to merchants. I think good APIs and integration points for merchants are, amongst other points, the keys to success. The merchants must be able to keep control of their data.  For example, if you are a PSP and you provide this type of app and service, you will provide true value to the merchant and also increase the merchants dependance on you. I know of several merchants that would love to have private label plastic cards, but have too few potential cardholders to justify the cost of the cards. Making these cards mobile would be a game changer as the cost of card issuance and distribution is significantly lower.  There are some technical challenges to overcome, which we have experience with.

It will be interesting to see how this space will evolve in the near future.  Please contact us if you are interested in the topic, or leave a comment. Thank you.

Mobile Wallets for Major Scheme Cards


Mobile payment is THE hot topic in the card payments industry. The main focus is certainly around the major card schemes like Visa and MasterCard and how to put their cards into a mobile phone. Once this has been achieved, the functionality of the cards can be enriched like never before. From on-device cardholder verification to loyalty and much more, there is a lot of room for innovation.

With Google allowing HCE and more recently Apple Pay, there are technical solutions that allow creation of applications and business cases around mobile wallets.

I do not doubt that HCE and Apple Pay will be adopted in one form or another, sooner or later. Apple Pay has launched just at the right time – before the U.S. shopping season – and while some doubt its long term success (Why Apple Pay Is Fizzling and What It Means for the Future of Mobile Payments) others think that’s exactly where it is heading (Is Apple Pay Fizzling? No Way Man, It’s Sizzling!).

However the whole topic of loyalty is still a major issue as it requires integration with a merchant system. For a merchant, the following points are at least questionable when considering mobile wallets and loyalty programs:

  • People paying with phones are only a small fraction of the people paying with cards, who are in general again only a part of all business. Therefore, in general, merchants are not willing to invest in customized POS solutions enabling only one specific wallet. Wallets must use the “existing rails”, POS terminals.
    As a side note, yes I do believe that iBeacons have a place in the market. Currently, I think they are about targeted ads more than about payment. The future will look different, maybe like this, but not yet.
  • There is an abundance of wallet providers and wallet providers-to-be out there. Merchants will most likely not choose a certain wallet exclusively, for fear of losing business from other wallets. There are of course exceptions to that, but if they launch and then succeed, that is still an open question.
  • The fundamental difference between Google’s HCE approach and Apple Pay increases the complexity. Apple most likely will not allow anything else to become an NFC payment app, resulting in no other IOS wallets than Apple Pay that can be used with POS terminals.

Considering the above issues it is understandable that merchants will wait and see. Maybe they will run a trial here and there and learn the technology. There will be several HCE wallets for the big scheme cards, and there will be Apple Pay. Merchants will have NFC terminals and not lose any business. Loyalty will be subject to support by these apps and solutions.

But what if a merchant can have its own app, with its own merchant-specific payment and loyalty functionality that is using the existing POS?

I will write about that in the next post. Sign up if you wish to be informed of when it will be published. And of course leave your comments, we appreciate it.

Strategies to implement EMV on Terminals

EMV Chip

The EMV liability shift in the U.S.A is getting closer so I would like to share some basic strategies on how to implement EMV on POS terminals.

While EMV has been a key component for terminals in Europe, Australia and other regions, many terminals in the U.S.  accept magstripe cards only. This will change in Fall 2015 when the cards schemes will stop taking the liability for non-EMV transactions. POS and terminal manufacturers with magstripe-only terminals will have to adjust and become EMV compatible to stay in the market.

Apart from the existing handling of a transaction that controls transaction flow  and connects the card reader with the acquirer, an EMV compliant terminal must also adhere to the EMV specification. In whatever way this EMV compliance is implemented, it can conceptually be separated from the rest of the terminal functionality. This separated piece of functionality is commonly referred to as the EMV Kernel. The EMV Kernel, together with the rest of the terminal, must undergo periodical certification and adhere strictly to the EMV specification.

Simply put, there are two strategies on how to implement EMV compliance when creating a POS terminal:

  1. Write your own EMV Kernel
  2. Use an existing 3rd party solution

The upside of writing your own EMV kernel is that indepth EMV knowledge will be  built up amongst the development team and  control over the source code stays within the company. The challenges however are that it takes time and money to build this knowledge (EMV Co estimates 18 months), that it requires continuing maintenance to stay EMV compliant, and it is a mission critical component that cannot fail.

The advantages of using a 3rd party solution are as follows:

  • Faster time to market, as the know-how is bought in.
  • As the EMV specification is the same for every POS it is not a differentiating factor for a POS solution. Therefore it is not a strategic piece of code where knowledge needs to be kept internal.
  • It makes sense to use a stable and already approved product that runs on many other terminals and has successfully proven its value in the market.
  • No need to adapt to frequent changes in EMV specification, especially for contactless. This has proven to be a major problem for several reasons.

Regardless of which strategy is used we recommend thorough testing before attempting certification, as there are one time costs related to certification  that are payable whether a solution passes certification or not. There are several test tools on the market (e.g. by  Clear2Pay) that facilitate testing, but these come with a significant cost.

Also, the testing can either be done in-house or by a 3rd party. When implementing your own kernel, it probably makes sense to test in-house.  Alternatively, using a 3rd party test lab saves the cost of acquiring the test tools, test knowledge  and certification knowledge.

Regardless of how these US companies choose to become compliant, EMV certification will be a requirement to successfully stay in the card payments market.

Abrantix provide an EMV Kernel starting with a beginner package that includes 1000 licenses at a low cost.  Packages for more than 1000 licenses, support and consulting are also available.  In contrast to other suppliers we provide the source code of the kernel to allow full transparency and integration into existing payment applications.

We also have a test lab and provide test and certification support.

We are happy to help, and also hear your opinions on this topic of course.

New payment methods in a global world?

payment in a global world

In recent years, we have seen a lot of innovation in the payment space. It’s not just cash, credit card or cheques anymore. You pay for your coffee with your contactless card or mobile app.  You do some cross-channel shopping; standing in a shop looking at a product and then using your phone to buy it online and get it delivered. You might pay hands free at your favourite fashion shop or take a cab ride without even needing your wallet.  Or you send some money to a friend via GMail.

Most of the new brands and payment methods we have seen focus on the way payments are made by the consumer or how merchants can accept new forms of payments. And most of them are or were to be the next big thing in the payment industry. But are they really?

While the way we shop and pay has changed, in the background things seem to still work the same way. Most of these new forms of payment will require you to create an account and – surprise, surprise –  register with your credit card details. Then you will either load some money onto your account, or the money spent on the account will at some stage be charged to your card. Sometimes you can also choose a domestic form of payment for this, for example the Lastschriftverfahren in Germany with PayPal. So while the front end, the POS, is addressed with very creative and good solutions, the nitty-gritty of the actual transferring of money is not.   We still rely on good old credit cards.

Simply put, what is electronic payment at the end of the day?  It is transferring money from account A to account B. This is easy if you know which account to transfer to and if you are in an authenticated environment (e-banking). But as we all know, looking at this from a POS or consumer’s perspective, this is one of the major issues in payment.  A vast number of consumer banks and a vast number of merchant banks need to be connected in some way. This issue was addressed elegantly by the card schemes. Their network connects all these entities which keeps them alive and makes them part of these new payment methods.

Now, if you have ever spent more than a few months living in different countries, you will know that banking is something very domestic (except if you have a lot of money, then you might have a different experience). You cannot open a bank account if you do not live in the same country as the branch where the bank is located. And if you move abroad for a longer time, the bank might charge you a lot because you live abroad. The same applies for merchant banks.  Most likely a merchant can only open a bank account in the country where it is located.

So, returning to my original topic of new forms of payment, I have not yet seen a payment method that solved this problem. Either they are domestic, or they use the rails of the card schemes to solve this problem. Even worse, many of the new payment methods work only in the country they were first launched (e.g. Gmail Send Money only works in the U.S.).

There are several reasons for this.  Rules and regulations that differ in different regions and countries, proprietary bank interfaces and the cost of integrating them, banks not willing to support a payment method they do not benefit from and so forth. This is the big value of the card schemes and funnily enough is also one of the original problems they wanted to solve.

I am very excited about many new methods of payment, and from a consumer perspective the points I made above are not that important. However, for the payment industry the big innovation would be to overcome this dependency on the card schemes. A payment method that will truly replace credit cards will have to work all over the world.

I think we have only seen the first steps in this changing world of payments. How difficult will it be to overcome dependencies on the card schemes?

Please share your thoughts on this, we appreciate it.


NFC at a Coffee Machine – Success Story at the University of Applied Sciences Berlin (HTW)


Congratulations to Maurus Rohrer from the BeWiTEC INKA research group at the University of Applied Sciences Berlin (HTW)!

For a research project Maurus used the Abrantix MDB Converter to connect a coffee machine to a  sophisticated user system. The goal was to investigate and implement a system that allows the user to easily make purchases with an NFC device and store these purchases in an accounting system. Also, the system was to memorise the product preferences of the user and automatically inform maintenance personnel about the machine status.  More features were implemented and many more could be imagined.  For example, users can sign up with any NFC capable device, be it a credit card, key fob or a badge. Users can also share preferences and recommend products to each other, or the sytem can suggest new products to a user based on their previous consumptions.

We’ve posted a video on our Youtube channel so you can see the system in action.

This is exactly what the MDB converter has been designed for: Enhance old MDB hardware with modern and smart technology! There are many vending machines out there and replacing them with modern machines is very costly. With the MDB converter it is easy to add complex and new technology at a low cost.

The MDB converter is a piece of hardware that can act as an MDB master or MDB peripheral device. It is fully MDB compliant and can easily handle the conversion of the 9 bit communication requested by MDB devices into an 8 bit protocol understood by regular PCs or any other RS232 capable device. Furthermore, it takes care of the polling and timing mechanisms of the MDB system, leaving you to deal with the important requests only. Simply connect your MDB system over the MDB converter to the serial port of your device and you are ready to go. With the sample source code that is provided with the SDK, you will be able to run any custom application on top, from a very simple test application to a full blown system as Maurus did.

Here is what Maurus says about it: The MDB converter from Abrantix helped me a lot for my research project. Using it meant that I could implement the coffee application successfully. Also I want to thank Abrantix for their technical support during my project. The machine has now been running successfully every day for 6 months!

If you have any questions or need more information, please leave a comment or contact us via our website.

Congratulations again to Maurus!

You can buy the MDB converter here.

MPOS and EMV, where is the business case?

MPOS Payment

In our last post we asked ourselves if EMV killed MPOS in Europe before it even started. Thanks for all the sharing and discussion on this topic, we received a lot of feedback (here is an example on linkedin) and appreciate it.

As all of us know there are companies in Europe that already provide EMV MPOS solutions (iZettle, Adyen, …). And there are even more companies who are about to come out with a solution, or at least claim to do so. Interestingly, most of them decided to use Miura Shuttle as the card reader and PIN pad. Of the better known companies, only mPowa seems to use a different hardware, at least from the pictures on their website.

Of all the feedback received it seems that opinions are 50/50 on successful EMV MPOS business cases. Some even question if the Squares out there turn over positive figures. Therefore I went through the numbers and want to quickly share a simple business case.


  • … we used the Miura Shuttle or something similar, acquired for EUR 200.-
  • … we sold the Shuttle for EUR 100.-. There are some teasing sales campaigns for EUR 50.-, e.g. with Payleven, but the regular price seems to be around EUR 100.-
  • … we took 2.75% per transaction
  • … we had a deal with a processor for 1.25% per transaction
  • … we had marketing/sales and handling costs of approximately EUR 100.- per device
  • … our merchants made transactions for an average amount of EUR 80.-

This leaves us with device costs of EUR 200.- that need to be covered by the transaction fees. EUR 200.-  (device costs) + EUR 100 (marketing/sales/handling) – EUR 100 (selling price).
With the above fees and average amounts we can take EUR 1.20 per transaction: The breakeven is achieved with 166 transactions per device.

The numbers above are just estimates, although probably not too far off. To me, this does not look like the easiest ball game. I doubt this will bring card payments to the small merchants in the near future, because:

  1. Device costs are too high. Why should I buy that? My business has been running without this option so far.
  2. Small merchants aren’t attractive as it’s highly questionable they will bring 166 transactions within a reasonable time.

However, I think this is a real winner for mid-size merchants with door-to-door services such as locksmiths, gardeners and the like. If you look at losses caused by late payments or defaults, enforcing card payments by these merchants could save them a lot of money and hassle, and would justify purchasing the equipment. An Abrantix-internal study (available on request, in German only) suggests this is definitely the case here in Switzerland.

Target industries and merchants are definitely where the successful will part with the unsuccessful MPOS providers. Mpowa seems to be heading in the right direction.

On the other hand, the approach taken by Square is also worth considering. While we are all talking about MPOS they are already a step ahead, trying to create their own payment network. Here is Karen Webster’s interesting article on pymtns regarding this. MPOS was only the foot in the door. With broad merchant acceptance gained by MPOS and a huge number of users gained by the Starbucks deal, they are definitely on the way to becoming a second PayPal. In the future, will Square care about MPOS with credit cards once they are a payment network?

I have three predictions for Europe:

  1. We will see MPOS for mid-size door to door merchants, but not for small merchants.
  2. We will not see the creation of a payment network that starts with EMV MPOS, such as with Square, as the target industries are quite specific for the business case.
  3. There are a huge number of small businesses out there that will not be catered for with EMV MPOS solutions. Hence there is definitely room for other solutions such as the Starbucks App or private label cards, or even bank to bank payment solutions.

Please let us know your opinions and ideas. We are really interested in continuing the discussion on this one.

Abrantix is a payment software engineering company and has extensive knowledge around card payments and EMV. Abrantix also sell an EMV Level 2 Kernel.

Happy New Year!


We made it! Despite hard economical times and the end of the Mayan calendar the year 2012 will soon be history, and we are still here. To make this payment world a little bit better, we suggest the following new years resolutions:

  • As an acquirer, instead of only focusing on signing the big accounts I will also be  focused on better service and data quality for all customers.
  • As an issuer, I will reconsider whether I really need the part of the interchange that funds my innovations, or if  I can also be innovative without it.
  • As a card scheme, I will try to make it easier for all players to adopt new business models whilst trying to lower the hurdles for these.
  • As a merchant, I will provide my customers with convenient, fast and modern payment methods.
  • As a bank, I will devise a bank to bank payment method that makes it easy to transfer money C2B and C2C, with low transaction fees.

Besides losing all the weight gained with the mountains of chocolate we ate, we at Abrantix have commited to a new years resolution of supporting all above parties so that together, we get a step closer to the best of all payment worlds.

We wish all our customers, partners and readers a very happy new year and a successfull 2013!

The darned 9th bit


As Daniel said in his birthday post, one of our products is the AXT1 vending machine payment terminal. For a long time now I wanted to share some of the problems we had and insights we gained while creating this product. As a software company, starting with the product design we never imagined that the final product would be a fully engineered hardware terminal. But that’s what it turned out to be…

One of the key features of the AXT1 is its MDB vending machine interface designed in the 80ies by Coca Cola. MDB stands for Multi Drop Bus. Simply put this is a serial bus you can connect one master and several slaves to. The MDB protocol is widely used in vending machines and it’s the way to go if you want to provide a payment terminal for vending machines.

The special thing about it – or at least special for us software people coming from 8, 16, 32 and 64 bit environments – is that it is a 9 bit protocol. Instead of using the more common 8 data bits and one optional parity bit, it uses 9 data bits and no parity bit. The 9th bit is used to to address the slaves in the beginning of a communication session. The problem is that the UARTs (hardware components that takes care of the serial communication on the bus) provided by standard embedded PC boards (PCB) support 5 to 8 data bits, but 9 data bits are not supported out of the box. Therefore, connecting a “more intelligent” device such as a PC to a vending machine is not a plug and play kind of thing. But this is exactly what we wanted to do. Our payment software runs on linux and we undoubtedly wanted to keep it that way. The reasons for this I think are quite obvious and could fill another blog.

Easy done, we thought. We simply get a linux PCB, use a UART in 8 bit mode and use the parity bit as the 9th data bit, as this guy here suggests. Not very elegant, but it works. Another option would be to get a PCB with 9 bit UART support. There are some of these out there, but this limits the choice of PCBs and creates an unnecessary dependency to the PCB used.

Happy about our first implementation, we connected our terminal to a vending machine. This first test was a big disappointment. The MDB protocol specifies a time window of 5 milliseconds for a slave to answer. We found out that when running our software on an OS like linux, it is more or less accidental wether we could reply in this short time or not. In hindsight, it is now obvious… We thought about changing to a real time OS, but dismissed this because it would have required massive efforts to port and maintain our software.

The only way to go forward was to design our own piece of hardware with a 9 bit UART and a micro controller that acts as a “gateway” between the PCB and the MDB. The MDB converter was born. The micro controller on the MDB converter takes care of all the MDB specific timing issues and uses the 9 bit UART to communication with the MBD. On the PCB side, we use a standard 8 bit UART and an internal communication protocol. As a final step, we integrated the MDB converter with a standard PCB into one piece of hardware and there it was, the AXT1.

Currently, we run this solution in over 500 vending machines and are very happy with the solution. It gives us the flexibility we need to extend our software while still keeping up with the MDB requirements.

Talking to our partners, we found out that most of the companies who want to connect linux or other modern devices to vending machines have the same problems. Therefore, we now provide the MDB converter as a standalone module. Simply connect your device to the vending machine using the MDB2 converter. Or you can use the AXT1 and port your software onto it. Whatever suits your needs, we are open for discussion.

If you have had similar problems or are looking for a solution in this area, please share with a comment.

You can buy the MDB converter here.

Visa plans to accelerate acceptance/use of EMV cards in U.S.

EMV Deployment Map (September 2010)

In Summer 2011 Visa announced plans to accelerate the acceptance and use of EMV cards throughout the U.S. EMV cards are also known as IC or Chip cards. This announcement was no surprise as EMV has been a long accepted standard through Europe and Asia. However, to make the entire network EMV ready requires all the participants in the market to adapt their systems. Chip cards will need to be issued, the acquirer/processors must adapt their host systems and the terminals at the POS will need to be replaced.

Accompanying the announcement Visa published a road map stating the following:

  1. Visas Technology Innovation Program (TIP) will be expanded into the U.S., effective October 2012.
    This means Visa will waive the annual validation of a merchant’s PCI/DSS compliance, as long as at least 75% of the merchant’s transactions originate from dual-interface EMV terminals. Dual-interface terminals are terminals that can process contact and contactless EMV transactions.
  2. All participating acquirer/processors have to make their systems EMV ready by April 2013.
  3. Visas global POS Counterfeit Liability Shift Program will be extended into the U.S., effective October 2015 (two years later for petrol merchants).
    This program will transfer the liability for fraud originating from non-EMV transactions to the acquirer/processor, and as a result to the merchant as seen in other countries.

This plan clearly focuses on two goals:

  1. Reducing fraud.
  2. Setting the benchmark for NFC based card acceptance (for example; contactless payment by card or mobile phone).

In recent years the U.S. has been an easy target for fraud. In 2008, fraudulent transactions made up 0.04% or USD 8 billion of the complete U.S. turnover of credit card transactions. Card numbers are being stolen all across the world and used in the U.S. to commit fraud. The predominant number of magstripe POS terminals makes this a relatively easy way to commit fraud. With the adoption of the liability shift program one large fraudulent region will be eliminated, as seen in other countries that already run the program. Once this has been achieved, the question remains: Where will the fraud move next? Until chip cards are used worldwide, magstripe fraud will remain a global problem.

Interestingly, the liability shift program is a sweet deal for Visa as it will instantly and largely increase the points of acceptance for NFC based cards. Conversely, it will be a cost intensive change for the merchants as it forces them into changing their POS infrastructure into dual-interface EMV terminals. This sets the ground for Visas contactless program Pay Wave and for mobile payment. Google already provides a nice solution with its wallet, where the phone emulates an NFC payment card.

This is where we believe it gets really interesting. In contrast to Europe where cardholder authentication through PIN is usually required, Visa aims for an online / non-PIN model in the U.S. which will pave the way for contactless transactions. Wave the card and that’s it, no PIN entry required. Issuers and acquirer/processors will be happy with this, as it lessens the costs and complexity on the card and the terminal.

In contrast to all of this, one can see an increasing market for “easy” magstripe transactions. Square, amongst others, provides an easy way for merchants to accept magstripe cards. Up to April 2011 Square has seen USD137M total flow. These payment solutions target small businesses and make it very easy to accept credit cards as a merchant. Common to all these solutions are high transaction fees for the merchant and the full risk of chargebacks. What some people might not know is that Visa invested in Square. There seems to be a two way strategy in pushing the mid and large size businesses into accepting contactless EMV cards and enabling small businesses to accept credit cards on their full risk. Clearly a winner for Visa! But what do they actually do for it?

In the longer term magstripe transactions will disappear. Issuers will simply stop issuing magstripe cards. This has already started in some Eastern European countries. The main reason is fraud, but also because there is new technology that makes cards obsolete. The “card” itself might not be a “card” anymore, but a mobile phone, key fob or all sorts of mediums carrying the chip. While it may take several years to fully implement, it is interesting to wonder how small businesses will be targeted.

Abrantix is a payment software engineering company and has extensive knowledge around card payments and EMV. Abrantix also sell an EMV Level 2 Kernel.