Re: [w3c/payment-request] Define handling of multiple applicable modifiers (#684)

>  It seems like #581 then didn't end up addressing the issue.

I think you are right... seems we talked ourselves out of a proper solution in #581 or somehow the solution got lost. 

> I think we should be consistent on first vs. last in tie breaker scenarios.

Agree. From my testing Chrome's behaviour seems to be "**only the last matching PMI declaration wins**  - all previous ones are ignored". @rsolomakhin, @zkoch - please confirm... as this might confuse developers, leading potentially to incorrect totals 💸!  

To be somewhat sane, we might need an algorithm that, in order, filter `supportedMethods` on PMI, then filter `supportedTypes`, and finally filter on `supportedNetworks` (need to code it up to verify).  

Developers then need to go specify things from least specific "All the [debit, credit, prepay] cards incur a $3 fee!" to least specific, "Visa credit cards $2 fee". 

< 📣 rant 📣 >
I'll admit, this makes me queasy 🤢. 

The right way to deal with this would have been to have a payment option change event, that includes just `"{type: 'credit', network: 'visa'}` (i.e., we don't leak private info or credit card numbers!). Then the developer can add additional display items, update the total via`.updateWith()`... like we do with shipping change events. 

Why don't we just do that instead? Better than dealing with insane combinations of modifiers and vastly simplifies the spec for both implementers, developers, and reduces the risk of screwups for everyone.  
</📣 rant 📣> 


-- 
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/payment-request/issues/684#issuecomment-365511426