Intent to implement and ship: Add request identifier to PaymentDetailsInit

[Rob Buis]

Intent to implement and ship: Add request identifier to PaymentDetailsInit

Contact emails
rob....@samsung.com, rou...@chromium.org

Spec
https://w3c.github.io/browser-payment-api/#paymentdetailsinit-dictionary
https://github.com/w3c/browser-payment-api/issues/287

Summary
We add an id attribute to PaymentDetailsInit. PaymentDetailsInit will be handed to the PaymentRequest constructor which exposed the identifier through a new id attribute on PaymentRequest. To match PaymentRequest with PaymentResponse we add a new attribute requestId to PaymentResponse.
When no id is specified in the PaymentDetailsInit handed into the PaymentRequest constructor, PaymentRequest generates a UUID for it.

Motivation
This will help with push payments and will allow the payment app and payee website make sure they are talking about the same transaction.

Interoperability risk
Firefox: No public signals
Edge: No public signals
Safari: No public signals
Web developers: Strongly positive
Facebook: strong positive view of the id.

Compatibility Risk
Small.

Ongoing technical constraints
None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
No. PaymentDetailsInit.id can be used only for PaymentRequest, which is currently supported only on Android. Eventually more platforms will support PaymentRequest, except WebView.

OWP launch tracking bug
http://crbug.com/701254

Requesting approval to ship?
Yes

[Chris Harrelson]

Hi Rob,

The feature looks fine to me.

Are there any web platform tests for this API or feature yet? Also, please file a tracking entry on chromestatus.com. Finally, regarding signals from other browsers: did they just not see it?

Chris

--
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.

[rwl...@gmail.com]

Hi Chris,

Sorry for not adding it on chromestatus.com before, I added it now:

https://www.chromestatus.com/features/5645346663301120

I am not part of the specification editing/discussion but do know a mozilla editor added the feature in the specification, so that seems to hint that they are serious about implementing it. As noted Facebook has a strong positive view of the id attribute.

I added more information in the Description about the tests included  in the patch:

Added PaymentRequestIdTest as a payment integration test for verifying the PaymentResponse contains the free-form identifier specified in PaymentDetailsInit Added PaymentRequestTest.DetailsIdIsSet unit test to verify that PaymentDetailsInit.id is reflected in PaymentRequest.id.

Actual web platform tests do not exist for this API AFAIK.

Cheers,

Rob.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Philip Jägenstedt]

https://github.com/w3c/web-platform-tests/tree/master/payment-request has some tests for things that are in https://w3c.github.io/browser-payment-api/

What kinds of tests do you expect to write for this? If it's not possible to do them in web-platform-tests, what we're looking for is a tracking issue for what it would take to automate the tests. I updated the Intent to Ship template a bit today to give some examples here, see the "Is this feature fully tested by web-platform-tests?" section.

[Rob Buis]

I have added two tests to my implementation (https://codereview.chromium.org/2770193003/).

PaymentRequestIdTest is a payment integration test for verifying the PaymentResponse contains the free-form identifier specified in PaymentDetailsInit.

PaymentRequestTest.DetailsIdIsSet is a unit test to verify that PaymentDetailsInit.id is reflected in PaymentRequest.id.

PaymentRequestTest.DetailsIdIsSet could potentially be a web platform test, if there is interest in that? PaymentRequestIdTest actually requires doing a payment using user actions (click Pay, add address/card credentials, close dialog etc.) and I don't think we have a web framework for this.
Cheers,

Rob.

[Philip Jägenstedt]

Ah, I didn't know the implementation was already underway.

The IDL change itself is actually already in https://github.com/w3c/web-platform-tests/blob/master/payment-request/interfaces.https.html, which is imported and failing, can you make sure that goes to passing?

Beyond surface-level coverage like that, it sounds like this needs both input automation and some web payments-specific automation. Can you file issues on https://github.com/w3c/web-platform-tests for the bits of automation that would be required to test a payment request and post links here? Cross-linking with spec issues etc. is nice also.

This looks like a small and simple addition that we should do, but allow me to ask one more thing. All vendors are listed as "No public signals", can you poke around a bit to judge the likelihood that others will eventually implement this? Other are implementing the payments API as a whole, so I assume it's not difficult to find the relevant implementers. 

[Rob Buis]

On Monday, April 10, 2017 at 9:14:55 AM UTC-4, Philip Jägenstedt wrote:

Ah, I didn't know the implementation was already underway.

 

The IDL change itself is actually already in https://github.com/w3c/web-platform-tests/blob/master/payment-request/interfaces.https.html, which is imported and failing, can you make sure that goes to passing?

It does, I adjusted the expectation so that PASS is expected in the patch.

 

Beyond surface-level coverage like that, it sounds like this needs both input automation and some web payments-specific automation. Can you file issues on https://github.com/w3c/web-platform-tests for the bits of automation that would be required to test a payment request and post links here? Cross-linking with spec issues etc. is nice also.

I talked a bit with Rouslan and we do not think such automation is easy/realistic. Instead I added a few new web platform tests including a manual test with instructions. They are added to external/wpt/payment-request which I heard is synced with the wpt repo.

 

This looks like a small and simple addition that we should do, but allow me to ask one more thing. All vendors are listed as "No public signals", can you poke around a bit to judge the likelihood that others will eventually implement this? Other are implementing the payments API as a whole, so I assume it's not difficult to find the relevant implementers.

I talked with Zack and we added a more accurate description to https://www.chromestatus.com/feature/5645346663301120:

"All browsers are supportive (this was voted on in the w3c WG meetings)."

Cheers,

Rob. 

[Rob Buis]

Philip, friendly ping? :)

