Green android

The only difference that matters: AndroidPay vs. Pay | Why Pay will always be more secure

AndroidPay is for everyone
Pay is for everyone...with an iPhone

The difference between

Pay and AndroidPay

Apple vs android


Before we get into the delta between these 2 mobile payment solutions, there a few things worth pointing out. A lot about them is the same as far as the intended result which is access:

The following nonsense is mine:

Allow a consumer, a merchant and a financial institution to have access to instrastructure that deploys networked financial systems services in real-time. Using the following to complete a sales transaction between a merchant and a customer, using an approved financial component with the context that by placing emphasis on “security and privacy”, the entire ecosystem will benefit.


This is what was said to me when I read the Secure Element API. The spec itself is not complicated to understand. I wrote a little about hypothetical differences here, but now we have proof from Google…that they would rather share transaction data with people, which is the #1 reason there is private financial data waiting to thives to steal and use to commit fraud:

 Merchant data that is captured at transaction is a security risk,  leads to a privacy breech, does not add value to the purchasing process.

Those of us who went to public school call the above description, ‘Buyin stuff with your phone…’ While it is important to know how it works (the risk) and perhaps listen to someone explain what goes on in the SecureElement API transaction, understanding that just as it’s possible to use the internet on your handset You might not know you can also buy things with an iPhone just by waving a wand of magic. You don’t have to have any actual money, but the store will give it to anyway. Just because you you? Sure. (that and Apple said you are good to go).

Nfc symbolI am specifically referring to a the demographic of  tech savvy consumer, who has seen and used this symbol more than just ‘sometimes’ More specifically, that user understands the elevated risk of using payment systems with merchants, payment service providers and their affiliates that do allow access to captured transaction data, of the dollars (revenue generated/saved or costs avoided) specifically from retail using contact-less scanners and SecureElement based authentication methods in the transaction process, and removing the merchant from access to the financial data.

What Changes

Removing the merchant from the financial authorization process (which is between the customer and the bank) as the

In the new consumer purchasing process that consists only of those dollars spent using mobile devices as a physical tool for purchasing, metrics generated will show the reduction of fraud in these accounts, as the merchant does not access the financial account information.

The merchant checker doesn’t need ID, doesn’t need to handle or look at the handset. The merchant doesn’t need to know who you are. Just the wink from Apple (in the form of authorization cide) that you are golden.  There is No merchant transaction copy. Not paper. Not e-records. No databases.

Privacy buttonHow is this level of privacy attained?

Remove the the merchant from even being privy to or have authorization or requirement from documenting anything about the transaction because someone else has all of that part covered, and show them how the process works. The process must eventually be used by everyone to eliminate this specific kind of fraud. Even though there can be a variance on how the SE is designed to work with the system, there are some important non-negotiable needs users to be aware of. For Pay and Android pay to operate with conformity to the following:


  • ? A method to Validate an account from a bank or other financial institution containing an amount of money that is equal to the merchant+customer agreed upon price (verified by the customers authorized financial network to use that account as a resource that can cover the cost of the agreed upon (with merchant) transaction.)
  • ? A cellphone based hardware or software/on device or off methods for authentication or processing encrypted authentication data in a solution (using sensor data like : location data, biometric scanner data, SE acknowledgement and key, and other parameters) deployed by the customer who is the provider of authentication and seeking authorization.
  • ?  The contactless scanner (POS) to receive request and recieve authentication data from the handset through a contactless scanner located at the merchant point of sale system.

Failures in the current card payment processing system


What is wrong with the current system?

  • Fraud
  • Lack of transparency
  • Lack of respect for privacy
  • Burden of risk accepting Credit cards
  • Data collection policies favor take it all rather than take what is required.
  • Lack of adequate security due to improper placement of the customers preference to auto-opt in data sharing rather than , ‘Just call us if you don’t want us and all of our friends or maybe some people we haven’t met yet can use each others data that we have collected on you, and fill in the blanks as needed  (all of them) to create 2 identical files…oh and you better make sure the data isn’t wrong.
  • Data brokering should be regulated. Not because I’m a liberal, but because the best way to get some vision into the specific data matrix that describes what makes a complete ‘Google’ record on someone?

Do we need a new system?

New improvex

