Intent to Implement and Ship: BasicCardResponse.expiry{Month,Year} should be 2 digits

[Rouslan Solomakhin]

Contact emails rou...@chromium.org, se...@chromium.org, zk...@chromium.org Spec https://w3c.github.io/webpayments-methods-card/#basiccardresponse Summary This is a change in the format of expiaryMonth and expiryYear fields returned to the merchant website in response for a "basic-card" payment request.

The expiryMonth field should contain a two-digit string for the expiry month of the card in the range 01 to 12, instead of the currently implemented range of 1 to 12. The expiryYear field should contain a two-digit string for the expiry year of the card in the range 00 to 99, instead of the currently implemented range of 0 to 9999. Interoperability risk Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: No signals Compatibility risk Existing content will break if developers were not careful about parsing the expiaryMonth and expiryYear formats. We will reach out to partners directly and to the developer community through document and blog to let them know about the change in format. Ongoing technical constraints None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes or no. No. This request to implement and ship is for Android only. Other platforms are being developed. There're no plans to implement on WebView, however. OWP launch tracking bug http://crbug.com/673353 Link to entry on the Chrome Platform Status https://www.chromestatus.com/feature/5671972004429824 Requesting approval to ship? Yes

[Rick Byers]

Hey Rouslan,

Are you able to quantify the compat risk a little?  Eg. do we have usage metrics for PaymentRequest that would put an upper-bound on the risk of broken sites here?  Do you have any anecdotal data on how often sites depend on the existing format?  Intuitively I'd expect the risk of breakage to be pretty low (as a combination of those two things being relatively rare) but in general we try to quantify the risk somehow when making breaking (eg. proving to web developers that we haven't been careless in making a change that ended up costing them real revenue).

thanks,

   Rick

[Zach Koch]

Good news on this. After chatting with MSFT, sounds like they're also returning back 4-digit years, just like us. As such, we agreed to update the spec. I submitted a merged a PR this afternoon, so we should be good on this front now. No more risk here.