So I don't believe there's a 'detection of the EMV chip', I think when the BIN/PAN is sent as part of the transaction the response comes back from the payment processor that this is a Chip enabled card that should be run via EMV. But I'm thinking it could be something with the Tokenization. Since what it's presenting is not the actual card number, but a tokenized one for which there's already a back end association to the issuing banks (by virtue of not all banks participating in Samsung Pay) that these tokenized cards will not send the flag to use EMV and thus rely on the added security of the fingerprint.
All decisioning happens locally at the device vs the payment processor. There should be a flag within the mag-stripe data that says 'Hey Mr. Card Reader, I have a chip so please instruct the consumer to insert me (or tap if the card/phone is capable of passing EMV data via NFC). When you move to Samsung Pay the mag-stripe data could easily just say 'Hey, I'm just a mag-stripe card or someting of that nature.' Then in those instances the liability would still be on the issuing bank.
Sometimes they could remove the flag due to a tokenized card or they may just not care based on added security of phone finger printing. It will all change on issuing bank,, merchant and risk thresholds, but Samsung does have something cool where it can emulate the mag-stripe by passing some audio frequency data to mimic and mag-stripe.
When ApplePay came out, Apple actually pushed for dynamic card data for each transaction, but the industry isn't ready to support it as it will require a new data field for these machines to pass a field that says 'I'm tokenized/dynamic data from the card and not the card itself.'
Payment processing is a crazy, outdated industry ripe for innovation, but when everyone expects to be able to go to any register swipe their card and just have it work.