Not just new, different. The processes and the culture needs to be managed. In other words, what the world needs one safe and easy was to pay for things that doesn’t compromise the personal data of the person making purchases. This is the data from the event that gets documented at the transaction point by the merchant but only if you use a card for the purchase. It is these documents that get stored on a database by a retail sales outlet for no logical reason. These databases get hacked, its data compromised and the and private financial and personal data that is stolen gets used to commit fraud that places even more weight of process responsibility.

This data is used by criminals to damage the digital identity and credit rating of the owner by using their information to apply for other credit cards. Seeing that the discrepancy was the method itself, the decision to draft a new standard and build the guidelines was made.

Why do we need a new one?

  • Boost and reinforce consumer confidence in the market
  • Establish a pro-consumer environment
  • Re-integrate consumer Privacy into the purchase process
  • Eliminate fraud

From an economic standpoint, enabling an environment where the consumer is able to take possession of something immediately from the Merchant is valuable for struggling and growing markets alike, but only if the payment is eventually received.

People spend money on things in impulse. If someone says they have the money (but not actually on them) and they want to ‘buy’ something, why should not actually having the money stop someone from having what they want from the market? Removing the actual process of manually depleting physical cash from a wallet also removes another opportunity for the customer to think about changing their mind on the purchase.

Fraud and crime are a detriment to local economies. Both as a drain on operating costs and the effort expended to combat fraud inside the business (leaving less budget for positive programs like Corporate sponsored community outreach/projects), and on the taxpayer (police must investigate fraud) Often resulting in the loss beight written off by the business against a subsidized by government policy or sold to debt collectors. Who then harass the wrong person for debt reconciliation.

What is the all of the Merchant record fraud going on?

When it comes to credit card fraud you can look at 3 things:

  • People who steal people’s actual credentials (wallet/purse) and use those cards or try to produce more credit cards based on the credentials of the legal owner of the ID.
  • People who buy lists of data…merchant data to create other fraudulent accounts and produce cards as well.
  • People who hack databases and rummage through paper waste looking for data to use or sell to the person above.

First lets recognize that removing the merchant from the list of authorized service providers with access to the transaction data also removes fraud capability from 2 of the 3 sources. Most of the ‘monetary’ damage that fraud does is against the merchant. By accepting a fraudulent credit card and delivering a product that hasn’t been paid for by the bank, a shortage in the till and the warehouse is caused. They need to get paid. But as soon as the bank pays them, the liability for the fraud is now incumbent upon the financial institution.

So there is a reluctance to pay. The transaction data is only needed by the financial institution with the merchant as the data point-of-capture, but because of the risk they assume to accept credit cards as a form of payment. That risk consists of you actually paying and the risk of actually getting paid later for the merchandise that you are letting someone walk out the store with right now.

Who will benefit?

The Merchant

From the merchant perspective, its desirable to have an easy check-out process with nothing impeding the sales transaction. As a proprietor, unless you have built consumer loyalty, people obviously impulse buy where ever they are. If your shop is the one who inspires a purchase, but you don’t accept what the customer has for payment they will likely buy it from the next place that does. Accepting credit cards is a pain. Collecting, processing, arguing….and using the receipt of the transaction as proof of the debt.

Choosing to accept credit cards means menchants make more sales, but they do more work, and are responsible for the cost incurred until paid by the bank and therefore assume more risk. Because of these records and documents kept by the merchants in case of a legal disputes, they inadvertently place themselves in a position to be targeted by identity thieves. If someone is looking to steal something from your business, your customer data is more valuable and you could be held liable for costs that easily eclipse anything you could possibly be selling on the show floor.

The Consumer

It’s always nice getting what you want, getting it where you choose, and getting it right now irrespective of the fact that you have no money in your pocket. You have a phone. That should really be enough.

If deployed correctly, an opportunity exists for a new payment system. It has the ability to eliminate fraud that uses PID records from transactions between the merchant and the consumer. This data fuels the efforts of operations that harvest transaction data from retail corporations and hang the private data of their customer out on the public IP. Someone gets that data, sells that data and someone will eventually consume that data in the process of criminal activities relating to identity fraud, either to purchase or sell the ability to purchase, retail goods using an illegally obtained account.

The consumer must be protected, and his privacy and financial transactions records need to be shown respect. The only way to do that is to lI it the visibility of transaction data to those who must see it.

How do we get there from here?

Things need to change. Processes need to change. Culture and attitudes need to change. Consumer Privacy needs to be at the top of the list.

Sharing transaction data with anyone who is not needed to complete the transaction, elevates the risk of privacy breech.

