Support requesting billing address #749

marcoscaceres · 2018-07-06T14:27:11Z

Part 1 for #27 (part 2 is #750)

The following tasks have been completed:

Confirmed there are no ReSpec errors/warnings.
Added Web platform tests
added MDN Docs - will be done as part of the with Firefox work.
added MDN compat data

Implementation commitment:

Safari (link to issue)
Chrome
Firefox
Edge (public signal)

Impact on Payment Handler spec?

Preview | Diff

domenic

All nits

domenic · 2018-07-09T20:31:17Z

index.html

+          "PaymentOptions.requestPayerAddress">requestPayerAddress</a> member
+          was set to true in the <a>PaymentOptions</a> passed to the
+          <a>PaymentRequest</a> constructor, then <a>payerAddress</a> will be
+          the payer's address chosen by the user.


This paragraph seems like it could be more similar to the shipping address one. E.g., mentioning the payer address changed algorithm.

domenic · 2018-07-09T20:31:39Z

index.html

+          the payer's address chosen by the user.
+        </p>
+        <p class="note">
+          On some user agents, the some attributes of the <a>payerAddress</a>'s


"the some" -> "some"

"the payerAddress's" -> "payerAddress"

domenic · 2018-07-09T20:32:00Z

index.html

+        </p>
+        <p class="note">
+          On some user agents, the some attributes of the <a>payerAddress</a>'s
+          might be redacted until the <a>user accepts the payment request</a> -


hyphen minus -> either em dash (—) or just use a comma

domenic · 2018-07-09T20:32:11Z

index.html

+        <p class="note">
+          On some user agents, the some attributes of the <a>payerAddress</a>'s
+          might be redacted until the <a>user accepts the payment request</a> -
+          at which point all the user provided details of <a>payerAddress</a>


"user provided" -> "user-provided"

domenic · 2018-07-09T20:36:10Z

index.html

+              </li>
+              <li>Set the <a data-lt=
+              "PaymentRequest.payerAddress">payerAddress</a> attribute value of
+              <var>request</var> to <var>payerAddress</var>.


It'll be worth testing that UAs create distinct objects here and change payerAddress to the new PaymentAddress object. That is, they can't mutate the existing object; per this spec they have to create a new one.

Will make sure to test that.

domenic · 2018-07-09T20:45:35Z

Hmm, substantive concerns at #27 (comment); I'd appreciate your (or others') thoughts there before merging this.

marcoscaceres · 2018-07-19T23:25:19Z

Gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1477117

marcoscaceres · 2018-08-10T04:26:56Z

Closing, due to lack of consensus.

marcoscaceres · 2018-08-14T06:45:25Z

@adrianhopebailie, @ianbjacobs, @rsolomakhin:

Ok, so given feedback in #27 and teleconferences we've had. How about I do:

Rename: PaymentOptions.requestPayerAddress -> PaymentOptions.requestBillingAddress
Drop: PaymentRequest.payerAddress and PaymentResponse.payerAddress.
Add "redacted" billingAddress to Basic Card's event response: User changes payment method payment-method-basic-card#53 - which is nulled when requestBillingAddress is false. Then, when the user changes instrument, the event fires and you get the billingAddress but not the card information. The merchant then can call .updateWith().
Lastly, the merchant always gets the billing address in the PaymentResponse.details - which they can request adjustments with via .retry()

Agree?

rsolomakhin · 2018-08-14T15:43:31Z

This looks good to me as is.

marcoscaceres · 2018-08-15T02:09:15Z

@rsolomakhin, thanks for the feedback. The issue that come up previously is that billing address is always bound to an instrument, so it might make more sense to just attach the billing address to the "paymentmethodchange" event.

Basically, the model that is currently specified stays the same... the deck chairs just get rearranged a bit.

marcoscaceres · 2018-08-15T06:54:30Z

Ok, now matches #749 (comment) and I've also updated w3c/payment-method-basic-card#53

rsolomakhin · 2018-08-15T18:52:00Z

I do prefer a paymentmethodchange event that includes a redacting billing address if necessary. @marcoscaceres 👍

marcoscaceres · 2018-08-16T01:15:06Z

@domenic, the updated PR is basically a rewrite (smaller tho:)). Do you have cycles to re-review it?

@rsolomakhin, do you want to give it a good look over and see if the text matches how you would implement this?

