Merchant-specified default shipping address

[rsolomakhin]

At TPAC we've talked about merchant defining the default shipping address as a requirement for some implementers or merchants. I'm in favor of this feature. Should we also allow specification of other fields? For example, name, email, phone number. Even basic-card related data is conceivable here, but I'm not sure whether any merchant would use that.

cc: @marcoscaceres @aestes @michelle-stripe @jenan-stripe

[marcoscaceres]

Ok, we might need to split this up into more parts to deal with email, phone number, etc. so let's do that separately.

I'll start by with adding the constructor to PaymentAddress (and corresponding init dictionary), which gives us the highest priority thing we need.

Kinda crying now that it's called PaymentAddress as this will be useful throughout the web platform. Too late to rename? We can deal with that later.

[marcoscaceres]

I've started working on this... but have questions about how crazy we want to go with the E.164 conformance.

Playing with the libphonumber demo, it seems to be much stricter than what E.164 requires. e.g., if I'm reading E.164, "+" is optional.

We can come up with a subset, like must start with "+", be at least 3 digits long, and have no more than 15 digits. And we canonicalize that by collapsing white space and "-".

[marcoscaceres]

Modified the canonicalization proposal above to include removing "-". So, +1 800 555-555 becomes "+1800555555". We could be stricter tho with input into the API.

Additionally, PaymentAddress would need to sprout two static methods:

• boolean isValidPhoneNumber(DOMString tel);
• DOMString canonicalizePhoneNumber(DOMString tel);

We should also look at historical discussion around <input type=tel>, as HTML opted not to enforce any structure. cc @sideshowbarker

[sideshowbarker]

We should also look at historical discussion around <input type=tel>, as HTML opted not to enforce any structure.

See https://html.spec.whatwg.org/multipage/input.html#telephone-state-(type=tel):telephone-state-(type=tel)-2:

Unlike the URL and E-mail types, the Telephone type does not enforce a particular syntax. This is intentional; in practice, telephone number fields tend to be free-form fields, because there are a wide variety of valid phone numbers. Systems that need to enforce a particular format are encouraged to use the pattern attribute or the setCustomValidity() method to hook into the client-side validation mechanism.

[jenan-stripe]

It's worth noting that <input>s have the limitation of matching value to display / entry, whereas Payment Request. The user agent may accept many different formats for entry but still output a consistently-formatted value.

[marcoscaceres]

Unlike input, I also think it's workable to require E.164 formatted number, as we are putting the burden on the merchant (instead of the user!) to make sure the number is correctly formatted. If they know the address already (including country), they should be able to format the phone number correctly.

[marcoscaceres]

Just noting that if we are going to specify allowing a default address, we might as well allow a suggested address when validation of a shipping address fails, as per #537.

That is, we should specify something that works for both.

I'm still wondering if we should allow just one suggested address or a set of them?

[marcoscaceres]

Speaking to Editors, we want to push this to a future version of the spec.

[ianbjacobs]

@marcoscaceres,

Does that mean postpone to after the v1 Recommendation, but still in charter for the WG?

Ian

[marcoscaceres]

Yes, precisely. We can still work on it in parallel tho (resources permitting).

[marcoscaceres]

Noting WebKit implementation: https://trac.webkit.org/changeset/226766

[mnoorenberghe]

Noting WebKit implementation: https://trac.webkit.org/changeset/226766

Are you sure that's the correct link? I don't see address related changes in that commit

[marcoscaceres]

Oops, the link was for merchant validation. Thanks!

[marcoscaceres]

Noting this comment here: braintree/braintree-web#357 (comment)

[ianbjacobs]

This issue was raised in Payment Request, but closed once we removed addresses from that API. We anticipate adding addresses back to the specification and so are re-opening this issue proactively.