What this boils down to is what happens when someone was faced with a dilemma during an analysis of the existing payment system. Their concern was generated from what could happen (again) using existing technology.  The data capture practice is allowing the privacy of user to be violated and their identity stolen and sometimes they are put into financial ruin because of the result. This data is captured at the POS (point of sale) and stored by the Merchant.

Merchants capture this data for records in the event of a dispute or issue, either legally or operationally. But there is no reason why a merchant should keep personal and financial data stored from someone who bought fifty cents worth of candy 5 years ago. But if that candy was bought with a credit card, it more than likely is.

Merchants who capture financial data and present the data wits records that also have personal identifying data, photos and a copy of the signature because they are conditioned to do so by banks and by those who investigate the fraud, inadvertently collect exactly what is needed for a ID thief to create fraudulent accounts an put it all in one spot. Creating and maintaining copies of the receipts and other data is the only thing that merchants can provide for their own indemnification to loss by fraud. So banks ‘pay as late as possible’. Not only do processes need to be changed, but culture needs to be changed as well.

Technology Insertion

Documented here and used only as a reference for guidelines and not a set of requirements: The Secure Element API

Pay and AndroidPay use the Secure Element API specification for secure transactions using mobile devices. Utilizing the SE that is either hardware based (like discrete a computer chip) or complicated software based process to generate each data value.This specification allows development of web applications making use of these secure element applications. Some typical use cases that applications can address based on this API include:

  • Authentication: Instead of user name and password, access to an online service may be protected by a strong authentication mechanism, based on credentials stored and processed in a secure element. In web-based operating systems, system applications such as VPN (Virtual Private Network) or eMail application may use of the secure element to authenticate the user.
  • Digital Signature: Applications may use the secure element to digitally sign a document or any data with a key stored in this secure element. The signature operation itself is executed inside the secure element, ensuring both the integrity of the signature and the confidentiality of the key used in this process. For instance, this could be used by an eMail application to sign emails sent by the user. Or by a government web application to sign a online administrative request.
  • Payment: Online commerce may use widely used smart credit cards, or specific payment applications, to enforce the security of online transactions. On cellular telephony environment, the on-card payment application may be hosted on the SIM card, alleviating the need for the user to handle multiple physical devices.
  • Credential provisioning: The content of a secure element may be updated to install, update or remove an application or any credential it may host. For instance a public transport application may offer a user to credit her NFC-enabled transport card with tickets bought online. Or a corporate intranet web application may offer employees to renew online the X.509 certificates hosted in their corporate badge, so that they can do this operation from anywhere just before these certificates expire.

Continual Process improvement

The processes that no longer make keen business sense need to be removed what they are obsoleted. The practice of using the Merchant as the records repo for financial transactions between the customer and financial institution is a poor practice. Here is how each company (Google and Apple) decided to deal with the privacy aspect of transaction data:

Apple Pay

  • Removed the merchant and themselves from being able to see the details of the transaction data. By boing so, they mitigate fraud and protect the merchant and themselves from the liability of privacy violations.

Google AndroidPay

  • Adjusted their privacy policy to allow sharing consumers private transaction specifics to a number of non-Google business partners



They are not the same despite doing some of the same things

??They are both mobile solutions (using a cellphone) for financial institution backed transactions (credit or debit card) between a 2 party agreement (C2B ‘customer to business’ in this example, but peer-to-peer payment functions are used elsewhere) to exchange currency for a consumer purchase without actually having the currency to exchange in his pocket, he can allow enough systems to verify he has it in a bank, and if it can put an pre-authorization hold on an amount equal to the transaction, that includes electronic documentation that designates who the hold money is promised to, because of ‘transaction Id’ and that but there is enough data provided evidence that the promise to pay going along with transaction is in good faith.

Why privacy is important

Target oay

Target: Great place to buy milk and pick up some socks. Not a great place for keeping your private data like ‘secure’ bank-card transactions from past shopping visits on a database. Why should they be? Target doesn’t claim  claim to have the best database network security or proper paper destruction policies in their commercials. But Databases get built. Garbage cans get rummaged through and networks get hacked to steal user data from which other fraud will be perpetrated. Most people say, ‘Well Target screwed up, they need pay up to fix their transgressions!’ While I don’t disagree, I’m more interested finding out why these records are kept in the first place. Why are they even generated? And if they don’t have to be generated, how much credit card based fraud can be eliminated?


