Re: [w3c/browser-payment-api] Use first matching PaymentDetailsModifier (#541)

> So I think this addresses the problem, but not in the ideal way. It should be part of the show() algorithm, IMO.

Agree - this is incomplete. I thought here was good as a starting point, as `updateWith()` also relies on this - not just `.show()`. 

What I'm thinking is that this section would define the "use the first matching one!" rule because: 
 
 1. This data needs to go to another UI process.
 2. The end-user may consult different payment methods.
 3. User could asynchronously add a payment handler, which may then be activated in the UI (e.g., this is the first time they use Web Payments - so they get onboarded).

For point 2 above, the use case/user story is:

"I'm going to try to pay with my Amex, because double points, oh yeah! 
- user picks basic card in UI.

"Oh, crap! If I do that, I get charged 5% more. So, screw that! I'm going to switch to 'bobpay.com', as I don't have to pay any fee (and, wow! I get a free mug!)." 
- User switches to "bobpay.com" as payment handler.

"Oh, wait, that's only if I use my bobpay debit card. M'eh. that's fine."
- user selects "debit card", clicks "Pay". 

> Also, currently we only store the modifiers as serialized strings in the [[serializedModifierData]] slot. It's a bug in the current spec that nobody every references that slot. We should probably reference it! 

Yes, probably here. 

> But now I'm confused as to why it needs to be JSON-serialized at all. Will it be sent across processes? 

Yes. Consider what I described above, where I might "shop around" for the best deal based on payment method:

![screenshot 2017-06-05 19 05 44](https://cloud.githubusercontent.com/assets/870154/26777852/236967ac-4a22-11e7-9072-4c14a5f068db.png)

I might jump back in forth between "basic-card" and "PayPal" above to see who gives me the better rates - this could include currency rates, free stuff, discounts, etc... all encoded in [[serializedModifierData]]. 

> Is each payment app going to process it differently? If so we should make that explicit, like we kind of do for [[serializedModifierData]].
 
Yeah. Hence why I think #536 is so important. Also, we can't filter things out of [[serializedModifierData]] because of point 3 above (payment method becomes available to the user _after_ payment request). 


-- 
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/541#issuecomment-306142450