-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add billing shipping type #409
Conversation
There are cases (such as with digital goods), where an address is needed, but there is no notion of shipping. I would prefer to be more bold in this edit by changing the name of this enum to PaymentAddressType and changing requestShipping to requestAddress, but I wanted to be on the safe side to start. Please let me know if the renaming would be agreeable as well.
@@ -1210,7 +1210,8 @@ <h2 id="state-transitions" class="informative"> | |||
enum PaymentShippingType { | |||
"shipping", | |||
"delivery", | |||
"pickup" | |||
"pickup", | |||
"billing", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Invalid Web IDL (trailing commas)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will address that once I get some quick signal around the naming.
Billing address requirement depends on payment methods. So, bitcoin, for example, would not need it, but credit cards do need it. Therefore, I'd prefer that we keep billing address in method-specific data. I suggest that you send a patch to "Basic Card" spec, which has billing address in https://w3c.github.io/webpayments-methods-card/#basiccardresponse. I'm in support of something like this: new PaymentRequest([{
supportedMethods: ['basic-card'],
data: {requiredFields: ['billingAddress']}
}], shoppingCart); |
I disagree with your premise, the merchant will often need an address in order to compute the taxes owed. If I accept your premise, I don't understand how this would work. When would the browser surface an address selection? |
I believe we discussed billing address in issue 27: (which may not have concluded cleanly) Ian |
I would prefer that merchants estimate the tax and indicate that to the user by placing a If we must calculate the tax precisely during the PaymentRequest flow, user agent needs to provide billing address to the website before the user clicks "Pay" in browser UI. Is the country enough for tax purposes? A user agent generally should require a user action for this to happen in a privacy-preserving manner. Therefore, we need:
This is a fairly involved addition to the API. Therefore, I prefer the estimation workaround. How strong is the preference for this? |
On 27 Jan 2017, at 4:53 am, Rouslan Solomakhin ***@***.***> wrote:
Billing address requirement depends on payment methods. So, bitcoin, for example, would not need it, but credit cards do need it.
But only in some countries (Australia doesn't require a billing address to process a credit card payment online, afaik).
… Therefore, I'd prefer that we keep billing address in method-specific data. I suggest that you send a patch to "Basic Card" spec, which has billing address in https://w3c.github.io/webpayments-methods-card/#basiccardresponse. I'm in support of something like this:
new PaymentRequest([{
supportedMethods: ['basic-card'],
data: {requiredFields: ['billingAddress']}
}], shoppingCart);
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
In the US (for states with sales taxes that are destination-based), the tax applies to the shipping address not the billing address. That would apply even for digital goods; the tax is calculated based on where the customer "takes possession" of the product, not whatever their billing address is. This would seem to mean that a "shipping address" should be gathered for digital goods that need to be taxed, not a "billing address", at least for tax purposes. Taxes are fun. |
So, making this a shipping type as @rvm4 suggested probably makes sense, however, perhaps the name should be something like "tax" or "taxation" or "usage" rather than "billing" so as to avoid confusing it with a "billing address" which has to do with payment methods, as @rsolomakhin noted. |
The canonical example here is for digital goods. Shipping address doesn't quite fit because nothing is shipping. Why would you have to send a merchant the address prior to Pay being clicked? You could be given a list of items that does not include tax, but specify in the options that I need a billing/taxation address and when that event is received, append another item to the list that captures the applicable tax. |
I think this is actually one of our oldest issues, see #27. We didn't have a good solution to this for a while, but I agree that this is probably the right place to build this in. There are a few things to consider, though:
|
Could the editors discuss this at their next meeting and suggest something on this thread? Ian |
I think our suggestion is similar to what I mentioned above:
|
Do we need to hold up this PR for figuring out the label? The enum name is immaterial to what gets rendered in the browser, is it not? Let's hash this out in the F2F if need be. |
I don't think we can merge until we clarify what happens with shipping options when this is selected. |
Remarks from the 03/02 call:
|
We discussed on today's WPWG call: The group supports support for VAT info collection in v1 of the spec. We ask the Thanks! Ian |
Closing this to continue discussion in #27. We've agreed we would like this, but needs a bit more work to figure out interactions with shippingOptions, etc |
There are cases (such as with digital goods), where an address is needed, but there is no notion of shipping. I would prefer to be more bold in this edit by changing the name of this enum to PaymentAddressType and changing requestShipping to requestAddress, but I wanted to be on the safe side to start. Please let me know if the renaming would be agreeable as well.