They designed a replacement transaction method for getting all of the authentication data decrypted and where it needed to be for a purchase to happen. This transaction is usually between a consumer and a financial institution over shared (or not shared in ApplePay) infrastructure using a cellphone providing GPS (location) that matches the location data of the contactless scanner residing at a merchants (usually) physical location, a fingerprint sample for biometric security verification which also integrates AppleID into the equation for embiggened security bonus on iPhones that utilize Pay.

What is left to do

The means to provide people with the level of access to their own (verified by bank) money and a merchant can be convinced that the means to pay for, the intent to make good on and personal guarantee payment will be made and that this is all in good faith conveniently let’s us have things and take possession right now, without actually having to produce any physical money.

The Rebuilding of trust between merchants and consumers. When it comes to privacy This is essential for market confidence. By using processes that put customer privacy and customer sat first and by using methods that reduce or eliminate fraud and other crimes, the entire industry and logically the overall economy will benefit from reduced product cost. This reduction is due to the cost avoidance acquired from no longer needing large anti and counter-fraud systems. After the privacy component is placed at the top of the priorities, you can begin building fielding a payment system to service your customers that has their best interests in mind. There are 2 keys needed for this to happen:

  • Key #1 to making this project possible is building the relationships between merchants, banks and government first. And not to do anything stupid that risks impacting the level of confidence your new friends have in your vision of a financial network and payment service by creating it with customer privacy out front.
  • So less people have access to these financial records, remove the task (and the liability) from the merchant regarding the need to capture event data at the transaction point is Key #2

Build the relationships, buy the permits, get the licenses needed to facilitate all of this to function, and then announce that a better (it is actually theoretically much better than what is used now) process which is more secure, easier to use and actually safer for your data. By removing the residuals left from a practice that was created for no good customer centric reason (i.e.: why do you need to know and remember that I bought 2 milks using my card), you can build your own financial infrastructure charging yourself with the responsibility to provide the customer with better privacy and security. But you also remove the responsibility off the merchants shoulders for transaction record storage, and the civil liability a merchant can incur if that customer data is compromised.

That’s a win/win


Merchants who capture financial data and present the data with their own records and the records from other non-requirement providers, in order to make that data more valuable to advertisers, as the merchants inadvertently collect exactly what is needed for a ID thief to create fraudulent accounts using another persons good name. Creating and maintaining copies of the receipts and other data is the only thing that merchants can provide their own indemnification. So banks ‘pay as late as possible’. Not only do processes need to be changed, but culture needs to be changed and new technology for authentication is needed as well.

You can’t change something if you don’t have the authority to make changes, so using someone else (like Pulse) for the ApplePay method doesn’t allow Apple to make up the rules. You don’t really control and can’t protect services required for this customer-to-bank process that is business between banks and their account holders only. So Apple actually built and owns the infrastructure that Pay is deployed on.

That is a major difference between Pay and AndroidPay, but it isn’t the biggest difference. The philosophical difference between Pay and AndroidPay can be found in the following privacy statements that I read during my sign up for AndroidPay on my Galaxy S3:


The biggest difference between Pay and AndroidPay sits squarely on the contrasting philosophies of each company. One values its customers privacy, the other values access by its partners to its customers private financial records for monetary gain. Because of this, the basic operating tenant of consumer privacy can’t benefit Google partners in any anti-fraud campaign because Google doesn’t respect people’s privacy:






The Sharing transaction data with anyone who is not
 needed to complete the transaction, elevates the risk of privacy breach.

Pay Will always be more secure than AndroidPay


Mountain View

Circle androidGoogle wants to charge ahead with the same solutions that maintain the environment that can  cause the same fraud because of their reluctance to respect the end users privacy. By adjusting their privacy policy to be more accomodating to the needs of data harvesting for business part era over the needs of the user privacy, they counter the efforts of what the SecureElement API was created for. Only the customer and the bank need transaction data. Google and Google’s partners do no need transaction data. Data thieves go to where the data is stored.








PayApple has done its due diligence, understands the origin in payment processing fraud and has gone the extra mile to show it is serious about keeping their customers privacy out front. They have even removed themselves from being privy to the transaction data. Pay will therefore have the propensity to be remail head and shoulders above the AndroidPay process who reserves the right to share your transaction data with advertisers, partners and 3rd party solutions.


%d bloggers like this: