Community

Appcelerator, Rhomobile - these are a couple of cross-app mobile development IDEs that enable development of a single codebase that can be deployed on iOS, Android and a couple of other mobile platforms. Having heard such stories before, we were very skeptical when we started development of a mobile LBS app using one such platform. But, at the end, we were pleasantly surprised. Despite the fact that our app needed to use GPS, accelerometer, camera and other device functionality, we were able to deploy a single code base on iPhone and two different makes of Android phones without any changes. Such IDEs might help banks and others to strike the right cost-benefit balance between native and mobile web apps.   

In its recently published article titled Finding a Reasonable Definition of Commercially Reasonable, the Federal Reserve Bank of Atlanta reports
400 reported cases of corporate account takeovers involving the attempted theft of $255 million, resulting in actual losses of approximately $85 million. These are nowhere near the highly scary figures reported by the Guardian Analytics and Ponemon Institute research.

@FinextraM:

TY for your comment. Books ordered via instore QR code are not available for immediate pickup. They'll be home-delivered, just like orders placed on the website. I didn't notice anything on the website / video to suggest that the former channel qualifies for faster delivery than the latter. Do you think the QR code alternative helps latecomers in some other way?

@FinextraM:

TY for pointing out that the report on Sweden is authored by the central bank. I didn't know that. However, that doesn't change much because of the following reasons:

1. While I don't know about Sweden, central banks in many other countries - USA and India, for example - are expected and known to represent the interest of banks above others.
2. This report seems to talk of the overall cost of various MOPs across all participants in the payment value chain, whereas I'm referring specifically to only the merchant and the customer, who I consider the two most important members of the payment.
3. Thresholds can work both ways. Even if credit card acceptance might be cheaper for the merchant for ticket sizes above EUR 40 in Sweden, the situation could be the opposite elsewhere. For example, according the following extract from the bill payment website of my local utility, the merchant finds the cost of accepting credit cards to be too high to be absorbed above INR 10K: "For transaction exceeding Rs. 10,000 for card payment, Card holder to bear charges @1.2% for the amount exceeding Rs. 10,000." Let me add that the merchant doesn't charge any surcharge for any amount of payment by cash. It has been argued for years that merchants don't realize the hidden cost of handling cash, but, quite frankly, what they perceive as their costs is all that matters here. 

US retailers are protesting high credit card interchange fees to regulators. In India, some merchants refuse non-cash MOPs altogether and others openly demand 2% extra for credit card acceptance saying they've pass on this amount to banks for credit card acceptance. According to this report, merchants in the UK find cash to be both the cheapest and the fastest MOP. Besides, I haven't come across merchants in any of these countries - or elsewhere in the world - levying a surcharge for cash payments or complaining to the regulator to bring about a reduction in their cost of accepting cash.

I do admit that cash must be costly for middlemen like banks for I've only come across them charging a premium for accepting cash payments e.g. additional fees for settlement of credit card bills with cash. As for Sweden, the article is authored by a bank and I'm sure cash is not attractive for them. I might start believing that cash is costlier for merchants and / or customers in Sweden / elsewhere if I saw one of them going on record to this effect.

Not just Pay By Square, but all mobile wallet instore payments are reportedly considered as CNP, thereby attracting higher interchange fees. In the case of SQUARE, iZettle and others who bundle a merchant account, this shouldn't matter since they anyway charge a flat fee of around 2.75%, which exceeds both CP and CNP interchange rates. However, it would matter in the case of mPowa, Google Wallet and others who don't bundle a merchant account and follow an interchange+ pricing model.

It could be argued that Pay By Square already provides 2FA - physical possession of smartphone and face recognition - so there shouldn't be any case for stipulating upper limits on transaction sizes in either EMV or non-EMV worlds.

Since merchants are responsible for face recognition in the case of Pay By Square, it's only natural that they should bear the risk of fraud. No different from recognizing the signature on the backpanel of the plastic card in the non-EMV world.

When I used my Android smartphone to buy a paid app for the first time from Google Play - or Android Market as it was called at the time - I was taken to a screen titled Google Wallet and told to add a credit card. I did that via the smartphone's keyboard. The Visa card I entered has been stored on file as my default funding method on GW since I don't have to enter it during subsequent purchases, including the one shown here. I didn't have to interact with Visa or the card-issuing bank even once. I guess this method of adding a credit card to GW is only applicable when GW is used for mobile-based remote transactions.

For NFC-based instore payments using GW, pushing the card details from the card network's account center, as described in this article, might be the only way to add a credit card to GW.

If the amount is fixed in advance (e.g. house rent), direct debit is fine. But, for variable amounts (e.g. mobile phone), I'd never dream of using direct debit, based on my personal experience with this leading UK MNO. I'd signed up for a GBP 25 / mo. plan for a 3G USB modem. With a few extras, my monthly bill would typically range from 25 to 35 GBP. Suddenly, one month, I received a bill for GBP 820. Armed with usage data, I called the MNO to explain why it was impossible for me to run up such a huge bill. I was surprised that the MNO's CSR readily admitted to a problem in their billing system and reversed the transaction without demur. I shudder to think how much more hassles I'd had to go through had I issued a direct debit mandate to this biller.

I was curious to know BPAY's lead time and visited the linked website. According to its FAQ, banks send out the payment on the same day. It's the biller who seems to procrastinate ("it can take a biller a number of days to apply a payment to your account."). So banks in Australia already seem to be offering Same Day Payment, if not near realtime payment.

This reminds me of an interesting situation that developed when a Top 5 UK bank went live with Faster Payments in May 2008. Within hours of going live, a leading MNO called its RM at the bank and told him to ensure that the sort code of its collection account at the bank was NOT enabled for FPS since since its internal systems weren't ready to sweep the bank account and apply credit to the customer's account in <3 days! 

While my personal experience might not be representative, credit must be given where it's due: Maybe it's the billers who need to get their IT act together.

Interesting idea. Shall we call it "Open Source Within Closed Doors"?

Even if they have Apple Passbook / equivalent app that takes the pain out of having to fire up an app and search for the appropriate "card" (cf. my Finextra comment), I'm not sure how many people will be willing to buy so many closed-loop cards.

Even if enough of them do, we come back to the perennial question about how many merchants would be willing to invest in the POS equipment required to support such mobile contactless payments.

Now, if we take open-loop cards via mobile, the business case for the merchant diminishes further since such payments would be treated as CNP and attract even higher interchange rates than the CP rates they've already been complaining about.