Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316)

@rsolomakhin : Thanks for the feedback and suggestion.
 
There are two main problems I see with the approach; one of which is almost certainly bigger than the other.
 
- The approach of having our Merchants add a new JavaScript include into their pages, and a div into the button element makes sense; however the reality is that it's very hard to get existing integrations changed. Unless the Web Payments standard really takes off and becomes ubiquitous, Merchants aren't going to be inclined to take something that works great for them today and change it; thus you have something of a chicken and egg problem; you need Merchants to change their integration so it gains market traction, but they won't do the work until it has the market traction :-) Remember that in many cases we're talking about Merchants who may have very limited technical skills, so changing their integration may mean finding someone to make the changes for them...
Having an integration path that can be done 'behind the scenes' by the PSP makes a lot more sense in this context; Merchant integrations stay unchanged, but they get 'automagically' enabled to allow their shoppers to make use of the Web Payments functionality.
 
- The second issue is around the payment method mask; out of your three options the only really viable one is a hybrid of 1 and 3 (.. I think). We're talking about tens of thousands of Merchants, so a custom file per Merchant isn't viable unless auto-generated, the valid set of combinations for payment methods will only grow over time and so become unmanageable, and having a Merchant embed a path with a list of payment methods (3) means that any time they change their configuration they have to go back and change it within their website.
I suspect you'd have to have something similar to your 3, but where the Merchant passes in a unique API key and the server then generates a custom JS file based on their current configuration around accepted payment methods. Obviously the issue with doing this is that it introduces another round-trip between browser and PSP which will introduce additional latency around how long it takes to bootstrap the Web Payments functionality, which may be less than ideal.
 
To answer the earlier comment from @rsolomakhin : I don't have any exact stats on how likely it is to happen, but if you consider how many customers (Merchants) a major PSP has today and combine that with future growth then it's going to happen; even if only as an edge-case. If the goal is to build something that Merchant's want to use and adopt, then I'd suggest that designing in limitations such as we're discussing here can only be a detriment to that. Especially since, as @burdges pointed out, finger printing may still be relatively trivially possible even with rate limiting imposed.
 

-- 
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/browser-payment-api/pull/316#issuecomment-265208713