Hacker News Reader

Comment by hiatus | Hacker News Reader

Sparkfun put out an app to help detect skimmers primarily on gas pumps [1], though it no longer appears to be available on the google play store.

[1]: https://github.com/sparkfunX/Skimmer_Scanner

View on HN

It annoys me that none of the gas stations I use have the "tap to pay" that actually works.

They seem to have the sensor on the pumps, but they never work.

I wonder why. I had the same problem and assumed they'd just bought some premature technology and never upgraded since.

My preferred gas station got tap to pay during the pandemic and I make it a clear effort to use it every time I get gas to try to bump the numbers up so it doesn't go away or gets fixed if it breaks. Such a great feature.

Preferred gas station here did something to the UI--you can "pay" by waving your phone at it, but then it will prompt for your zip code. When you enter the zip code there's a couple of prompts about ensuring you know you're paying credit price--oops, entering the zip code also answers no to the first question.

That's real dumb and totally defeats the point. That sucks.

I'm sure it's a bug--they're not adequately debouncing the key and it's being taken as an answer to the next question. I've told them but I doubt the people in the store have an adequate way of pushing a bug report like that up the chain.

My pet theory is that transitioning to wireless payment also opens up user expectations for the vendor to participate in way more payment networks than just Visa/MC/Discover/AmEx. If you have a wireless reader but no agreement with Apple Pay, or Google Pay, or Samsung Pay, or WePay, or WhateverSomeNewMBACrap users will start putting in reports that the reader is “broken”.

You don't have to have an agreement with Apple or Google to accept Apple Pay or Google Pay. If the customer holds a Visa then the phone presents a Visa to the reader. There is no special thing you have to do to accept those payments.

Unfortunately that's not how it works. There is a protocol at the payment processor for Apple Pay (at least) that has to be followed so that the device card number (not the card number on your card and not a "virtual card") is tied to the correct account. It's a whole thing. Most POS systems ship with support for it at this point. And you have to sign some sort of agreement so that you are compliant.

https://www.forbes.com/advisor/business/how-accept-apple-pay...

I think that's just EMV tokenization, not something exclusive to Apple Pay.

[first bit removed because I was wrong]

I imagine it is possible to do something wrong at the processor to make this not work, due to the device card number shenanigans you mention. But, are there really still processors who still do it wrong? The device card number is associated at the issuing bank, not at the processor (unless I am missing something).

This is true in theory, but I can think of one grocery store (rural, admittedly) where Apple Pay doesn't work, but tap does.

I’ll absolutely admit knowing very little about the nuances of payment networks in the US, particularly with contactless —- but my experience (in Australia) is that payment terminals that support contactless inherently support Apple/Google/etc Pay, even if the payment terminal is unaware of those things, in which case the transaction will work the same as a contactless card transaction (e.g. transactions >$100 require PIN).

Reply on news.ycombinator.com