rsolomakhin

Overall looks good. I have a question and a nitpick suggestion.

rsolomakhin · 2018-08-16T15:13:35Z

index.html

@@ -3881,9 +3904,16 @@ <h2>
            </li>
            <li>Set <var>event</var>.<a>[[\waitForUpdate]]</a> to true.
            </li>
+            <li>Let <var>identifer</var> be undefined.


@marcoscaceres I would prefer to name this methodIdentifier to avoid confusion with the Payment Request identifier. paymentMethodIdentifier and pmi would also be OK.

Also, "identifer" -> "identifier"

@rsolomakhin, so I totally agree: problem is we have methodName attributes on both PaymentResponse and PaymentMethodChangeEvent, both standing for PMI. Changing this one to be pmi or paymentMethodIdentifier would make this one the odd one out 😢

Although methodName is a terrible name, I'd prefer we stay consistent. Is that ok?

@rsolomakhin sorry, I misread this out of context! You meant the local variable in the algorithm. Sure, I'll change it.

index.html

domenic

I've lost track of the plot on what feature this implements and how, but at least editorially it seems reasonable, with only a few nits.

I guess my biggest substantive question is why we're adding requestBillingAddress to PaymentOptions when it sounds like we're keeping billing address as a payment method-specific thing. (E.g., it is not returned in any property of PaymentResponse.) If that's the case, shouldn't whether or not to request the billing address be part of the payment method data?

domenic · 2018-08-16T19:46:32Z

index.html

@@ -3881,9 +3904,16 @@ <h2>
            </li>
            <li>Set <var>event</var>.<a>[[\waitForUpdate]]</a> to true.
            </li>
+            <li>Let <var>identifer</var> be undefined.


Also, "identifer" -> "identifier"

domenic · 2018-08-16T19:48:55Z

index.html

-          <var>detailsPromise</var> settling. If <var>detailsPromise</var>
+          <var>detailsPromise</var>, a <a>PaymentRequest</a>
+          <var>request</var>, and optionally a DOMString <var>identifer</var>
+          (a <a>payment method identifier</a>). The steps are conditional on


I don't think it should be optional. It should just either be a string or null. Spec-ese doesn't have the nice JavaScript thing where undefined = missing, so the below is actually broken when the third argument is not passed.

Yeah, true that. Will fix.

domenic · 2018-08-16T19:49:33Z

index.html

+                  <var>identifer</var>, then <a data-cite=
+                  "!WEBIDL#dfn-convert-ecmascript-to-idl-value">convert</a> <a>
+                    paymentMethodErrors</a> to an IDL value. Otherwise,
+                    <a data-cite=


It's already an object, so no need to convert.

Ok yeah. I thought it was still a JS object and it was being converted into an IDL object. We might need to check other parts of the spec, as we do the same thing in other places.

ianbjacobs · 2018-08-16T20:00:48Z

@domenic,

billingAddress should be part of the payment method data. The thing is that in some cases, the Total depends on the billingAddress (e.g., VAT computation). The merchant wants to know about the billingAddress while the sheet is open to display a correct total.

I believe the solution of this pull request will work for those payment methods build into the browser (e.g., basic card). However it will not work for some payment methods supported by payment handlers (e.g., for push payments or real-time credit financing) until we do something else. I'm synthesizing what I'm hearing here:
https://github.com/w3c/payment-request/wiki/PushPayments

Ian

marcoscaceres · 2018-08-17T02:53:22Z

@domenic wrote:

I guess my biggest substantive question is why we're adding requestBillingAddress to PaymentOptions when it sounds like we're keeping billing address as a payment method-specific thing. (E.g., it is not returned in any property of PaymentResponse.) If that's the case, shouldn't whether or not to request the billing address be part of the payment method data?

Yes, you are absolutely right! It should be part of the method data. I'll fix that.

@ianbjacobs, wrote:

I believe the solution of this pull request will work for those payment methods build into the browser (e.g., basic card). However it will not work for some payment methods supported by payment handlers (e.g., for push payments or real-time credit financing) until we do something else.

I really need your help understanding what "something else" could be. I've read over everything provided thus far, and tried to make sure the updated PR addresses the push payment use case (as I understand it). If it doesn't address the use case, then I want to fix that - but I need your help showing me that what I've proposed here is actually unable to address the use case.

