To much fanfare MasterCard just launched their new PayPass Online not to be confused with their PayPass Wallet NFC offering.

We’ve packed a whole lot of choice into one ingenious, little button. You see, the PayPass checkout button not only lets you use our PayPass Wallet to checkout quickly and securely, it lets you use any digital wallet offered by a PayPass partner.

I applaud them for trying but unfortunately it is flawed on many different levels. They missed a great opportunity, but they don’t even seem to fix the fundamental security issues in the existing network.

First the good:

• OAuth 1.0A
• User only enters payment information once
• User only enters shipping information once
• Example code for Java/.NET/Android/IOS
• Partner’s can create their own wallets

Now the very bad:

• No OAuth 2
• Returns full credit card account to merchant (yes you read right)
• Very complex flow
• No embedded payment functionality
• Reliance on 3rd party Platform Integrator
• Still requires separate merchant gateway
• Uncertain if it works for recurring billing and electronic goods
• No OpenTransact support
• Only US merchants
• Only U.S., Canada, UK, Australia, Germany, and Japan card holders
• Few clear benefits to US merchants

OAuth

OAuth is a good standard and I have advocated it’s use in payments since the beginning.

OAuth1.0A is very complex though and is much hated by developers. Much of the complexity was to make it work over non SSL connections. PayPass will never be used without SSL so they should have used OAuth 2.0 instead.

As a further step they add further complexity to this by using the RSASHA1 signature method of OAuth 1.

Non tokenized credit card access (Huge problem)

When a user has authorized a purchase and selected a card, the merchant uses the OAuth access token to request shipping and credit card information.

This credit card information includes the full credit number, expiry date etc. As a merchant you are then meant to use your existing credit card gateway to process it as normal.

This completely removes any security benefit of using the wallet. For background on the issues see Breach shows credit card based payment systems fundamentally broken.

MasterCard fixes this by suggesting the use of a 3rd party Payment Provider who do their own tokenization. This still leaves the Credit Card numbers in multiple places where breaches happen all the time.

MasterCard could easily have implemented OpenTransact instead and exposed their own payment endpoint using the exact same OAuth token they issued and they would have avoided this problem completely.

The reason they didn’t was certainly due to political reasons. They still have to feed the long chain of payment intermediaries in their system, so they had to politically allow them to be part of PayPass without forcing them to updating their systems.

Introduces new intermediaries

Since the flow is so complex, MasterCard is hoping that “3rd Party Platform Integrators” or “Payment Providers” as they interchangingly call them are going to handle most of it, as it is definitely too much to ask smaller merchants and old legacy payment gateways to integrate with them directly.

Most smaller merchants already use a platform like Shopify, Stripe or BrainTree as the credit card processing is already too complex.

I suspect these businesses could chose to implement this for their customers, but I don’t see much reason in doing so for them.

Too complex a payment flow

The usage of OAuth1 together with the multiple intermediaries introduces som unnecessary steps:

1. User clicks button
2. Merchant asks Payment Provider for Authorization URL
3. Payment Provider requests OAuth 1 Request Token
4. Payment Provider returns authorization URL to merchant
5. Merchant redirects User to Authorization URL
6. User logs in and authorizes payment
7. User adds payment card and shipping details if necessary
8. Redirect user back to Payment Provider
9. Use Request Token and Verifier to exchange for Access Token
10. Retrieve shipping and credit card details from Checkout Resource URL
11. Payment Provide creates their own payment token and provide that together with shipping information to Merchant
12. Merchant submits payment token back to Payment Provider who sends the credit card information to the underlying payment gateway
13. Merchant displays confirmation page

This leaves a few unknowns such as an API for the merchant interfacing with Payment Provider.

Another unknown is how do you tell PayPass the amount and product that you wish to ship. I couldn’t find that anywhere in the docs.

Proposed flow without intermediaries and with OpenTransact

MasterCard could have achieved the exact same thing but much simpler and more secure by cutting out the intermediaries and using OpenTransact Transfer Authorization:

1. User clicks button
2. User is redirected to PayPass OpenTransact URL
3. User logs in and authorizes payment
4. User adds payment card and shipping details if necessary
5. User is redirected back to Merchant with an OAuth2 auth code
6. Merchant exchanges auth code for a OAuth2 Access Token
7. Merchant uses OpenID/Connect to get shipping information
8. Merchant performs a http post to OpenTransact URL with access token to perform payment
9. Merchant displays confirmation page

The flow could be simplified even further for electronic products and unsophisticated merchants using the OpenTransact Transfer Request:

1. User clicks button
2. User is redirected to PayPass OpenTransact URL
3. User logs in and authorizes payment
4. User adds payment card and shipping details if necessary
5. Payment is performed
6. Merchant displays confirmation page

A smart Payment Provider could provide OpenTransact on their end as well simplifying the PayPass flow for their merchants.

Recurring billing, non physical goods?

I assume this will be supported in the future, but no mention in the docs on how to do so.

Usability?

From what little I’ve been able to see it looks like their userinterface will be as clunky as PayPal. I certainly do believe that credit cards should not be entered straight into merchant forms anymore. But from what I can see MasterCard didn’t take the opportunity to do anything to innovate on usability.

Benefits for merchants?

The only two clear benefits for merchants are:

1. Users don’t have to enter their credit card and shipping details, which in theory should improve conversion.
2. By theoretically having access to credit card numbers you can move payment gateway. It may be harder to move Payment Provider if you end up using one.

I don’t think these benefits are enough for most US merchants to switch over from what they’re using now.

Not international

Like most merchant processing solutions this is not yet available for merchants outside the US. There also appear to be limits on where card holders can be located.

Conclusion

PayPass 2.0 might be a worth while product from a technical point of view. They’ve made a lot of technical errors typical for developers coming from the traditional banking/payment world. But those can be fixed.

The biggest issue is that MasterCard need to cater to the whims of all the intermediaries within their system. I don’t think this is as easy a fix as moving from OAuth 1 to OAuth 2.

mastercard paypass