Comments (13)
The payment request can specify a guide price and the payment app can request updated pricing from the payee based on user input (coupon, currency selection, loyalty program login etc).
A user (or their payment app) may want to make choices based on the available pricing options. This would be a frustrating experience if the user first had to make some choices to see those pricing options -- and then back out and try others. It would also be an inefficient (or infeasible) process for a payment app that is automating the process.
from webpayments.
A user (or their payment app) may want to make choices based on the available pricing options. This would be a frustrating experience if the user first had to make some choices to see those pricing options -- and then back out and try others. It would also be an inefficient (or infeasible) process for a payment app that is automating the process.
What are the other options? If we are going to support the concept of pricing options at all I only see 3 ways for this to work:
- Payment requests contain computational logic (can be scripted) and can adjust the pricing based on user input within the app
- Payment requests must contain every possible pricing option pre-calculated by the payee
- Payment apps are able to request an updated payment request when users make choices that may change the price they pay
It's possible that we have combination of 2 and 3 which would be my preference. Provide a good set of options that assist users in making their initial choices but still have the flexibility to fetch an updated set of prices if required.
from webpayments.
It's possible that we have combination of 2 and 3 which would be my preference. Provide a good set of options that assist users in making their initial choices but still have the flexibility to fetch an updated set of prices if required.
This sounds fine (and preferable) to me. Ideally, most of the information will be available via 2, but we could allow for cases when 3 is necessary.
from webpayments.
I'm for 2.
The payment app tells the payee's website which payment methods are supported... it is on the payee to add additional items (e.g. "fees") to the payment request's detail for the specific payment method.
from webpayments.
@alexdown said:
The payment app tells the payee's website which payment methods are supported
That's a violation of the customer's privacy. The current design is for the payee site to say which payment methods it accepts and for the payer's software to expose the available methods to the payer for selection.
Welcome to the group, @alexdown :)
from webpayments.
I think it's a good idea to have pricing options for loyalty cards, for example. I don't think it's necessary for version 1 of the API, in the interest of building the most common and simple API for now. Perhaps in version 2 would be better.
That being said, I would prefer option 3 ("Payment apps are able to request an updated payment request when users make choices that may change the price they pay"), because I want to avoid computational logic and exhaustive pre-calculation. Also, option 3 fits the "paymentRequest.setAddressChangeListener()" paradigm nicely. I'm thinking about perhaps "paymentRequest.setPaymentInstrumentTypeListener()", for example.
from webpayments.
Here are a handful of use cases from our base use case document that I feel are related to this feature:
6.1.3 (application or marketing elements) supports this directly in that it talks about loyalty cards and coupons. However, at least in the latest draft these are not in any Roadmap "phase".
6.2.1 (discovery of accepted schemes) talks to having multiple accepted payment schemes. If that's the case, it should be possible for different schemes to have different payment amounts (e.g., if you pay with Visa it is this much, in Bitcoin it is this much).
6.2.2 (selection of payment instruments) also goes to this case. The user (or their automated agent) needs a way to intelligently decide which payment instrument or combination of instruments will be used.
from webpayments.
We've discussed the idea of having the user agent indicate to the web page what payment method has been selected as a way of accomplishing what @alexdown suggests. This still has privacy implications, which is one reason we haven't made a more formal proposal yet. This topic also is something we can add support for later. It's not clear that merchants necessarily want to advertise all the different pricing options they might want to offer right up front.
from webpayments.
Another consideration is the user experience for picking a payment app.
Is price an important factor in making the decision? If the payee is prepared to accept different amounts depending on the payment method should the user be able to see that when making their choice of payment app. i.e. Should each payment app choice also show the price the user will pay if they select that app?
If not, there is no incentive for merchants to price different payment methods differently which begs the question of what incentive a merchant has for using the API over a payment flow they have more control over that allows them more influence on the payment method.
from webpayments.
On Thu, Feb 11, 2016 at 7:06 AM, Adrian Hope-Bailie <
[email protected]> wrote:
Another consideration is the user experience for picking a payment app.
Is price an important factor in making the decision? If the payee is
prepared to accept different amounts depending on the payment method should
the user be able to see that when making their choice of payment app. i.e.
Should each payment app choice also show the price the user will pay if
they select that app?
Well - I think at least we should not prevent a merchant from doing this.
Consider the case where a merchant has a private branded payment method
(e.g., Amaco used to have their own credit card) and if the consumer uses
that method, it is less expensive / error prone for the merchant. The
merchant should be able to pass some of that savings onto the consumer as
an incentive. Target Stores do this today with their self-branded debit
card, for example.
-Shane
from webpayments.
Should each payment app choice also show the price the user will pay if they select that app?
JFYI - the web-payments.io demo has been updated to show a price on the payment app selection screen now.
from webpayments.
Migrated to w3c/payment-request#54.
@adrianhopebailie, please close the issue if you feel that w3c/payment-request#54 is the right home for this issue.
from webpayments.
I am closing this but think the history here is important for anyone picking up the issue on the other thread.
We also discussed this at the F2F and I don't believe came to consensus so this is still an important point of discussion.
from webpayments.
Related Issues (20)
- [Payment apps] How can we optimize user experience when there is only one match? HOT 1
- Pull filters out of payment method data HOT 2
- Overview document figure 5 HOT 13
- Propose a payment method specification that includes an example of field level security HOT 1
- propose to add encoding attribute to data set HOT 18
- European market - Security concerns HOT 10
- [Tokenized Card Payment] Replace usage of 'last4' with 'suffix' HOT 8
- [Tokenized Card Payment] TokenCardRequest should inherit from BasicCardRequest HOT 3
- 3D secure support HOT 4
- Sepamail WebIDL syntax and algorithms HOT 4
- Payment Method Manifest spec - should enable country specific app discovery HOT 9
- Fingerprint and version metadata (in Web App Manifest spec) HOT 36
- Should the WPWG develop a cryptocurrency payment method specification HOT 14
- Adopt a "test as you commit" policy HOT 10
- Just a question, curious HOT 1
- Visual Identity for Web Payments HOT 14
- Specify both pickup and delivery addresses in a single payment request HOT 2
- QR use cases HOT 5
- Proposal to restore charter text around UI being out of scope HOT 10
- Pagos alex
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from webpayments.