Cheers,

Rob.

[Philip Jägenstedt]

Sorry Rob, I have yet to come up with a system where threads I've replied too are separate from other things. Pro tips welcome :)

On Wed, Apr 26, 2017 at 1:41 AM Rob Buis <rob....@samsung.com> wrote:

Philip, friendly ping? :)

Cheers,

Rob.

On Thursday, 13 April 2017 10:08:57 UTC-4, Rob Buis wrote:

On Monday, April 10, 2017 at 9:14:55 AM UTC-4, Philip Jägenstedt wrote:

Ah, I didn't know the implementation was already underway.

 

The IDL change itself is actually already in https://github.com/w3c/web-platform-tests/blob/master/payment-request/interfaces.https.html, which is imported and failing, can you make sure that goes to passing?

It does, I adjusted the expectation so that PASS is expected in the patch.

 

Great!

Beyond surface-level coverage like that, it sounds like this needs both input automation and some web payments-specific automation. Can you file issues on https://github.com/w3c/web-platform-tests for the bits of automation that would be required to test a payment request and post links here? Cross-linking with spec issues etc. is nice also.

I talked a bit with Rouslan and we do not think such automation is easy/realistic. Instead I added a few new web platform tests including a manual test with instructions. They are added to external/wpt/payment-request which I heard is synced with the wpt repo.

Manual tests are certainly better than nothing, I've written them and learned things about other implementations using them. Still, for shared interop tests to become the default way of working, for all features and all vendors, we'll have to figure out how to automate approximately everything.

Would you mind filing a blocking bug for https://crbug.com/707649 that described what it would take to write automated tests for this, however far fetched it currently seems? A web-platform-tests issue like https://github.com/w3c/web-platform-tests/labels/type%3Auntestable would also be good if there's anything to discuss with other vendors.

This looks like a small and simple addition that we should do, but allow me to ask one more thing. All vendors are listed as "No public signals", can you poke around a bit to judge the likelihood that others will eventually implement this? Other are implementing the payments API as a whole, so I assume it's not difficult to find the relevant implementers.

I talked with Zack and we added a more accurate description to https://www.chromestatus.com/feature/5645346663301120:

"All browsers are supportive (this was voted on in the w3c WG meetings)."

Cheers,

Thanks! LGTM1, and apologies for the delay. 

[Rob Buis]

Manual tests are certainly better than nothing, I've written them and learned things about other implementations using them. Still, for shared interop tests to become the default way of working, for all features and all vendors, we'll have to figure out how to automate approximately everything.

Would you mind filing a blocking bug for https://crbug.com/707649 that described what it would take to write automated tests for this, however far fetched it currently seems? A web-platform-tests issue like https://github.com/w3c/web-platform-tests/labels/type%3Auntestable would also be good if there's anything to discuss with other vendors.

Done, I filed crbug.com/715243.

 

Thanks! LGTM1, and apologies for the delay. 

Thanks and no problem :) 

Cheers,

Rob.

[Chris Harrelson]

LGTM2

--

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.

[Rick Byers]

LGTM3