How are third-party native wallets integrated? about webpayments

[rsolomakhin]

I think that native apps will connect through OS-specific means, like intents on Android. Here's how user agent code would look like on Android, I imagine:

Intent intent = new Intent("org.w3.intent.action.PAY", Uri.parse("https://bobpay.xyz"));
intent.putExtra("Details", "{\"price\": 5500, \"currency\": \"USD\", \"merchant\": \"superstore1\"}");
intent.putExtra("SchemeData", "{\"bobPaySpecificField\": \"foo\"}");
startActivityForResult(intent, 0);

The payment app should send back the result as a string (or HashMap) plus the result code. Like so:

Intent result = new Intent("org.w3.intent.action.PAY");
result.putExtra("InstrumentDetails", "{\n"
        + "  \"cardNumber\": \"4111111111111111\",\n"
        + "  \"nameOnCard\": \"Bob J. Paymentman\",\n"
        + "  \"expMonth\":   \"12\",\n"
        + "  \"expYear\":    \"2016\",\n"
        + "  \"cvv2\":       \"123\"\n"
        +"}");
setResult(Activity.RESULT_OK, result);
finish();

We would need similar examples for the other platforms, but I am less familiar with them.

Should we pass in a generic data structure like HashMap or the unparsed string to the payment app?

[cyberphone]

Pardon a silly question: Who sort of "owns" the interface code which BTW looks like Android Java code rather than JavaScript?

[rsolomakhin]

Apps should communicate through an OS-level mechanism, so that linking of interface DLLs or JARs is not required. This requires specifying an interface. For android, the interface could look like this:

• Intent name: "org.w3.intent.action.PAY".
• Intent URL: One of the supported instruments.
• "Details" key maps to the "details" object from the payment request.
• "SchemeData" key maps to the "schemeData" object for this payment app from the payment request.
• The response should have "InstrumentDetails" key that maps to the payment instrument object for merchant.

Android native apps communicate over intents in Java. Other operating systems will use other languages and communication channels. I imagine that apps on iOS would use Objective C.

There should be a JavaScript API for payment web-apps, too.

[cyberphone]

