- From: Marcos Cáceres <notifications@github.com>
- Date: Mon, 04 Mar 2019 20:50:34 -0800
- To: w3c/payment-request <payment-request@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/payment-request/issues/842/469536532@github.com>
@samuelweiler, @npdoty, what I've done thus far is heavily redact the billing address information sufficiently so it works with fraud detection systems, and allow for tax calculations. Tax calculations, performed when the payment instrument changes: https://github.com/w3c/payment-method-basic-card/pull/67 Fraud prevention: https://github.com/w3c/payment-request/pull/846 I share the concerns about `requestBillingAddress`, but instead of an enum, as @adrianhopebailie suggests, how about we use either a boolean or an array. So: * `requestBillingAddress` is `false` (this is default): Merchant gets nothing. * `requestBillingAddress` is `true`: Merchant gets redacted `billingAddress` sufficient for fraud prevention and tax calculation. * `requestBillingAddress` is Array of members that the merchant needs (and redacted list still applies). So, `"requestBillingAddress": ["recipient", "postcode"]` would ignore "recipient" because it's on the redact list, and thus only gives the merchant back the post code. Gives merchant more control if they need to do tax calculations and/or fraud prevention checks. As this is a significant change to the API, I don't think we should do this in V1. We should do this in v1.1 tho. Using the array should be backwards compatible with the 1.0, in as far as an array will be treated as `true` by the 1.0 API. -- 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/842#issuecomment-469536532
Received on Tuesday, 5 March 2019 04:50:56 UTC