Previously, I've discussed NFC a bit, and also Passbook. I've been thinking about the whole payment thing a bit lately, and I think I might have come up with something which might work - or at least be a starting point.
First up, I don't see Passbook as a payment method. It's a barcode, and as such, it can be easily copied. You can easily take a screenshot of a Starbucks pass, and scan it in Starbucks, charging your drink to someone else.
But in the same vein, I don't see NFC being used in anger for a while. It's too complex for most shops, and the merchants (ie, VISA, AMEX, the banks) are very slow to act.
So, a possible solution.
Assumptions
This is designed to work with - not replace - existing card terminals. It assumes that the user and the merchant both have internet, and the user has a smartphone.
Using it at the POS
- A transaction is completed on the POS, as per normal.
- The merchant enters the amount of the transaction into their "terminal". This might be automated as part of the POS (eg, Vend, Lightspeed, Square) or it might be manually entered into a hand-held device using an app from the provider of this service.
- The user then scans the merchant "code" (NFC, QR, barcode, or has a list of recently used places based on GPS). This code is unique for both the POS and the merchant, so if you had 3 POS terminals, they'd have 3 codes. The transaction value shows up on the screen, and the user accepts it, possibly picking which method to pay with and entering a pin if required.
- The merchant's terminal is notified that the transaction has been accepted (push message, web service etc). If needed, the users photograph could be provided for further verification.
This is a fairly simple flow. It would also support merchant-not-present transactions, eg:
- The user completes an e-commerce transaction up until the payment steps, as normal.
- The website pushes the value to the service, and shows the QR code/identifier on screen. This identifier would be unique to the transaction, not just the merchant.
- The user scans the code, and the app connects to the backend service to retrieve the transaction.
- The user accepts the amount, and the service notifies the merchant's e-commerce application that it has worked.
- Normal fulfilment happens after this.
Having this work from a Smartphone app would allow things like automatic loyalty cards, tabs (like Square), automatic "I'm near this merchant" type functions.
Backend
The backend of this service is where I think it can get interesting. Both the merchant and the user need to be signed up (as they do now with credit cards), and provide some way to pay, or to receive money (as they do with PayPal now).
Once signed up, anyone can receive or send money, and the backend service is responsible for pushing the money around. This might be direct to/from a bank account using a service like GoCardless or PayPal, a normal credit card merchant gateway, or a stored-value account, or any other payment method.
Not relying on a credit card gateway reduces the cost hugely.
Importantly, the user does not have their card details on their mobile device, and the merchant does not see or receive their card details. If the device is lost of stolen, the cards are protected by a PIN, and even if that pin is guessed, the device can be disabled, as it must communicate with the server for each transaction.
Functionally, this is quite similar to the Barclays PingIt service, which uses the mobile number as the unique key. It's sender initiated, where as my method is merchant initiated.
Advantages
- More secure than a credit card, less impact if it's lost or compromised.
- Two or more factor authentication should reduce fraud.
- Merchants could do this with an iPod Touch and a WIFI connection. That makes for a very cheap terminal.
- Could easily be integrated with a system like Square, where the card is present.
- Moo now supports NFC business cards, so with that and a QR code printed on it, you could use your business card as a payment receipt method.
- Easy to setup without a merchant account. Cheap service to run.
- Multiple sources of money: Bank account; Credit/Debit card; Paypal; Balance.
Problems
- Chargebacks for credit cards could hurt a lot. I'm not sure how PayPal deals with this.
- Scanning bar codes is a pain in the arse. That said, chip and pin is almost as bad.
- Requires a smartphone with a decent camera. Requires an internet connection (fine in cities, not good in rural areas)
- Doing a bank transfer transaction without having the money to back it up. Could be fixed with a credit card being required, but direct debit and other methods are not real time.
- Fraud; Money Laundering.
This is mostly a brain dump, but what are your thoughts on it? Did I miss something big somewhere in the process?
