- From: Marcos Cáceres <notifications@github.com>
- Date: Tue, 01 May 2018 20:06:22 -0700
- To: w3c/payment-request <payment-request@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/payment-request/issues/647/385852164@github.com>
Seeking input: * @domenic, feedback on IDL and general design would be appreciated. * @aestes, are there cases that are not covered (i.e., that you couldn't then map to `ApplePayError`)? * @mnoorenberghe, @edenchuang, implementable? ## Shipping address errors Looking back over the discussion, I think having a `PaymentError` interface might be confusing and a bit heavyweight: Confusing, in that it's not an `Error` in the JS/DOM sense (has no stack, for example). Heavyweight, in that it simply models a triple, but provides no other utilities. As an alternative, I think we can just use dictionaries to achieve the same result: ```JS dictionary AddressErrors { DOMString addressLine; DOMString city; DOMString country; DOMString dependentLocality; DOMString languageCode; DOMString organization; DOMString phone; DOMString postalCode; DOMString recipient; DOMString region; DOMString regionCode; DOMString sortingCode; }; partial dictionary PaymentDetailsUpdate { AddressErrors shippingAddressErrors; } ``` Note: `AddressErrors` could be reused for billing address errors, once the Payment Request API actually supports billing addresses properly (https://github.com/w3c/payment-request/issues/27 and https://github.com/w3c/payment-request/issues/550). Note: Errors for redacted fields could be ignored by the UA (e.g., complaining about shipping address' `phone` during the "payment request" phase would be ignored, but would be honored when retrying the payment response). ### Usage example ```JS pr.onshippingaddresschange = ev => { const shippingAddressErrors = { "city": "FarmVille is not a real place.", "postalCode": "Doesn't match a known zip code for your country.", }; event.updateWith({ shippingAddressErrors }); } ``` ## Payer-related errors The next class of errors deals specifically with payer related errors (name, email, phone): ```JS dictionary PayerErrors { DOMString email; DOMString name; DOMString phone; } partial dictionary PaymentDetailsUpdate { PayerErrors payerErrors; } ``` ### Example ```JS const payerErrors = { email: "The domain name is invalid", phone: "Invalid format", }; // We don't have a means to use this object yet... that will be `retry()`. ``` Thoughts, before I spec it up? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/payment-request/issues/647#issuecomment-385852164
Received on Wednesday, 2 May 2018 03:06:47 UTC