Nothing,

Absolutely nothing.

It is a gadget thing, it is a Google’s advertising thing – they know a bit or two about ads. And the value proposition is: now you (customer) can touch instead of swipe, and don’t have to carry around all that plastic in your wallet.

Admittedly, NFC enabled mobile (as in mobile phone) payment could be a convenient way to pay. Convenience, however, does not make a business case unless you can charge for it, and there is no word about charging for NFC facilitated payments.

What has not been tackled by NFC based innovations – see all the related news and announcements – is the business case and how it fits into the payments value chain.

Is it going to remove the plastic and the card vendors (the likes of Gemalto) from the equation? Is there a saving on plastic and chip and all the supply chain and stocking baggage that comes with that? Or is the plastic problem now replaced with a mobile and NFC chip baggage?

The fact is, NFC still requires a terminal (signal receiver), until that is removed or replaced with some commodity kit, there is nothing interesting about NFC and the likes. For example, consider the following where the actual POS device is replaced by the customer’s device (smartphone).

Could this scenario use NFC for the technical implementation? Maybe. However, until there is a business case for NFC in mobile payment, it will remain a hype, an attempt to carve out a buck or two from the payments value chain.

In the meantime, the really interesting developments are happening at Square and ISISPOS POS and the likes.

Tokenization

• storage,
• capture/transmission,
• and back office administration.

Drawbacks to Tokenization

Tokenization providers act as a middle-man between the merchant and the processor. When a merchant performs a credit card transaction, the request goes through the tokenization provider before proceeding to the processor. When a credit card number is used for the first time, the tokenization provider creates a token that represents that number and only the token is stored by the merchant’s software. In future transactions with that card, the software simply provides the token in lieu of the credit card number and the tokenization provider replaces the token with the real card number when it communicates with the processor. While allowing the merchant to avoid storing credit card numbers and placing themselves in-scope for PCI-compliance, most tokenization schemes have several drawbacks.
First, most providers charge per-transaction fees for use of their service. These fees can quickly eat away at any savings provided by avoiding PCI-compliance.
In addition, most tokenization providers do not provide support for authorization reversals, preventing payment software from adjusting authorization amounts in response to backorders or freight amount adjustments. This causes downgrades and higher processing fees.
Most importantly, however, using traditional tokenization results in “provider lock-in”. Provider lock-in occurs when a merchant has been using tokenization and wants to switch providers. The original provider has all of the merchant’s customer credit card data stored in their system and leaving that provider means abandoning all that data and starting fresh. This can have highly negative consequences for merchants who use recurring billing, have auto-billed subscription services, or are simply used to the convenience of having customer credit cards on file.

Account Updating

According to MasterCard, on any billing cycle, the average merchant experiences a 25 to 30 percent decline rate on recurring payments – dramatically more than the average of 5 percent for card present transactions. Many of these declines result from invalid expiration dates or card numbers. As a result, merchants must spend time contacting the customer for alternative payment forms, which is not only a costly administrative expense, but also presents the cardholder with the opportunity to cancel service.

Subscription Billing’s Opposing Forces

When going to market using subscription billing there are three diametrically opposed forces fighting you, the person who owns the active subscriber count as you try to acquire and retain the most customers possible. These forces are PCI, Account Updater, and customer data ownership. I want to focus on the balancing act between the first two.
These days, one of the primary mechanisms to lowering the compliance burden and the actual risk of card disclosures is to use tokenization of those cards from your merchant acquirer, or gateway. Tokenization is simply an infrastructure at, for example, your gateway that will take the card you obtain from your customer on your checkout page, encrypt it for storage in their database, and hand you back a ‘handle’ to that card for future use. It doesn’t remove much of the compliance burden as credit cards still flow through your webserver and thus you still have to fully comply with PCI, but it does lower the risks of actual disclosure and shrinks the scope of your compliance efforts.
A surprising number of merchants are unaware of or don’t implement Account Updater, which is available from Visa and Mastercard in North America and some of Europe. Account Updater functions in two ways. The primary way will automatically send card changes for customers that you’ve billed in the last six months to you so that you can seamlessly update their card before a billing event. The alternative way is for you to either proactively or after a billing failure ask if there has been an update on any given card. We’ve found that the absolute best result is to run Account Updater in both modes and spend time optimizing the latter mode for specific billing plan frequencies.
Unfortunately, the requirements of Account Updater and its impact on customer retention are at odds with the requirements of tokenization in support of PCI. Most of the tokenization projects at the various vendors do not take the product requirements of Account Updater into consideration. How does one query the Account Updater service for the new card that may have replaced the one that failed when all you have is a handle to the old card? Unless your vendor has specifically added this to their tokenization implementation you are hostage to their product roadmap to save some significant percentage of subscriber churn. When you recall that few vendors are focused on the challenges of digital content and services with subscriptions, and instead get the bulk of their revenue from one time purchase physical goods merchants it makes sense that these tokenization projects have usually not addressed Account Updater functionality.

Using Previous Transaction ID as a token

…process a $1.00 auth on the card so that you verify the card is valid. Then when you are ready to charge the buyer, you would just perform a reference transaction API call where you reference the previous successful transaction and we will use the credit card information that was used on the prior transaction.  You would just pass over the new amount you want to charge.  So you would just have to know the transaction id of the previous transaction for that buyer so that you could reference it.  You could either look it up in your account, or store the id on your end.