Another mystery unsolved. Will we ever get the answer? 
Yes, there are. In fact I know one restaurant that will accept Girocard but will not accept any other card. I tried to cheat my way in by holding a Maestro card against the Terminal but the card was declined. Back then I also had a Girocard as well and that worked without any issue. The reason is that there are still some old contracts with the Terminal provider, usually a local Bank with outdated prices from back in the days when credit card transactions where much more expensive.
Sometimes Merchants will say they accept Girocard only (or EC, the old name for it) but when you use your Maestro it will work as well.
Also as you mentioned Sum-Up does not support Girocard, but most cards will work anyway because of the Co-badge with Maestro.
1 „Gefällt mir“
When it happened to me - I showed the merchant the physical debit card and the exact same image on the phone, and said they were the same thing. He was not having any of it, and insisted that I pay with the card. At that point, there was no point in getting into any kind of discussion with the merchant. This was some 4 years ago, long before NFC and Apple Pay were a known thing.
On Amrum in 2017, I surprised a merchant by paying with NFC (card), and he was very suspicious of me. We chatted for a moment about the technology (in my terrible German). I said next time, I’ll pay with a phone. The second day, I paid with Google Pay, and he was even more suspicious. Although his machine (Verifone H5000) took the transaction, and he examined the receipt very carefully before I left the store.
A former colleague tells a great story about my attempts to use Google Pay back in ~2012 in the US. I’d specially got a US SIM card to enable the wallet, and successfully installed the wallet. It worked in a few places. We were in the basement of a mall in Chicago, and I could not get a 3G signal on my phone, and so the wallet would not work. I tried the mall wi-fi with no luck, and then also to piggy back of a second phone’s 3G connection. All failed - to the entertainment of the cashier in the mall. I ended up paying NFC with a physical card. (Yes, I’m super fun then it comes to paying with technology).
VR Payment still markets Girocard only contracts, Sparkassen-Händlerservice doesn’t actively advertise them any more, as far as I know.
From my point of view, Sum-Up is actually doing false advertisement (not legally but rather morally). On their website you can see the „Electronic Cash“ or „EC“-Symbol - the old name for the Girocard. So it suggests that it is being accepted as well.
The rights from the „EC“-Symbol is actually owned by Mastercard now so some card issuers print it on their cards together with the Mastercard-Symbol. So people think that it is a real „EC“-card or Girocard and those cards will work with SumUp of course. But the real Girocards will fail.
1 „Gefällt mir“
Acceptance issues - on a technical basis - can happen, and merchants don’t really know what to do, or how to handle it.
Whenever I would hear of acceptance issues, one question to the merchant was „what colour was the card“, to see if we could identify the bank, and get one to see/test.
A former customer of mine, who had many retail locations, would send an email around the head office whenever a new debit card was launched, to see if someone had one to test acceptance. Any reports from the field "… with a card from Bank X … " would result in an internal email asking for someone to come forward with one of those cards. At the same time, I’d get an email to know if there was „something wrong with a card from Bank X“.
Most of the time merchants are overly cautious when it comes to cards that don’t work - and would prefer to say „hey, don’t use that - it never works - can you pay with something else“ rather than the minutes lost while a card fails to process correctly. It’s a less unpleasant experience.
(Final story) In an electrical retailer a few years back, I was going to pay with a credit card from Bank Z. The cashier said something along the lines of „good thing you’re using the credit card, as the debit card does not work“. I swapped the cards, and used a Bank Z debit card, and as expected the transaction was declined. There was a configuration error on the POS device, and Bank Z declined the transaction on a technical basis (OK, so I knew this, but the cashier did not).
I called over the duty manager, and said „call your IT help desk, and say the following… [technical notes on the configuration error]“. I believe it was resolved.
Same store about two years later, and I note they have new PIN pads. I make some comment to the cashier about the new PIN pads, and the response was „… those bl**dy things… Bank Z cards never work“… I go „really?“. I pay with my Bank Z card, and yes another technical decline (same as before).
I called over the duty manager, and repeat my statement from two years previously. „call your IT help desk, and say the following… [technical notes on the configuration error]“. Again it was resolved.
Acceptance issues are most of the time technical (configuration or similar and one of my specialties) or they are business decisions made by the merchant (Girocard only with ELV).
Enough war stores for one day from some old guy…
1 „Gefällt mir“
There still might be a difference between Apple Pay and Goggle Pay. I found this article from 2014 — it’s been six years, time is flying by…
So, Google wallet used to present a virtual card number via host card emulation while Apple came up with a unique token for each transaction. Even the POS terminal would not see a card number (neither a virtual one nor the physical card number) but just pass the token through to the server. That time, it was deemed much more secure. I remember, terminals in the US were plagued by manipulated firmware that skimmed the card numbers and Apple Pay seemed to be a good mitigation.
Host card emulation means that the cryptographic tokens that replace the card number during the payment process aren’t generated on device. Apple does this on device, Android phones, Gpay and systems like the Sparkasse App use a cloud service to generate tokens and store a limited number on device. But all of them use unique one time tokens for payments.
(This is the reason why Apple Pay doesn’t need an internet connection to generate new tokens. Android stores a couple of tokens on device but once they are used, payments aren’t possible any longer until the device is able to connect to the host again.)
You might refer to a different problem with a different technology. Before chip based contactless was widely adopted, contactless cards used a different data standard. In simple terms, the card would send the same information the magstripe contained. This is often called Magstripe Mode (vs. EMV Mode).
Both Google and Apple Pay technically support this older standard as fallback, but Apple is a little more restrictive about it and has stricter terms about its availability in specific regions. More about this also here: Golem.de: IT-News für Profis
Fun fact: the history about Magstripe Mode and EMV Mode for contactless payments also explains why merchants in the US specifically advertise that they accept Apple Pay. Here in Europe, when merchants accept contactless Visa cards, they also (technically) can accept Visa cards via Apple Pay – its the same technology and data standard. But in the US, contactless mostly meant acceptance of cards using magstripe mode. A side effect of the slow adoption of EMV (chip and PIN) cards and terminals.
1 „Gefällt mir“
Thank you, very interesting! Now, how about tapping a physical card: does it send its card number or a one-time token to the POS terminal? Considering a hacked terminal, the former would be less secure than paying by phone.
I don’t want to nag you too much and I don’t need to become a payment expert, but you probably know of Transport for London’s Pay as You Go. You tap your card or phone and you’re charged a single fare. If you travel multiple times a day your total fare is capped to a day pass. How do they figure out it’s you? You know, if your phone gives out unique tokens there must be some other kind of ID.
When you set up Apple Pay on a new device, a device account number is generated. This number is similar to a card number. The DAN is linked to your card number, but it is useless on its own. This number identifies the account holder only. And the token authorizes the payment. DANs on their own can’t be fraudulently used for card not present transactions.
TfL uses DANs to identify unique devices. That’s why it is important to always use the same device for tapping in and out, even if your phone and watch might be linked to the same card account.
2 „Gefällt mir“
I was a little bit confused but after some additional reading I think I understand it now. So the merchant sees a „Credit Card number“. But in the case of Apple Pay this is the device account number and it is basically useless without all the other dynamic information which is part of the token send during a payment process
A couple of quick „tidy up“ notes around mobile wallets, @Frnk is mostly correct.
To process correctly at a device, the customer presents something that is recognised as a payment instrument. These days there are two parts - first an AID as mentioned above and secondly a „Primary Account Number“. This second item has traditionally been the number embossed on the front of the card and how customers know their „account“.
There’s a process called Tokenisation, which comes in a few forms, and with various terminologies. The ApplePay document from 2014 linked above refers to a Device Account Number, and elsewhere there are terms like Dynamic Account Number. Almost universally these days, the technical teams I interact with refer to this data element as a Token.
You can have tokens that are allocated to a specific device like Wallets or fitness bands/watches. You can also have tokens that are allocated to a specific merchant (like Amazon), also called „card on file tokens“. Tokens have distinct restrictions as to how or where they can be used. If you tried to present your Amazon token at Netflix, it would not work. The same goes for the Google Pay token, if you try and use it with PayPal.
Tokens look just like Account Numbers - my Google Pay Token is 460738XXXXXXXX42 while my Tomorrow Account is 434975XXXXXXXXX7. The Token is formatted like a real Visa card number as it needs to process through the payment networks normally. The „42“ token is allocated to my device (and my device only). If I change phone and re-install the Wallet elsewhere, I will be allocated a new token by Google/Solaris/Tomorrow. The Token is translated to the original cardholder account number before it gets to the issuer, so it can easily be applied to your account.
@Frnk mentions Host Card Emulation. This is where some data is delivered „just in time“ from the Wallet Provider for it’s use in a transaction. Typically a few batches of data are cached on the phone so transactions can be performed without a 3G/LTE/Wi-Fi data connection. This process is mostly seamless to cardholders.
The data delivered allows for both the mag-stripe and EMV mode NFC transactions - although mag-stripe mode is discouraged in Europe. The Token remains the same regardless of how the transaction is processed. In the data package there are cryptographic keys which are used to sign the transaction data (date, amount etc…). This signature is called a cryptogram, and a standard part of EMV processing (Wallet, Chip or Contactless). The cryptogram is very secure. Mag-stripe mode NFC uses a smaller data set in it’s cryptographic processes. The signing process is performed on the phone, with a session key delivered for that transaction.
@Piux asks about data transmission between the Wallet and the POS device. In the clear! ISO14443 for the radio transmission and ISO7816 for the command structure, and EMVCo for the individual data elements. Visa/Mastercard for a layer on top of that again.
Here is an example of the main exchange between a test device and a Google Wallet. The ‚|‘ and „.“ are the split up the data to make it a bit more readable. I’ve also removed a couple of protocol characters for readability. Note the mix of ASCII and BCD.
The „0000000000001“ is €0,01, the 276 is Germany, 978 Euro, 201207 today’s date, and so on.
To Wallet/Card >> ‚80A8000071|836F|77800000|000000000001|000000000000|0276|0000008000|0978|201207|00|00000000|000000000000|0002|0000|000000000000000000000000000000|0000000000000000|3132333435363738|E0E8C8|22|00|0000000000000000000000000000000000000000000000000000000000000000|00‘
From Wallet/Card>>‚7766|9F26.08.4B052E4344AD8B3F|82.02.2040|94.04.10020400|5F34.01.00|9F36.02.0002|9F6C.02.0080|9F6E.04.238C0000|9F10.20.1F43FF5120000000000000000000814900000000000000000000000000000000|57.13.460738XXXXXXXX42D23122210000000000000F|9F27.01.80|9000‘
This is the digital signature 4B052E4344AD8B3F which is connected to this transaction. If I push the same data in a second time, the new cryptogram value is AC499B72CF697868.
Capturing NFC data „in the wild“ is annoying to complete reliably. Capturing chip data is much easier, and that is why all the POS devices have tamper evident seals, and a whole range of tamper mechanisms. Smartspy+ | Fime
2 „Gefällt mir“
Cheers, I’m getting the picture. Out of curiosity, if I order online and the store front offers to store my card number, would it be always tokenized and for this merchant only (as in your example with Amazon)? I’m always reluctant to do so and rather hack it in each time I’m ordering. I guess tokenization is not mandatory and stores can store card numbers even as plain text if they’re fancy.
With e-commerce, there’s no tokenisation happening besides systems like Apple Pay. Whenever you enter a card number online, you‘re risking that your card is being compromised in cases of data breach.
@Frnk … not quite 
@Piux have a look at the Adyen API https://docs.adyen.com/checkout/prebuilt-ui where any e-commerce merchant can easily integrate. In this case, the card number is stored on an Adyen server with customer information, and the merchant only references the customer with a UID. Not quite tokenisation as I describe above - more a reference that the merchant uses - and so the merchant is out of scope of PCI. (And that was the goal with this).
A merchant like Amazon can use a token - and they can request a Token from Visa Visa Token Service The Token is unique to the merchant and can only be used by them. Behind the scenes, Visa validates the Token, it’s usage and then translates back to your card number for your bank/issuer. If the token shows up as a physical card, the transaction will be declined. The Token is useless outside of the merchant it was given to. This is also supported by the other card schemes. Mastercard Developers
If you want to store real card number on your server, then you come under the requirements of PCI (https://www.pcisecuritystandards.org/) and all the heavy lifting that is required there. There is lots, hence the Adyen approach or the merchant Tokenisation system is easier.
1 „Gefällt mir“
@aidanic, thanks for the additional insight.
Recent cases like British Airways, Marriot Hotels, Adobe, and Mastercard’s own loyalty programme are examples for major data breaches where card numbers were leaked. I was a victim of card not present fraud myself, based on a credit card number leaked in one of these incidents.
1 „Gefällt mir“
leider fehlgeschlagen, magnetstreifen wurde angefordert. zahlung dennoch erfolglos war der erste einsatz der karte, habe nun einmal im netto mit pin bezahlt (visa debit) und hoffe dsss v pay das nächste mal bei der Post geht…
Ich habe so eine Anzeige woanders auch schon bei der Holzkarte gesehen (an einem anderen Typ vom Terminal). Hat das so seine Richtigkeit oder ist das ein Fehler der Karte und die müssten eigentlich getauscht/gefixed werden?
Müsste nicht oben Visa Debit und unten V Pay stehen?
@aidanic hat andernorts erläutert, dass die Konfiguration dieser Anzeige alleine durch die Konfiguration der Terminalsoftware erfolgt. Über die Karte kann man das nicht beeinflussen.
The text you see on the screen comes off the card (EMV Tag 50) when used in contact chip mode. It is displayed in the order of preference of the Issuer (EMVCo Book 1, Chapter 12.4 Step 4) EMV tag 87.
In the picture, Visa Debit (A0000000031010) is first as it has priority 1, and V PAY is second (A0000000032020) with priority 2, although the ASCII data is „Visa Debit“.
Raw Data
18:39:37.335 <<S-5 [0x5] >>‚00B2010C29‘
18:39:37.393 >>R-43 [0x2B]>>‚702761254F07A0000000031010500A56697361204465626974870101730B9F0A0800010501000000009000‘
18:39:37.393 Found application ID ‚A0000000031010‘
18:39:37.393 Found application label ‚Visa Debit‘
18:39:37.393 Found application priority ‚1‘
18:39:37.393 Add 9F0A (Application Selection Registered Proprietary Data) with length 8 (0x08) - data ‚0001050100000000‘
18:39:37.404 <<S-5 [0x5] >>‚00B2020C29‘
18:39:37.460 >>R-43 [0x2B]>>‚702761254F07A0000000032020500A56697361204465626974870102730B9F0A0800010501000000009000‘
18:39:37.461 Found application ID ‚A0000000032020‘
18:39:37.461 Found application label ‚Visa Debit‘
18:39:37.461 Found application priority ‚2‘
18:39:37.461 Add 9F0A (Application Selection Registered Proprietary Data) with length 8 (0x08) - data ‚0001050100000000‘
… yes this is my day job 