Intent to Ship: Android Payment Apps

[Rouslan Solomakhin]

Contact emails

rou...@chromium.org, zk...@chromium.org

Spec

https://docs.google.com/document/d/1izV4uC-tiRJG3JLooqY3YRLU22tYOsLTNq0P_InPJeE

Summary

Web payments is a W3C standard API for e-commerce websites to collect payment information from users with user consent. This feature lets users pay using native Android payment apps.

Link to “Intent to Implement” discussion

https://groups.google.com/a/chromium.org/d/msg/chromium-dev/fsslHD1Gf88/K2KpikS6BwAJ

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No. Android only, because these are Android payment apps talking to Chrome via Android intents. No WebView support because WebView cannot show Chrome user interface, which is required to get user consent for web payments.

Demo

1) Install BobPay.apk on your test device.

2) Enable chrome://flags/#android-payment-apps.

3) Navigate to https://rsolomakhin.github.io/pr/bob/.

4) Click "Buy" button on the webpage.

Debuggability

Use this command to find out why an app is not showing up in web payments UI:

$ adb logcat | grep cr_ | grep -i Pay

Interoperability and Compatibility Risk

Risk is low because other browsers have not implemented yet. We are working close with a number of payment app partners to perfect the APIs always with backwards compatibility in mind.

Edge: No signals.

Firefox: No signals.

Safari: No signals.

Web developers: No signals.

Payment app writers: Positive.

Launch tracking bug

http://crbug.com/684655

Entry on the feature dashboard

https://www.chromestatus.com/feature/5730366077796352

[Ian Kilpatrick]

Hey, just a few slightly naive questions:

1) Is this introducing any new API surface? (I found it hard to determine quickly from the document).

2) Has this / should this go through TAG review? (This is now part of the standard blink shipping process).

3) Should this exist in a proper spec in WICG or similar? I.e. is it reasonable that firefox or another android based browser would want to implement this?

Thanks,

Ian

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Rouslan Solomakhin]

On Tue, Mar 14, 2017 at 5:32 PM, Ian Kilpatrick <ikilp...@chromium.org> wrote:

Hey, just a few slightly naive questions:

1) Is this introducing any new API surface? (I found it hard to determine quickly from the document).

No.

 

2) Has this / should this go through TAG review? (This is now part of the standard blink shipping process).

From my understanding, TAG review helps to shape JavaScript APIs. This is not a JavaScript API, therefore I don't think TAG would be useful here.

 

3) Should this exist in a proper spec in WICG or similar? I.e. is it reasonable that firefox or another android based browser would want to implement this?

It is reasonable that Firefox or another Android browser want to implement this. However, this is API is exposed on Android side, so W3C-type standardization tools seem ill-fitting.

[Rouslan Solomakhin]

On Tue, Mar 14, 2017 at 5:37 PM, Rouslan Solomakhin <rou...@chromium.org> wrote:

On Tue, Mar 14, 2017 at 5:32 PM, Ian Kilpatrick <ikilp...@chromium.org> wrote:

Hey, just a few slightly naive questions:

1) Is this introducing any new API surface? (I found it hard to determine quickly from the document).

No.

Actually, it depends on how you look at it.

Previously, doing something like this will result in NotSupportedError:

new PaymentRequest([{supportedMethods: ["https://bobpay.com"]}], shoppingCart).show();

Now with this feature, users will be able to interact with BobPay app and .show() will either resolve with a payment instrument or reject with AbortError. 

However, keep in mind that PaymentRequest is designed to be extensible in the sense that it does not define how individual payment apps work. Does that make sense?

[Zach Koch]

So just to clarify, when we wrote the PaymentRequest spec, we always assumed there would be third party payment apps whose integration was determined by platform-specific constraints. So Android would define how Android-specific payment apps work, Windows for windows apps, etc. From a spec level, we're following all the right specifications, including Payment Method Identifiers. And our integration is build to work seamlessly with the PaymentRequest API. It just so happens that the receiving app is an Android App. We're also part of the group standardizing how web-based Payment Apps will work.

I'm not sure an Intent to Ship is entirely necessary here, as we are merely letting other native android apps integrate on top of an open web API. But happy to chat further and answer any questions.

Thanks,

Zach

[Jochen Eisinger]

By implementing this, we implement the payment app manifest part spec'd here: https://w3c.github.io/webpayments-payment-apps-api/#payment-app-manifest, right?

[Rouslan Solomakhin]

There's a manifest proposal @ https://w3c.github.io/webpayments/proposals/Payment-Manifest-Proposal.html that aims to specify in W3C language what we have in https://docs.google.com/document/d/1izV4uC-tiRJG3JLooqY3YRLU22tYOsLTNq0P_InPJeE. However, so far it seems that the Payment Manifest Proposal has no use anywhere outside of Android payment apps. Based on discussion in the Payment App Task Force of W3C Web Payments Working Group, it does not seem likely so far that https://w3c.github.io/webpayments-payment-apps-api/ will make use of the Payment Manifest Proposal.

[Jochen Eisinger]

hum, so I guess I agree with Ian that having the TAG review this would be nice.

Without more background, I don't understand why it's worth the risk to end up having to support two different payment app manifest files, one for android and one for web payments.

[Rouslan Solomakhin]

Started a TAG review here: https://github.com/w3ctag/spec-reviews/issues/158

[rou...@google.com]

Actually, I don't think we're quite ready for a TAG spec review. We will get the spec into better shape and then will circle back with both TAG and this thread in the next couple of weeks.

[Rouslan Solomakhin]

This is replaced by https://groups.google.com/a/chromium.org/d/msg/blink-dev/gQCGIrnMxFU/Fz0UDLNeBAAJ now.