How are payment requests and responses passed between the browser and third-party native wallets?

[msporny]

Migrating from w3c/webpayments#42:

@rsolomakhin sort of described it here:

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();

However, the spec should give folks some idea of how the integration might happen via a NOTE or similar mechanism to ensure that people know it won't be just the OS vendors providing payment apps

[adrianba]

At this point, this is an implementation detail. In the absence of an interoperable approach to this (and nobody has yet proposed one) we should not favour particular browsers or operating systems by including their proprietary solutions in cross-platform specs.

[msporny]

In the absence of an interoperable approach to this (and nobody has yet proposed one)

There have been various proposals.

Rouslan has suggested something that is at least payment-app agnostic above.

Anders and I suggested Intent URLs: https://developer.chrome.com/multidevice/android/intents

You could use the Web Payments CG spec's special domain / callback URL approach for web-based payment apps and register a handler for special payment URLs.

We could settle on intents and ask the other vendors to implement intent URLs, that would be one well spec'd interoperable approach.

we should not favour particular browsers or operating systems by including their proprietary solutions in cross-platform specs.

By not specifying anything we are favoring the proprietary implementations of the largest browser vendors and operating system vendors.

I don't think our approach should be "do nothing" (aka leave it unspecified).

[cyberphone]

A related proposal from Intel:
w3c/websec#65

Personally, I stick to my initial idea which I outlined in
w3c/webpayments#42 (comment)
where the core mechanism ("primitive") wouldn't be bound to the Web Payment API since it is universal like XHR.

[rsolomakhin]

@msporny Intent URIs will point directly to the app. My proposal points to "https://bobpay.xyz" URI, for which an app can register. This is similar to how the YouTube app registers for "http://www.youtube.com" URI. If the user clicks on any youtube link in a browser, the YouTube app opens instead. Personally, I think that "https://bobpay.xyz" looks cleaner than "intent://pay/#Intent;scheme=bobpay;package=com.bobpay.client.android;S.browser_fallback_url=http%3A%2F%2Fbobpay.xyz;end".

We can say in the spec which data is passed to the payment app. How it's passed is going to be different on each platform. I've investigated Android and provided an example of how it could be done. I don't yet know how it can be done on other platforms. I don't think that we should put only Android example into the spec.

Therefore, let's use this issue as a collection of all methods that the data can be passed to the payment app. When we have coverage for a few platforms (e.g. Windows, Windows Phone, Mac, iOS, Chrome OS, Linux), then we can put them in the spec.

[cyberphone]

@rsolomakhin I'm confused. Where does the Web code above run? Inside of the Web Payment API? In this posting you mentioned an entirely new solution, not based on intents:
w3c/webpayments#42 (comment)

[rsolomakhin]

@cyberphone An Android app is able to query other locally installed apps that are registered to handle "https://bobpay.xyz" and invoke them via intents. Sorry for the confusion. I am hoping that this works in 4 steps:

1. BobPay app registers to handle "https://bobpay.xyz" via an intent handler.
2. ShoppingWebsite.com creates a PaymentRequest with one of the supported payment methods being "https://bobpay.xyz".
3. Chrome queries the [PackageManager](http://developer.android.com/reference/android/content/pm/PackageManager.html#queryIntentActivities%28android.content.Intent, int%29) for locally installed apps that can handle "https://bobpay.xyz" and finds the BobPay app.
4. Chrome launches the BobPay app via the intent mechanism, passing to BobPay the payment information.

[cyberphone]

@rsolomakhin That's better but you still need to add a return data method, right? For us who are not (only) into payments the crucial question is: Will this (return data) mechanism be generally available, i.e. not limited to internal use by the Web Payment API?

[cyberphone]

@rsolomakhin I don't fully understand how Android application verification is supposed to work in a payment scenario where there are no pre-defined origins.

[rsolomakhin]

Need to add a return data method.

The Android payment application will need to call its Activity.setResult() method to pass payment response into Chrome. The payment response should be a string.

Intent result = new Intent("org.w3.intent.action.PAY");
result.putExtra("PaymentResponse", "{"
        + "  \"cardNumber\":       \"4111111111111111\","
        + "  \"cardholderName\":   \"Bob J. Paymentman\","
        + "  \"expiryYear\":       \"12\","
        + "  \"expiryYear\":       \"2016\","
        + "  \"cardSecurityCode\": \"123\""
        +"}");
setResult(Activity.RESULT_OK, result);
finish();

Chrome will parse this string into a JavaScript object and will use it to resolve the JavaScript promise returned from PaymentRequest.show().

[rsolomakhin]

there are no pre-defined origins.

When you say "origin", do you mean tuple(scheme, host, port)? My thinking was that the payment app will use the URL of their website as the payment method identifier. This URL can include a path as well.

For example, suppose BobPay company publishes BobPay Android app and owns the bobpay.xyz hostname. They can use "https://bobpay.xyz/pay" as the payment method identifier. BobPay company needs to publish a developer tutorial that specifies their payment method identifier, what extra data the BobPay app needs, and the format of the data that BobPay will return.

Android application verification

App verification is a security feature in Android not related to payments directly. App linking is a feature on newer Android versions that sets the default URL handler without user interaction. The user can change their default URL handlers in settings later. This feature is transparent to Chrome. Chrome can ask the the OS to launch an app responsible for a certain URL. The launch happens via an intent.

[burdges]

Intent URLs sound interesting. We've this idea of payment mediator though, so presumably the intent url should invoke that, let the user select their payment app, and then pass the intent to it. A payment app should not register as a handler of that intent itself.

[adrianhopebailie]

We shouldn't prescribe how native apps are integrated because this will be platform specific. On the other hand we should prescribe how payment apps are supported by the user agent on the Web platform.

The messaging that is passed between the payment mediator and payment app, as defined for web-based apps will be re-usable for native but there is no obligation for platforms to use them.

[adrianhopebailie]

Being addressed in the Payment Apps proposal at: https://w3c.github.io/webpayments/proposals/paymentapps/payment-apps.html

[msporny]

Please point to section or issue. Someone reading this issue has no idea how the payment apps proposal is addressing this issue.

[ianbjacobs]

This will be discussed here:
https://w3c.github.io/webpayments/proposals/paymentapps/payment-apps.html#payment-app-invocation-and-response-1

But we are still working on it so it's not defined how yet.

I don't know that we need to carry an issue forward to that spec since we already have bits in the spec that we're working on.

Ian

[cyberphone]

Apple's method for dealing with this issue
https://developer.apple.com/reference/applepayjs/applepaysession

var request = {
  countryCode: 'US',
  currencyCode: 'USD',
  supportedNetworks: ['visa', 'masterCard'],
  merchantCapabilities: ['supports3DS'],
  total: { label: 'Your Label', amount: '10.00' },
}
var session = new ApplePaySession(1, request);

Is clean and not OS-specific.

[msporny]

This will be discussed here: https://w3c.github.io/webpayments/proposals/paymentapps/payment-apps.html#payment-app-invocation-and-response-1

That's what I was looking for. @adrianhopebailie just pointed to the spec which leaves the reader of the issue without any idea which section of the spec he's talking about.

The section you point to doesn't address the issue wrt. native apps as far as I can tell.

I don't know that we need to carry an issue forward to that spec

My request was to not carry the issue forward, it was to point to the section of the spec (or another issue) where the concern raised by this issue was being addressed.