I was probably unclear :-( so please let me rephrase the question...

The idea was (of course) to use the Web Payment API. What I'm asking for is:

• a description for how this API talks to a custom Android, Windows, or iOS payment app
• an (approximate) description of the deployment process

[rsolomakhin]

I believe that I've specified the Android API above. I do not yet have the answers for Windows, Mac, Linux, and iOS.

What do you mean by "deployment process"?

[cyberphone]

If we stick to Android, it is the link between the Web Payment API and
https://developer.chrome.com/multidevice/android/intents
that I'm wondering about including how (and who) is furnishing the Web-part.

I can from the Android docs not see a way to return data to a calling Web application.

[rsolomakhin]

I don't think we will be using https://developer.chrome.com/multidevice/android/intents in our implementation. I am not aware of how this method gets the data back to the Web application. That's a good question, though.

Nevertheless, since we control the implementation of the user agent, we can pass information from Android's setResult() to the calling Web app's payment.request().then() callback.

[adrianhopebailie]

My inclination is to say that this will be implementation specific.

I believe that on mobile platforms the intent is for payment apps to be "apps" in the true sense of the word (i.e. in the same way as the browser itself is an app). Therefor passing the payment request from the browser to the payment app and the response from the payment app back to the browser is going to leverage some form of IPC that is already defined in most mobile OS (like intents as indicated by @rsolomakhin)

How a similar pattern will be achieved on desktop is still an open question. There appear to be at least two options:

1. Browser vendors provide guidnace on how to write browser extensions that register themselves as payment apps (i.e. capable of processing a payment request for a defined set of payment methods)
2. Payment apps will be regular Web applications (i.e. served from a remote Web server) and rendered in a special native dialogue window or an iframe embedded in the merchant website.

There are a number of security and UX considerations to make.

[haavardmolland]

Therefor passing the payment request from the browser to the payment app and the response from the payment app back to the browser is going to leverage some form of IPC that is already defined in most mobile OS (like intents as indicated by @rsolomakhin)

This should still be standardized though, since there will be several browser vendors on each OS.

Payment apps will be regular Web applications (i.e. served from a remote Web server) and rendered in a special native dialogue window or an iframe embedded in the merchant website.

One benefit with regular web applications rendered in a special window is that we can require that the app has to be loaded from a https site protected by a Extended Validation (EV) certificate. That way the app can prove the identity of the app vendor, and we can show the vendor identity to the user. This will make it much harder for a phishing site to create a fake payment app and convince a user to install it. I don't know of any such mechanism for native apps, at least not for Android, or extensions.

[adrianhopebailie]

This should still be standardized though, since there will be several browser vendors on each OS.

What should be standardized? Is standardization of mobile platform IPC something we can include in our scope?

[haavardmolland]

What should be standardized? Is standardization of mobile platform IPC something we can include in our scope?

This was more a side comment, the important part was using extended validation for payment web apps.

However, since we potentially will have many different native apps that need to communicate with different browsers, it seem to make sense to standardize the communication that happens over the IPC. It might very well be that this is not the right forum for it and that it should be standardized by the OS.

[adrianba]

At Microsoft, our view is that any extensibility comes through payment apps and not wallets. We don't have plans to address "How are third-party native wallets integrated?" in a general standardised way.

[adrianhopebailie]

At Microsoft, our view is that any extensibility comes through payment apps and not wallets.

@adrianba how would you differentiate between the two? Would you consider Apple Pay a wallet or payment app?

[webpayments]

FWIW I think that it is very important that we accommodate third party
wallets. There is a whole existing and potential industry out there around
helping a consumer choose the payment method that is best for the current
transaction, protecting the privacy of that payment method, of the
consumer, etc. We can't just arbitrarily disenfranchise that industry.

On Thu, Feb 11, 2016 at 5:56 AM, Adrian Hope-Bailie <
[email protected]> wrote:

At Microsoft, our view is that any extensibility comes through payment
apps and not wallets.
@adrianba https://github.com/adrianba how would you differentiate
between the two? Would you consider Apple Pay a wallet or payment app?

—
Reply to this email directly or view it on GitHub
#42 (comment).

-Shane

[mattsaxon]

+1 to Shane's comment

[rsolomakhin]

One benefit with regular web applications rendered in a special window is that we can require that the app has to be loaded from a https site protected by a Extended Validation (EV) certificate. That way the app can prove the identity of the app vendor, and we can show the vendor identity to the user. This will make it much harder for a phishing site to create a fake payment app and convince a user to install it. I don't know of any such mechanism for native apps, at least not for Android, or extensions.

@haavardmolland: On Android perhaps we can use App Linking. In summary, there're 3 steps:

1. Merchant says they support payment app "https://thepaymentapp.com/pay".
2. Chrome downloads "https://thepaymentapp.com/.well-known/assetlinks.json".
3. Chrome compares SHA256 fingerprint of the Android app to the fingerprint specified in "assetlinks.json".

Step 3 can also include EV certificate validation for https://thepaymentapp.com.

[haavardmolland]

@rsolomakhin : Extending the EV status given to a webserver over to a payment app by storing a hash of the app on the EV server might work.

However, from how I understand App Linking works, it allows apps to open links to a server without user's consent. It does so by comparing the sha256 fingerprint of the app's signer cert with what is provided by the server's assetlinks.json.

Thus, I assume it's the Android OS that compare the signer cert hash with what is in assetlinks.json. Will the browser have access to calculate the SHA256 fingerprint of the payment app's signer cert?

[rsolomakhin]

@haavardmolland : You're correct that Android OS allows such linked app to handle URLs by default. (Little known fact: users can still change the URL handler app in settings.) Apps have access to read the SHA256 fingerprint of the payment app's signer cert as well. See PackageInfo.signatures.

[haavardmolland]

@rsolomakhin : That's great. There is one other obstacle though (which is Chromium specific, so not sure how much that should affect this group). Chromium does not currently do EV evaluation on Android. I believe one reason is that Android lacks revocation support (Chromium uses the OS to evaluate the cert). Revocation support is required for EV sites so that the CA can revoke the site's EV status. Chromium on desktop supports revocation checking of EV certs for that reason. I believe this could be added as an extra check in the Chromium code after Android has evaluated the cert. It might also be possible that it will be added to the new certificate verification library that is currently being developed. But that needs to be discussed with the Chromium network team.

[mattsaxon]

@adrianba, @adrianhopebailie

How does the architecture differentiate a payment app from what the mediator is responsible for in terms of data provision? e.g. The API allows for shipping address to be returned, but it is not clear where this comes from in the architecture, if it can come from a nominated payment application, this may not be a problem, but if it comes from the mediators, we have a lockin or data synchronisation issues across platforms and browsers.

[webpayments]

(This was from @halindrome) See also w3c/payment-request#6 where we have
discussed this.

On Wed, Mar 9, 2016 at 7:40 AM, mattsaxon [email protected] wrote:

@adrianba https://github.com/adrianba, @adrianhopebailie
https://github.com/adrianhopebailie

How does the architecture differentiate a payment app from what the
mediator is responsible for in terms of data provision? e.g. The API allows
for shipping address to be returned, but it is not clear where this comes
from in the architecture, if it can come from a nominated payment
application, this may not be a problem, but if it comes from the mediators,
we have a lockin or data synchronisation issues across platforms and
browsers.

—
Reply to this email directly or view it on GitHub
#42 (comment).

Shane McCarron
Projects Manager, Spec-Ops

[adrianba]

How does the architecture differentiate a payment app from what the mediator is responsible for in terms of data provision? e.g. The API allows for shipping address to be returned, but it is not clear where this comes from in the architecture, if it can come from a nominated payment application, this may not be a problem, but if it comes from the mediators, we have a lockin or data synchronisation issues across platforms and browsers.

I think how to deal with this depends on the extent to which someone defines a cross-platform payment app.

I have heard comments that suggest people want to support native apps (especially on mobile) that can be payment apps. These apps will interface to the browser in a platform-specific way. I have also heard some people propose a web-based payment app that runs in a special browsing context. While it is possible to have this browsing context be platform-specific, I think the desire of those proposing web-based apps is to have a cross-platform interface.

So, in the native app case, how the browser and the payment app choose to integrate or not around shipping address and other similar data is up to those defining the interface to native apps (presumably the owner of the platform or the browser vendor utilising existing native platform capabilities). For the cross-platform web-based payment app case then I think it is for the spec describing how those work to define this.

I don't think the API needs to take a view on where the data comes from.

With that said, it is possible that someone will find implementation barriers on platforms today that cause us to rethink some of the design. That's not limited to this question. For example, the spec currently calls out a "delegated" state but we haven't really decided yet what that actually means in practice for developers.

[cyberphone]

I have heard comments that suggest people want to support native apps (especially on mobile) that can be payment apps. These apps will interface to the browser in a platform-specific way.

@adrianba As far as I understand all interfaces in a browser are implemented in a platform-specific way. However, what's exposed to a Web application does not even in the scenario you describe have to be platform dependent. The following PoC Web payment application works identically on OS/X, Linux, and Windows thanks to Chrome's Native Messaging interface: https://test.webpki.org/webpay-merchant

[adrianba]

However, what's exposed to a Web application does not even in the scenario you describe have to be platform dependent.

My point is that this is out of scope for the API.

[cyberphone]

My point is that this is out of scope for the API.

@adrianba @travisleithead That's perfect! It would be a pity if a feature that have so many other applications would become entangled in the Web Payment API.

[adrianba]

I don't know what feature you're talking about but this discussion has got off track from the original issue.

I recommend closing this issue - I've seen several comments that this is implementation dependent and there are no concrete proposals to the contrary. If someone has an explainer or proposed spec language that addresses this issue in a way that isn't implementation dependent then I recommend they share it. Otherwise, there doesn't appear to be any appetite to pursue this.

[cyberphone]

I don't know what feature you're talking about but this discussion has got off track from the original issue.

The original issue was (and is) native wallet integration.

I don't think this mechanism belongs to the Web Payment WG and API, but it is hard to see how you actually can succeed if this part is left in the air. That is, it should be delegated to an appropriate WG.

As I wrote creating a Web-app independent integration solution is already proven beyond doubt. Specifications have been circulated for almost a year but the interest have been marginal to say the least.

[cyberphone]

@adrianba @travisleithead FWIW, this is what I'm proposing and have implemented: https://cyberphone.github.io/openkeystore/resources/docs/web2native-bridge.pdf#page=4

Applied to the Web Payment API it could work like this:

                         Web Payment API
 (maps methods into serialized JSON-formatted request/response pairs)
                                |
            Bi-directional channel using an IPC mechanism
                                |
                            Wallet App

A more complete specification is available at: https://github.com/cyberphone/web2native-bridge

[msporny]

Migrated to w3c/payment-request#50.