Also chip cards don’t ever leak the CC number as part of the transaction. However, it seems like you could request a transaction for a different merchant?
Chip cards do send the card number as part of the transaction. They just also send other information that makes it easier to tell if the original card is physically present, meaning you don’t have to worry as much about someone stealing the details and spoofing your card.
You may be thinking of tokenization, which is a feature of some services such as Apple/Google Pay. This is where a “fake” account number—really a number that is scoped to eg a specific device or a specific merchant—is sent with the transaction. That then gets resolved to the real number somewhere down the processing pipeline closer to the card issuer. The benefit being if someone snoops this tokenized account number they won’t be able to use it thanks to the tight scoping.
Are you sure? I thought chip cards worked using certificates signed by the card issuer. And transactions involved sending a nonce to be signed. Everything can be verified by the public key. I could totally be wrong though.
Maybe that's how IC cards work in some places, but that's definitely not the normal EMV standard. I've worked on the implementation of EMV chip card processing through basically all the major networks and can tell you that we necessarily have access to—and have to store after—the raw card number to facilitate the transaction. There's a lot of encryption involved to prevent bad actors from getting access but it's far from end-to-end.
In a correctly configured system, the terminal itself would have to be reconfigured. That can sort of be be done via the POS, but also requires credentials from the group that configured the terminal.
I used to work with those payment gateways, and I always wondered about that attack vector. The terminal config (where you’d put your merchant ID, etc…) is protected by a PIN code, but suppliers typically just use the same PIN for their entire fleet. It’s not really a secret PIN either, because the terminal tech support will usually end up getting merchants to type it in if there‘s some remote support/debugging needed.
You could reprogram a terminal in a bar in a few seconds on a Friday night. Wait for the weekends takings to clear into your merchant account, and then take off with the money. The way that it falls down though, is that you need a merchant account, and there’s a lot of KYC and due diligence to get through if you want to set one of those up (there are a lot of merchant initiated scams, and your bank doesn’t want to be on the hook for them).
> Wait for the weekends takings to clear into your merchant account, and then take off with the money.
That's the difficult part - since the acquiring bank is fully financially responsible if you do so (they'll compensate everyone else involved for the fraud chargebacks, no matter if they can recover it from you), they generally take quite stringent steps to fight merchant-initiated scams, and the simplest step is simply freezing the money for some time; 30 days is not uncommon but I have even seen 90 days if the merchant's profile is risky or if the incoming payment volume suddenly increases significantly - the bank is effectively treating any payments to the merchant as a line of credit or letter of guarantee until it's clear that those payments won't be fraudulent or charged back. So a merchant can quite realistically do some shenanigans with a reprogrammed terminal, but they won't be permitted to take off with a large amount of money from the merchant account until a sufficient amount of time will have passed for the first chargebacks or complaints of fraud to show up.
I don’t know about every jurisdiction, but every place that I’ve ever been involved with payment terminals, the money clears to the merchant account in a couple of business days. So your weekend’s takings would usually be cleared by Tuesday. I can’t imagine any retail or hospitality business would be able to extend a 90 day line of credit to their payment processor on all payment card revenue.
I think the main reason this never happens is because there’s a lot of easier and more profitable scams you can operate as a fraud-oriented merchant.
I would expect there to be a difference between a first time and a repeat thing. If you do out-of-normal-operation things, the bank will treat you more suspiciously, if you do your normal business, it can release your money immediately
I built the first online payment system for my university' frosh week in the early 2000's (before that they only accepted cash). This is pre-shopify/etc, and if you were doing any moderate volume it was worthwhile to use a gateway that went direct to your own merchant account.
They started accepting signups a couple weeks before school started, and on the second day it was running, after several hundred signups (of ~$200 each iirc), apparently some security people from the bank showed up at the orientation office at the school basically just to confirm it was legit. (I don't remember if they suspended the account first or not)
I had built a few online store sites using merchant accounts by then, but nothing that went from zero to that volume so quickly; it was fascinating to see that check in action.
I wonder what volume it would take to trigger such scrutiny today, and what it would look like..
Different merchant underwriters have different processes. Visiting merchant locations was pretty common, usually just to check if it looks like a real operating business though.
> they'll compensate everyone else involved for the fraud chargebacks,
But in this hypothetical would there be chargebacks? People went to a bar. They consumed, and paid for it. As far as the costumers know it went all good.
The one who is harmed would be the pub. And presumably they would complain and soon.
I don’t doubt that the whole scheme would come to light quick, i’m just questioning the exact mechanism.
Presuming the attack wasn’t initially detected, which is entirely plausible imo, it would be noticed by the merchant when the funds didn’t settle into their account. So if you do it on Friday, the merchant should notice by Tuesday at the latest. If they don’t pay close attention to their accounts, it might take a little longer.
Don’t payment gateway request an initialization procedure that registers the POS with the remote gateway ?
During that procedure the terminal unique ID is sent, and depending on your environment, if you have a stable outgoing IP the connection might be filtered on that as well (assuming you do that on site, not at a POS provider). Jumping through a bunch of hoops you might still be able to hook a POS on another merchant account, but once the issue is detected there would be enough info to reverse the transactions (doing that after capture could cost fees, but it’s still better than nothing).
Looking at the delays between the transactions being cleared and the money appearing in your bank account, even with the best timing you might not see a penny of all of that.
1. You need to register yourself as a merchant at an acquirer bank. Either directly or through intermediaries such as Stripe/Square etc.,
2. Go through reasonably stringent KYB (Know Your Business) process.
3. Do a few legitimate transactions so that everyone in the payment processing chain (acquiring bank, payment gateway etc., issuing bank, network (Visa/MasterCard)) begins to trust you.
4. Reconfigure the kiosk to use the above merchant account.
5. Pull out money from the acquiring bank before enough customers raise a charge-back and your your account is marked as fraudulent by someone/everyone in the payment processing chain.
These fly-by-night merchants are indeed created; especially at marketplaces such as EBay, Amazon. But to do it at a physical kiosk such as McDonalds' seems like a low ROI to me.
I doubt that'd work. My client is set up as multiple merchants (different companies from a legal pov) but with the same payment provider, going over the same pipes, etc. Even so, the way the payment servers were set up, they could only mix up the merchant config if the "wrong" one also happened to be on the same server.
They have dedicated servers, so I'd expect McDonald's and other big chains to have them, too, which means that you couldn't send payments no anyone outside the mother company.
