Issue Summary - w3c/webpayments GitHub Wiki
WORK IN PROGRESS
Under each issue one or more proposals are listed and following each are the:
- arguments in favor of the proposal, followed by one or more:
- counter-arguments
Gathering shipping address data
QUESTION: Does this issue include the "events model" question? Or should that live outside this?
Proposal
The Web Payments browser API SHOULD NOT support the collection of shipping information through API calls
-
There is work being done elsewhere at W3C to develop a system for gathering this kind of information. The Credentials Management API could be used to get shipping address credentials from the browser and is a more appropriate API for this function.
-
@mikewest (editor of the Credentials Management API) has stated that the API is not currently the right place to do this as the API is narrowly scoped to handle login credentials. He suggests that any group wishing to extend the API for other purposes should write a concrete proposal and get input on this proposal.
-
@nickjharper
-
-
It is possible for websites to gather shipping address information without an API today so there is not a strong requirement for this feature.
-
There are other pieces of data that may be important to a payment request (billing address, loyalty program details, subscriber number, etc.) and the group should not presume it can define an API for gathering all of these so there is a case against designing the API for this special case.
-
The reasoning for this comes from the fact that user agents already hold this data and re-using for a better checkout user experience aligns precisely with one of the primary goals of this group: reducing the number of users that drop off from a checkout.
-
No other pieces of data can be gathered directly from the browser. This feature would not require a direct channel of communication between the payment app and the website (feature that may be impossible to provide in some deployment scenarios such as mobile).
-
The point at which shipping address is collected during online shopping may affect cart abandonment rates, for example, collecting it at the end of the process can cause sticker shock leading to abandoned carts. Codifying its collection into a high-level API that every site is expected to use could be at odds with improving certain aspects of online commerce or potentially detrimental.
-
Proposal 2
Getting the shipping address via this API will enable the user experience to be implemented by browsers in a way that will improve the checkout experience and is an appropriate use of the browsers ability to provide this data.
-
Physical good purchases are the majority of online transactions and part of that flow is the collection of shipping information.
-
Shipping information is special because, unlike loyalty cards, etc, it is impossible to fulfill the transaction without it. It is both ubiquitous and critical across all physical good transactions.
-
There may be an "80%" case where a high-level checkout API makes sense for collecting shipping address and other common information, like shipping option, but that high-level API should be composed of smaller low-level APIs that sites could compose together and call at times that work best for them. If the group is not yet ready to create every composable low-level API, it should focus on those that it is ready to work on and design the high-level API with composability in mind.
-
Websites often need to collect a variety of different pieces of information in order to aid people in their online shopping experience. This may include collecting shipping address information, loyalty cards, coupons, etc. Sometimes websites will want to collect this information at different times. This speaks to a need to have a low-level API for requesting information outside of a checkout flow. However, if they do want to collect that information during a checkout flow, it would be ideal if the user agent could simplify the UI experience for the user so they aren't taken through multiple screens if unnecessary.
-
There seem to be two low-level primitives involved here: obtaining customer information and requesting payment. We could define each of these as low-level APIs and then create a high-level checkout API that can be started to unify the UI when a website wants to ask for information and then request payment all at once.
Stateful vs stateless API
ISSUE 2:
- Title: Expression of Monetary Amounts
- Issues Number: 40
- Consensus Reached: No
Difference 4:
- Title: Payment Details
- Issues Number: 38
- Consensus Reached: No
Difference 5:
- Title: Accepted Payment Methods format
- Issues Number: 37
- Consensus Reached: No
Difference 6:
- Title: Payment Request is Object or Data
- Issues Number: 36
- Consensus Reached: No
Difference 7:
- Title: Payment Request Status
- Issues Number: 35
- Consensus Reached: No
Difference 8:
- Title: HTTP API
- Issues Number: 97 17
- Consensus Reached: Yes, it has been agreed we need an HTTP API< but it is consider lowed priority
Separation of enrollment from payment
Ian scenario: Service asks user at enrollment to register payment details for future use. API is used to retrieve those details, but no payment should actually take place."
AdrianBa: There may be many occasions where a site wants to request a payment method but not to make a charge. For example, it is common to provide a credit card number to book a car rental or to make a hotel reservation but the payment is made later, in person, and potentially with a different payment method. The merchant may charge the original payment method under some circumstances (for example no show at the hotel).
###Proposal 1 (Zach, AdrianBa)
- Use amount = 0
###Proposal 2 (Rouslan)
-
is_billing_agreement: true
For periodic billing: the amount should be the estimated periodic charge amount. For future charge: the amount should be the estimated future charge.
What is the role of the payment app and how will the browser communicate with them?
- And what is role of HTTP API in remote payment apps?