Ian, would it be best to have a call about it? We've successfully resolved issues like this before when we've chatted (or you've successfully explained to me how wrong I am 😅). We only get one real shot at this, so we gotta make sure we get it right.

rsolomakhin · 2018-08-17T14:01:43Z

@marcoscaceres : I think @ianbjacobs wants to make changes to Payment Handler, but this PR should work.

@ianbjacobs : Did I understand you correctly? Please add me to the call, if you have one at a convenient time.

ianbjacobs · 2018-08-21T22:46:03Z

After chatting with @marcoscaceres and @rsolomakhin we would like clarification on one point: if a merchant needs a billing address (e.g., for VAT computation), will that merchant need the billing address for EVERY payment method the merchant would accept?

The answer to this question affects the design, roughly as follows:

If the merchant needs a billing address for EVERY payment method, it is easier to indicate that once through the API.
Otherwise, the merchant will need to request the billing address on a per payment-method basis.

As an example, would a merchant ever need billing address for a basic card payment, and not need a billing address for payment by credit transfer, or cryptocurrency, or real-time financing, etc.?

@lyverovski, @Krystosterone, @michelle-stripe, @asolove-stripe, @mattsaxon, @vkuntz, @frank-hoffmann we welcome your input here.

asolove-stripe · 2018-08-22T22:13:06Z

I think there are probably some cases where you only need billing address for one method. I could imagine wanting it for card so you do AVS on a card, but don't care about it for other payment methods.

That said, the main use-case here is still where the billing address affects tax or other calculations controlling the total. For that use-case, it's really the same across all payment methods.

stpeter · 2018-08-22T22:19:43Z

Thanks @asolove-stripe! As @adrianhopebailie mentioned on a call right now, if billing address is needed for VAT then it would be needed no matter what the payment method might be. I still worry a bit about non-VAT use cases where a user might be asked for a billing address when that's unexpected for their chosen payment method, but maybe we don't have a good handle on those yet.

marcoscaceres · 2018-08-23T01:28:47Z

Ok, we can go back to having it as a "global" requestBillingAddress on PaymentOptions.

In the future, if we need to, we can go more fine grained by adding requestBillingAddress on specific PaymentMethodData's if the case arrises.

This reverts commit 5191fe0.

marcoscaceres · 2018-11-27T01:25:47Z

@rsolomakhin @aestes, @zouhir just wanted to confirm if you are also planning to support this (requestBillingAddress)?

Firefox's plan is always return null for billing address unless this is set to true.

rsolomakhin · 2018-11-27T15:11:31Z

Yes, we plan to support this in Chrome, but the exact behavior needs to be thought through and fine-tuned on our end. The Firefox decision seems reasonable is in the realm of possibilities for us.

snez · 2018-11-27T15:44:31Z

I am currently using Stripe's javascript API with the paymentRequestButton, and I have found the billing address to be available in the returned json object when the customer selects a card. I.e. the billing address registered with the specific card comes back as part of the card details json object. Not sure if the underlying implementation is something that Stripe has done, or if it is part of the paymentRequest API, but it solves the problem in my case.

marcoscaceres · 2018-11-28T02:46:36Z

Hi @snez, you wrote:

Not sure if the underlying implementation is something that Stripe has done, or if it is part of the paymentRequest API, but it solves the problem in my case.

If I may ask, could you help us understand what you are using the billing address for?

marcoscaceres · 2018-11-28T02:49:02Z

Put up a test for review: web-platform-tests/wpt#14255

marcoscaceres · 2018-11-28T02:52:25Z

Just a quick update: Firefox patches for requestBillingAddress should be landing hopefully tomorrow.

marcoscaceres · 2018-11-28T10:16:31Z

File chrome bug, based on @rsolomakhin comment #749 (comment)

snez · 2018-11-28T11:15:50Z

Hi @snez, you wrote:

Not sure if the underlying implementation is something that Stripe has done, or if it is part of the paymentRequest API, but it solves the problem in my case.

If I may ask, could you help us understand what you are using the billing address for?

The billing address is a minimum requirement for many large eCommerce systems in order to place an order (in my case Magento). I wouldn't be able to programmatically create an order without it, and thus the whole idea of accepting payments from the product page could not be implemented (see https://magento2.cryozonic.com/radiant-tee.html for an example), which is a perfect use for the paymentRequest API, and something that many merchants are trying to implement to improve their conversions.

marcoscaceres · 2018-11-28T11:36:38Z

Thanks, @snez, for the example and details. That’s super helpful.

This was referenced Jul 6, 2018

Should API support billing address capture (for tax computation)? #27

Closed

Add error reporting billing address #750

Closed

domenic requested changes Jul 9, 2018

View reviewed changes

domenic approved these changes Jul 9, 2018

View reviewed changes

marcoscaceres added the needs tests label Jul 10, 2018

marcoscaceres force-pushed the billing branch from d33fc4b to 330e546 Compare July 16, 2018 18:57

marcoscaceres closed this Aug 10, 2018

marcoscaceres reopened this Aug 14, 2018

marcoscaceres changed the title ~~Add ability to request payer's address~~ Add ability to request billing address Aug 14, 2018

rsolomakhin approved these changes Aug 16, 2018

View reviewed changes

domenic reviewed Aug 16, 2018

View reviewed changes

marcoscaceres force-pushed the billing branch from a25c0db to 1337ed1 Compare August 20, 2018 03:39

marcoscaceres changed the title ~~Add ability to request billing address~~ Support payment method errors Aug 20, 2018

ianbjacobs mentioned this pull request Aug 21, 2018

Add support for communicating billing address to merchant (e.g., for VAT computation) w3c/payment-handler#314

Closed

marcoscaceres added 15 commits November 22, 2018 18:00

review nits

1e27643

nit

2fd6717

Define payerAddress more like shippingAddress

0a9d479

tidy

693094f

refactor based on discussion

01018e5

Do IDL conversion

0083422

fixup

b2239f2

put requestBillingAddress in alpha order

292ac8f

remove requestBillingAddress

0819123

Review feedback

3a1ee9f

DOMString or null

59574dc

Revert position of requestPayerName

b8acadd

Run update algo with null as needed

5bf3b8b

s/identifier/pmi

fbd58b4

Revert "remove requestBillingAddress"

e91e6b4

This reverts commit 5191fe0.

marcoscaceres force-pushed the billing branch from c7d80a8 to e91e6b4 Compare November 22, 2018 07:20

marcoscaceres mentioned this pull request Nov 28, 2018

Test PaymentOptions.requestBillingAddress web-platform-tests/wpt#14255

Merged

marcoscaceres mentioned this pull request Nov 28, 2018

Redact more things from billingAddress w3c/payment-method-basic-card#65

Merged

7 tasks

marcoscaceres removed the needs tests label Nov 28, 2018

marcoscaceres merged commit 974d879 into gh-pages Nov 28, 2018

marcoscaceres deleted the billing branch November 28, 2018 10:17

Support requesting billing address #749

Support requesting billing address #749

Conversation

marcoscaceres commented Jul 6, 2018 • edited by pr-preview bot Loading

domenic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

domenic commented Jul 9, 2018

marcoscaceres commented Jul 19, 2018

marcoscaceres commented Aug 10, 2018

marcoscaceres commented Aug 14, 2018

rsolomakhin commented Aug 14, 2018

marcoscaceres commented Aug 15, 2018

marcoscaceres commented Aug 15, 2018

rsolomakhin commented Aug 15, 2018

marcoscaceres commented Aug 16, 2018

rsolomakhin left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

domenic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ianbjacobs commented Aug 16, 2018

marcoscaceres commented Aug 17, 2018

rsolomakhin commented Aug 17, 2018

ianbjacobs commented Aug 21, 2018

asolove-stripe commented Aug 22, 2018

stpeter commented Aug 22, 2018

marcoscaceres commented Aug 23, 2018

marcoscaceres commented Nov 27, 2018

rsolomakhin commented Nov 27, 2018

snez commented Nov 27, 2018

marcoscaceres commented Nov 28, 2018

marcoscaceres commented Nov 28, 2018 • edited Loading

marcoscaceres commented Nov 28, 2018 • edited Loading

marcoscaceres commented Nov 28, 2018

snez commented Nov 28, 2018 • edited Loading

marcoscaceres commented Nov 28, 2018

marcoscaceres commented Jul 6, 2018 •

edited by pr-preview bot

Loading

marcoscaceres commented Nov 28, 2018 •

edited

Loading

marcoscaceres commented Nov 28, 2018 •

edited

Loading

snez commented Nov 28, 2018 •

edited

Loading