People look at you funny for not knowing how a credit card has worked for the last 30+ years. Here chips got introduced mid-80's and all cards had chips circa early-90's.
Why did it take so long for credit card to feature chips in the US ? Because it took a while for CIA's in-q-tel to take over control of gemplus, the company who owned the smart card technology, which happened early 2000's. This is known as "l'affaire gemplus". Once they got control, the company HQ got moved to luxembourg tax haven and the R&D and tech moved to the US. A few years later in 2006 it merged with competitor axalto to form gemalto famous for making SIM cards and recently for their SIM crypto getting in NSA hands[1]. In 2009 french government tried to counter the takeover by becoming gemalto's major shareholder, but it was too late, CIA got what they were after as shown by in-q-tel selling its shares in 2010 which coincidentally was the years EMV credit card got introduced to the US.
If you understand French language, there is an episode[0] from France Inter's radio show "Rencontre avec X" that is dedicated to Gemplus and its takeover by the CIA.
I would check out [redacted] written in [redacted]. its a really [redacted] story which covers the [redacted] orders from when [redacted] was president and the [redacted] court which had oversight.
And I'm really curious about the security of tokens used to store private keys... in Brazil, at least, many tokens are in the form of cards, with gemalto being the main supplier.
I'm kind of disappointed that you didn't go into the security features present in a typical credit card transaction. For example, you could describe the crypto protocols used to communicate with the gateway and/or card processor, what kind of data the stripe and chip contain and how it is used for authentication, etc.
Another thing I find interesting is the anti-tamper features that are present in a standard credit card terminal. There's a great CC terminal teardown video by EEVblog that walks you through them: https://www.youtube.com/watch?v=tCgtTPwlDSo.
The way I see it, this is describing the system exactly as much as it needs to make its case that 'banking system is bad and expensive, use our stuff'. Covering security, or the lower fees in Europe (thanks mostly to the security features), goes against the narrative.
An interesting tidbit: An extra reason US fees are so high are premium credit cards choke full of rewards: Not every card has the same fees, and the highest fees come from cards that are handing you extra rewards, that are paid pretty much directly by the merchant. It's just that banks know that the better the rewards the more people will use the credit card, and the easier it is to take the business away from cheaper cards, as nobody charges you more at the register for using a Chase Sapphire Preferred instead of a debit card.
Security features also make US cards extra expensive, as the best you have is Chip and signature, and that doesn't cover online. If we demanded 2FA in every transaction, including online, fraud would go very close to zero, and with it, fees.
With more modest rewards and better security, interchange fees could shrink by over a percentage point: Banks just don't do this because there's little to no competitive pressure.
Well if we really believed in the free market and consumer protection, there'd be a law requiring the total transaction cost be printed on the sales slip. Whether the merchant pays it or passes it onto the consumer would be up to the merchant, but the amount would appear on the slip so the consumer sees these costs and who is paying for it.
What we really have is mercantilism, where the issuer by contract disallows full information to be conveyed to the consumer without the consumer's consent, and this is in effect protected by law by the fact it isn't illegal. You could also call it an example of chrony capitalism.
> Well if we really believed in the free market and consumer protection, there'd be a law requiring the total transaction cost be printed on the sales slip.
So "if we really believed in the free market", we should regulate the details of how a private transaction can take place?
Leaving aside any other aspects of that proposal, whether positive or negative, it doesn't seem reasonable to describe it as "free market".
>So "if we really believed in the free market", we should regulate the details of how a private transaction can take place?
The information that has to be expressly stated as part of a contract is not some minor detail. It is at the very core of enabling free markets in the first place.
Some seem to think of free markets as a sort of natural phenomenon and of regulations as a distortion. But that isn't true at all.
Contracts, property rights and the responsibilities of all participants in a trade are concepts of law. Without them you would have to rely on implicit cultural conventions and resolve disputes by means of duels and vendettas.
> So "if we really believed in the free market", we should regulate the details of how a private transaction can take place?
Yes. I don't think "free market" is incredibly well defined but the concept it evokes to me (as someone with a degree in economics), is a market approaching perfect competition[0], which is well defined.
A perfectly competitive market has a number of requirements, things like low barriers to entry, lots of buyers and sellers, no externalities, and so on.
A government policy that intervenes to try to aid perfect competition (e.g. some anti-trust legislation) could still be called a "free market", I think.
That said, I realize some people seem to define it to mean "free" from all government interventions, but they don't have a monopoly (heh) on the use of the word.
Free market doesn't mean freedom from regulation, it means freedom to compete. When lack of regulation enables a (set of) actors to make competition harder, you can make a market "freeer" by introducing regulation.
Making it explicit to customers with debit cards that they're subsidising the rewards of other customers will [edit: "could"!] incentivise them to demand lower fees, for example. This is a free market at its best.
Free markets are not devoid of regulation; in fact free markets are not naturally occurring, it is created by regulation. Otherwise you end up with all kinds of obfuscation, which makes it impossible for people to make informed decisions.
No longer. Merchants can elect to publish and pass fees to customers. Durbin amendment legalized it. Didn't change anything though. Pretty much no one does it for competitive reasons.
Yes. And as a precondition that this information is exposed by the issuer when the authorization is created so the POS can provide the correct information. Right now this is obscured, the merchant doesn't know what fees applied to which cards until their monthly closing statement.
That's a lot of info to have to expose in a very short period of time. It also would involve integrating payment/contract info into systems that probably have no knowledge of it, today. How many APIs do you know of that access contract payment details every time they are accessed?
2FA I guess you mean 2 factor authentication? I guess the cost burden is overestimated. India has made it mandatory for all POS and even online transactions to have 2FA, like Visa's 3D secure service for online and ATM pin for POS. Other providers also have it implemented. It must be not very expensive to make the same service in other parts of the world. Wondering why they are not doing it. In India, RBI had released stricter guidelines for that after initial spike in card fraud during the online business boom. Not sure of how much percentage it helped to reduce the fraud, but it's a safe feeling that even if your card is lost or it's details are stolen, you are not robbed of your money in the bank.
[Edit]
And if you are wondering how companies can store the creditcard data for automated payments like Uber, they cant .Uber have tied up with payment wallets to make payments seamless or you have option to pay by cash. For business there is an option for interbank automated transfer but that require you explicitly singing agreements.
You make some good points, but with regards to the security of money in the bank, credit card customers in the U.S. are typically not liable for fraudulent transactions. By law liability is limited to $50, and Visa and MasterCard rules make liability effectively zero.
Really? Do you know where you can find that information? I'm surprised that Chase does it given the amount they could recoup from their rewards programs.
That doesn't say what you think it says. Every business has expenses that eat into profit. Saying that Chase pays for that out of its own pocket is like saying uber pays for drivers out of its own pocket.
Unless I'm reading it wrong it's because of the signup bonus that's worth $1500 in travel not because they charge the lowest card rate and eat the rewards cost
The transactions on the network (i.e. between the banks and the association) typically use the ISO 8583 protocol: https://en.wikipedia.org/wiki/ISO_8583
The actual implementation (for e.g. between the hardware terminal and their gateway) is usually using some custom API/protocol - for e.g. Stripe/Braintree have their own APIs as do other older players like like PTI (https://www.chasepaymentech.com/developercenter/index.html?W...).
Not surprisingly, EEVblog gets many things wrong or expects wrong things in that video. But still, having done a lot of embedded work on POS terminals in the early 2000's, it was a bit strange to hear him get things so wrong since for me they were quite obvious (SAM slots etc). Usually he's better informed - but POS terminals are strange beasts, although these days it's all ARM and a normal Linux that's running on the main cpu...
Interestingly, interchange fees in Australia for credit cards are going to get capped to 0.8% later this year. This is forcing banks to re-evaluate their reward card offerings. AIUI, American Express isn't affected because they have direct relationships with each individual merchant.
The big 4 banks in Australia have historically offered an Amex card and a Visa/MasterCard linked to the same account (because Amex isn't accepted everywhere and often attracts surcharges). If ANZ's recent move is anything to go by, it looks like the banks won't be able to afford offering a linked Amex with their accounts.
Does anybody know if using Stripe if we can pass the 2.9% fee onto our customers? We offer customized consulting plans that vary and typically in the thousands, so thinking of just adding a 3% credit card processing fee to the invoice for clients that use card.
Researching around the net, it seems for traditional brick and mortar, some issuers don't allow you to charge a percentage based card processing fee. Any idea is this is allowed on Stripe?
It's complicated and depends on things like where you're charging and whether or not it's a "fee" for using the card vs. offering a cash discount (how these are not essentially equivalent is beyond me):
I would check with your ISO/Processor...but you're pretty much fine as long as you charge a generic credit card surcharge and treat all cards the same. You only really get into trouble with Visa/MC/Amex/Discover when you start charging different fees on different transactions.
Thanks, I may have to reach out to Stripe directly to get an answer. My fear is that Stripe will say it depends on Visa, Mastercard, AMEX and defer to them which is not very helpful.
I did run across this link, which might explain why when you asked your initial question I was thinking "no way", but after reading the recent agreements was like "maybe so" (I worked in payments for a number of years, and always heard that cash discounts/surcharges for credit card use were disallowed).
So apparently there was a suit about that very problem which was settled in 2012. It looks like you would be able to, but if you're charging multiple thousands on the regular, it would probably be worth it for you to pay a lawyer to make sure you're in the clear. HTH.
Yes. The Durbin amendment specifically prohibits processors from restricting you from offering a discount for payment by other means.[1] What you found on the net probably is out of date.
Incidentally it also regulates debit interchange down to practically nothing. Processors like Stripe are making a killing on debit. Try to find one that does "interchange plus" pricing, and then you can accept debit at no additional cost to your customers.
I use Square and Paypal for my business invoicing because you can send invoices that can be paid via credit card via email. I add a 3% card fee explicitly to all my invoices. No one any of these companies has ever said anything. I also offer the option of Bitcoin and wire transfer payments for invoices w/o a fee.
We work with Stripe exclusively, and offer credit card or ACH invoices. ACH we don't charge any fees since the maximum fee from Stripe is $5. Credit card is another story since our invoices are in the multiple of thousands (2.9% adds up).
I can't really think of a specific, non-political reason to show the fee to the customer specifically on the payment terminal. If it's important to call it out, just put it on he invoice/receipt.
I work with tons of software companies that pass additional fees onto customers (so like 4% processing fee, and keep the residual).
Note - none of them I work with have used Stripe. They are normally using a gateway provider (like NMI) and a payment processor (like PayPro, Auth.net, Vantiv, etc). Stripe combines the merchant, gateway and payment processor into one bundle.
i've always found it to be profoundly messed up that address validation (AVS) and security code validation (CVV/CSC) happen after the funds are authorized and held by the issuing bank.
this means if you choose to decline transactions for cvv or avs reasons in your gateway settings, those funds are still actually held by the customer's bank as pending for ~24h, preventing them from trying the auth again if it puts them over their credit limit.
the only way to release them is for the merchant to call the customer's bank and provide the, cc number and auth code.
we've had to leave these "security" settings off in our payment gateway and just assess the processor codes ourselves. then manually call the bank if there are mismatches. it's a massive pain in the ass and pretty much a neccessity if your avg order is hundreds of dollars. >:(
We wrote our own system that preauths to get AVS, mandates a match to proceed or automatically voids the auth. You wouldn't believe his many people don't seem to know their own billing address. Customers get frustrated about the strict enforcement but we've only ever had one or two complaints about held funds. We just explain that those pending charges will fall off in 24 hrs, and they accept. Frankly, if the charge risks putting the customer over their limit, then it might not be such a good idea to deal with those customers. The cheapest customers are the most trouble and carry a higher incidence of returns fraud, fraudulent chargebacks, etc.
> i've always found it to be profoundly messed up that address validation (AVS) and security code validation (CVV/CSC) happen after the funds are authorized and held by the issuing bank.
That's because the alternative is the acquiring/issuing bank doesn't immediately reflect the authorisation in the shadow balance and only deducts it once either a confirmation has been received or a certain amount of time has elapsed, and of course that leads to a very chatty protocol and race conditions. Not to mention that the systems on the backend side at the acquiring/issuing bank would have to put the parts together.
My experience with writing integrations with acquiring banks was that you needed to issue a reversal to have the held funds actually removed from the shadow balance. But it didn't always work, something about the reversals having to be the next request immediately after the corresponding auth. Obviously this was a system not built to scale and the whole AVS/CVV was a bolt on.
AVS is most interesting because (at least using APACS 70, not so much ISO 8583 depending on the acquirer/issuer) it only works on the address numerics and not the other chars. So when you input your street number and postcode (at least outside the US) you can put whatever you want in the form as long as numbers match, anything else is thrown away.
This isn't quite true. It is up to your issuer if they decide to approve the transaction despite failing AVS or CVV checks. Often they will decline the authorization, but depending on their risk signals, might decide to approve it. Then, the merchant (or the processor they are using) can decide if they want to let the transaction go through despite the failed checks, or call it a decline and reverse the authorization, which removes the pending charge. Crappy terminals might cause the pending authorization to sit there for 1-3 days by delaying or not sending the reversal, but in general that shouldn't be the case.
>If the merchant doesn’t settle within a certain time frame specified by the network, then the authorization expires and the reserved funds are released (as with every complex system, there are caveats here too).
Where can I read specifics for each network?
Also, the post doesn't do a good job of explaining what affirm is. All I know is it's some kind of alternative.
it's almost always a 30 day window to run a capture from the date of initial auth.
i've seen few "caveats". paypal has some tighter constrains on their fund availability guarantees. they make you run a re-auth after 48 or 72 hours - i forget the specifics, but it's in their api docs.
The OP has things mixed up quite a bit.
For starters, Point Of Sale flow should be described separately from the Card Not Present (as in online purchases) flow (protip there really is no such thing as transaction void in POS world).
There are also things like auth reversals, partial captures etc.
I see this being downvoted, and I'm wondering if it's not simply just misinterpreted.
Most places in the US I've used chip&pin, the process goes like this:
- arrive at merchant, select goods, get total.
- look for a sign that says chip is not enabled.
- failing that, move assuredly towards the chip reader and keep an eye on the cashier to ensure he or she doesn't move to stop you.
- put card in reader (if enabled you can do this at any time - but doing it earlier won't save you time)
- wait 2-10s while the reader figures out what to do
- approve whatever you need to when it pops up.
- wait 30-60 seconds for the transaction to go through, then find out you miskeyed your pin.
- Repeat previous steps and associated waiting. Ignore eye-rolling of others in line.
- walk out a satisfied customer.
Obviously I drew it out as long as possible there for effect, but I've only ever seen very slow C&P implementations here. I am usually spending up to a minute waiting for the transaction to clear.
By way of comparison, swipe cards take about 3-4 seconds to process. Debit cards with pins take 3-4 seconds + however long it takes you to type in the pin.
So I full understand the "sadly" prepended to the statement.
I'm in Europe and never used swipe cards (haven't seen a cheque since I was a kid, not sure they're even used anymore, but I digress) but the experience is really simple and the times you mentioned are always shorter.
Select goods, put the card in, enter PIN, 10 seconds later I'm walking out of the store. With contactless cards it's getting even simpler and faster and I insist buying at shops that use them. In that case the whole transaction is just one short beep and I'm out. If the total is over ~$20 then I also need to enter the PIN.
It's not that bad in Europe, but it's still bad. With swipe, I can swipe before the clerk has finished scanning my products, and then I can put my card back in my wallet.
With chip, I have to wait after the clerk has scanned all the products and after he pressed the "pay with card" button on his terminal. During the authorization, I have to keep the card plugged into the POS. I do this while I bag my own goods, because in Europe the clerks do not fill up your bags like in the US. At some point during the packaging process, I have to stop to take my card back because I don't like to leave it there while the clerk has started processing the next customer.
The experience sucks profoundly. The convenience at swiping at any time during idle time cannot be understated.
There are a few local B&M merchants here that are using a specific model of chip readers, if recollection serves me correctly they're all readers from First Data, that are astonishingly fast -- at least compared to the all the others, which you've quite-accurately described.
Every time I go to the local mom-and-pop butcher shop I commend them on their chip reader's super fast processing speed -- and each time they comment that "Thanks, everyone says that!".
I find it incredibly funny and frustrating that their card reader is so fast, enough so that others have noticed & commented on it too, while everywhere else -- the local chain grocery stores for instance -- consistently have roughly >=1 minute processing times.
Also frustrating? The cashier has finished ringing my items up. I put my card in, select "No cash back", type in my PIN number, it thinks for a bit ... and then, it asks me if I want to confirm the charges?! No, I don't, I just typed in my PIN for kicks! I get it, it's to verify the amount, but I'd love to know what percent of the time a user [intentionally] selects "No" at that screen -- I probably _accidentally_ select "No" about 5% of the time, and roughly 0% of the time have I ever intended to select "No". Small things, but annoying UX overall.
I'd think that many larger chain retailers are working on this. Some may have it solved w/ more "proprietary" systems; I don't shop at Target much lately, but I recall their payment UX being superior to most, unsure if their chip system is too though.
You missed the part where you put the card into the chip reader early, and it beeps loudly and everything stops while you read that the card can't go in early, so you take it out and huffily wait until it says enter card now.
Even better are the terminals set up to use the chip for credit transactions but require a swipe for debit (after inserting the card and selecting debit). Truly a WTF moment when that happens.
well, there's the rest of the world, and there's the US, where chip cards are recent and still lack chip+pin requirement for now. we still use imperial units, too! not to mention the worst (read: non-existent) maternity-leave laws on earth - worse than many less developed countries.
Exactly! He said that with such authority, didn't he? :) Chase just issued me a chip card in the last couple of years, and every time I check out of a store equipped with a terminal that can do both, it's still pretty much a 50/50 chance they'll tell me the chip reader doesn't work yet and I need to swipe.
In my experience most stores are pretty good at this point about having some sort of sign or label if their chip reader isn't working. But I'm sure it's not always the case and there was certainly a lot of confusion a year or so ago when they were first phased in.
Well, now they would do well to put a sign up if the chip reader is working. Because now I by default assume the terminal vendor is lazy and won't implement it until they have a financial incentive to do so.
> well, there's the rest of the world, and there's the US, where chip cards are recent and still lack chip+pin requirement for now.
And don't forget paper checks are still circulating. I didn't try last time I was there but I imagine that when you go to cash a paper check you go to a guy sitting by an abacus.
In the US swiping is fairly common. I might only use my chip once or twice a week. The gas stations all by me, my grocery store, and most of the restaurants near me all still have swipe readers. They are all fairly large chains so this isn't some local one off.
Only very low value purchases (less than 30 GBP) can be made without a PIN, in the UK at least. That won't cover a decent restaurant meal, refuelling a car or grocery shopping of any significance.
Wow, that took me back. I don't remember seeing anyone swiping their card in recent years, even chipcards are becoming more and more uncommon - contact-less payment leads the way now.
Poland. In one of the top5 cities here but nevertheless, even if I'm visiting much smaller ones it's hard to find a place where you cannot pay in a contactless fashion.
This PayPass, or whatever is called, technology really took off here in the last 5 years.
That was easy enough to infer, what wasn't was where in the world contact-less payment systems came to dominate. Even in Europe chip appears to be the norm. China? Japan?
Because swiping is so much more convenient. With a magnetic transaction I can just swipe and put my card away. Most of the time I swipe at the beginning of a long checkout (grocery store). With a chip transaction, I need to leave the card in until the very end. I now need to leave my wallet out, or put the wallet away and then remember to take the card back. More card readers are optimized for swiping with card insertion as an afterthought. Inserting a chipcard is usually at some awkward angle.
As a consumer, chipcard provides no benefit. Yes fraud is theoretically lower, yet the banks aren't passing any of these savings to me (I'm still waiting for lower rates or higher paybacks).
Yes, this! At least in the US, there is zero benefit to me as a consumer from chip cards.
The banks have not increased rewards, or lowered interchange fees (thereby lowering retail prices).
Federal law protects me from fraud no matter the card input method.
Due to the risk of online fraud, I still have to check my statement for fraudulent charges.
There are, however, noticeable downsides. Including everything coin mentioned, here are a few more downsides to chip cards, at least in the US:
* Chip cards are slow in the US. This has gotten better lately, but its still bad. Before the downvotes start, look at the references [1] [2]. This leads noticeably longer lines at stores.
* Not every merchant accepts chip cards. Sometimes its hard to tell which version the merchant accepts.
* There are a lot more annoying noises (the buzz when you leave your card in too long). Its a small nuisance, but it adds up. Previously the transactions were silent.
While federal law protects you from fraud, it's still extremely inconvenient to have your credit card skimmed and then likely automatically cancelled by your bank at an inconvenient time when someone tries to use it, and left without that credit card until the replacement shows up. Chip & Pin solves this particular issue fairly well. This is even more critical for debit cards being skimmed where it's actually a non-trivial process to get your money back.
The swipe is a 1 second job, but the insert+PIN takes maybe 10sec. I do the card+pin at any point while the cashier is registering my groceries. By the time he finished scanning them all, the card has been back in my pocket a long time. The only thing I do at the end is hit "ok" to confirm the amount. The procedure would be exactly the same with a magnetic card.
Even just the convenience of a more reliable read is worth it.
This doesn't work in the US. Where I live, for a credit card chipcard, the cashier has to finish, then there's a 2-way authentication with the server whereby the card has to stay in the reader. This is why the card has to stay out until the very end.
I can see the extra security added by having the card in at the time of confirmation - but it seems a pretty heavy price to pay. This certainly isn't worth 10 seconds extra per customer checkout in a supermarket.
He says why. With swiping, you can often do the swipe while the clerk is ringing up your groceries and put your wallet away as opposed to having to do the transaction at the end (as you also need to do if you use your phone).
He's not wrong although this is pretty far down my list of life's annoyances :-)
The swipe transaction system doesn't provide a mechanism to authorize a transaction for a specific amount, unlike the chip system. That is - you swipe, and the merchant uses the details on the magstripe to make some arbitrary transaction later on - potentially weeks or months later as I've found out in the very few places in the UK that still run offline transaction systems. With a chip system, you authorize a specific amount and no more within a dedicated machine, and the merchant doesn't get a hold of all the details necessary to make another transaction.
I imagine they'll void or otherwise adjust the transaction. I've never had an issue. Frankly I'm more likely to notice something while I'm leaving the store if something didn't seem quite right and I start looking over the receipt.
> With a chip transaction, I need to leave the card in until the very end.
Visa announced Quick Chip EMV that enable you to dip your card at any time of the transaction for it to generate and capture a cryptogram before the end of the transaction. This will allow Visa EMV to be almost as fast as swiping.
This is NOT a consequence of chip card. In India, everything is chip and pin. Our ATM machines just need you to put the card in , chip side facing up and then take it out 2 seconds later (it glows green). Then you can put in your PIN number and move forward.
I think that's because ATMs are trusted devices, and only need a generic signed authorization to do anything. Payment terminals need to have the specific transaction amounts signed by the card, IIRC. At least that's the model I've learned here in my (European) country.
No. ATM need to sign amounts as well,but keep the key in memory. I don't think it's a consequence of swipe vs chip or anything. It just the UX built into the machine.
IMHO , consumers find it reassuring that they are asked for a pin AFTER the amount is entered into a swipe machine in a bar (where you are much more likely to be drunk). This kind of a mechanism is very nice when amount is entered by someone else (the retailer/cashier).
At the ATM, you are the only one that enters the amount.
So the pin entry at the end of the workflow is not a bug..It's a feature.
You can actually put your card in at the beginning with certain machines in the UK, and then it picks it up once the cashier starts the payment process. You'll get weird looks if you do. The slot for the card is almost always at the bottom, under the PIN pad. I assume the US uses different machines, since you need to do some awkward signature thing?
This is what a payment terminal looks like in most US chain stores. It would be attached to a mount of some sort on the customer side of a cashier booth:
It has a slot for a chip card at the bottom, a slot to swipe a card on the right, a PIN pad for debit transactions, and may be tap-enabled. The screen portion displays the order total and other instructions, and is also touch-sensitive for providing a signature using the attached stylus.
yes, the chips protect banks from fraud. your contract with the credit card already protects you from fraud as long as you report it in a timely fashion.
Depending on the category of the merchant, the network charges an interchange fee, the cost of which is split between the issuing bank (which takes most of the cut), the card association, and the acquiring bank.
This isn't entirely correct. The interchange is the part of the transaction fee that goes to the issuer. The card network gets a scheme fee, and the acquirer/processor charge a fee on top of that. If a merchant pays the same rate, regardless of what type of card is used, (credit/debit, consumer/business) then the processor or acquiring is basically rounding up.
> Visa and Mastercard alone control 70% of the market based on purchase volume. And lack of competition reduces the incentive for firms to improve the efficiency of their technological systems or price their services fairly.
Some detail about the pricing might help here. Most of the fee is actually going to customers, believe it or not, and sometimes processors. It is an interesting study in complex two-sided market dynamics. This is critical to understand when thinking about how to improve the system, and it's something many startups figure out the hard way.
Most of the processing fee goes back to the issuing banks, not Visa/MC. On a typical transaction:
1. Visa takes "only" 0.11% + 2 cents.
2. Depending on the card maybe 1.5-2% + 10 cents goes to the bank that issued the card (e.g. Chase, Citi, Bank of America). These are fixed and published rates called interchange.[1]
3. The remainder of the fee is processor markup (e.g. Stripe, First Data). They are responsible for merchant fraud so their markup can vary a lot depending on merchant risk profile and bargaining power. E.g. Starbucks pays virtually nothing in processor markup, while Stripe's markup on thinly vetted ecommerce sites is huge.
So while 0.11% of all card transactions is a lot of money for Visa/MC at scale, most of the "high" 2-3% card fee is actually going back to banks. Competition between Visa & MC keeps their cut to where it is. Even though they control "70% of the market", there is two-party competition there.
So what's the deal.. what are fees so high? Don't banks compete with one another? Well, yes, they do, but it's not by picking lower interchange rates. There's one more piece to the picture: card benefits like reward programs that refund 1-2% to the customer, thinning the bank's take considerably. Banks compete on how much reward to pay out to the customer.
Merchants dislike higher fees, obviously, but given the importance of card acceptance to completing a sale, they are more tolerant of fees than customers are tolerant of poor card benefits. The bottom line is banks need to compete for customers more than card networks need to compete for merchants.
The only way merchants have been able to reduce card fees is through regulation. Visa/MC have built systems that effectively leverage the power of customer choice. If you want to build something different you need to look at the customer benefit side of things, not just offering merchants a lower-cost method.
Nice summary. Worth mentioning that processors like Stripe and Paypal rake in the net difference between the fairly low Durbin "signature debit" rates and their 2.9% fixed fees.
Gateways like Stripe or Braintree are used for online payments only, aren't they? They are not involved when you swipe a card in a physical store's terminal.
The data doesn't really end up with advertisers though, does it? I can't call up AMEX and ask for a list of all the places my member of Congress uses his card, can I?
You can't ask for individual data points; you ask for a segment of the population (eg. "musicians over 40 with children") and they'll return the data aggregated in bulk.
I don't think they will actually return the data though. I think it's the same as Facebook. You can target ads to a certain segment, but they won't actually tell you who is in that segment or what the actual data is.
What annoys me is the expiry date and CVV. It seems like their solution to "more secure" is just to add more numbers. How about put the last 3 digits on the back, and call it the cvv ? How about use alphanumeric card numbers so we dont have to use as many digits ? Get rid of the expiry date used as validation. It's just more entropy, if you need more entropy then add another digit. It's just annoying having to type that crap in all the time.
In addition to not being on the magnetic stripe, merchants are also not allowed to save it, so if you steal a merchant's database of stored CCs, you don't get the CVVs.
No, that's what the CVV is for. It's only for card-not-present online transactions.
(Yes, there are probably a lot of retailers breaching their PCI-DSS compliance by storing the CVV, but the point is they're not supposed to. Until we can do chip-and-pin or similar for online purchases, e.g. Apple Pay, the problem remains)
Expiry date: It checks that you're not using an old card that someone has just thrown away, often card numbers remain the same if you get a new one. This is effectively just specifying the version of the card, and is something that needs to be on cards anyway (so the user knows when they're no longer valid). Additional benefit is that it means your customer has just checked that their card is still valid.
CVV: Not sure why it's on the back, but the point of this is that it's a number that's not raised, so it's not recorded when using a credit card imprinter (less common than is used now).
That doesn't seem convincing, for the expiry. The issuer needs to keep track of cancelled cards anyway, and they should be cancelling expired cards anyway - it seems like a huge security hole to keep expired cards in an active state and rely on an expiry date check to reject transactions.
I assumed that it's a leftover from early days, before online card checks, so the merchant can check that the card is still valid (besides checking signature and ID or whatever). When introducing online checks of the magnetic swipe, expiry date was part of the data transmitted, and early phone/Internet payment systems relied on reconstructing the data present on the magnetic strip, to "fake" a swipe. Then it just stuck from there.
Expired cards and active cards generally have the same card number. I've certainly had multiple cards with the same long number across them. If you have to write the expiry date on anyway then why not use it?
All my debit cards have had the same number on them for the past 5 years (at least). No part of it is my account number. I know it by memory. I have no evidence that it's been compromised.
One reason for this is that it's at the discretion of the issuing bank whether or not to accept an expired card (in fact, you can get into trouble for handling this locally with some processors).
I believe it's a convenience thing for the end user, when issuing a new card - offer a couple of days "grace" - and arguably there isn't much risk associated with this practice: lost/stolen cards are always cancelled immediately.
Expiring cards has a few other benefits as well. It ensures that the card company has a reasonably-recent mailing address for each of their customers. And it makes it easier to roll out security features/improvements to the actual card since they can limit the maximum age of any valid card. Also, merchants can use the expiry date to alert customers to re-enter credit card details prior to expiry for recurring charges.
> if you need more entropy then add another digit.
That would break so much as most of the message formats and batch files use fixed width fields. It's probably the same for the databases underneath. Changing to alphanumerics sounds nice but the check digit algorithm would have to change from Luhn to Luhn mod n. More breaking changes.
Banking systems are one of the ultimate forms of legacy, which is why most of the security additions have been bolted on. Just look at 3D secure - they added an entire subsection to the message format and it was still just another single factor auth method that nobody wanted and everybody hated.
> but the check digit algorithm would have to change
or just get rid of it. It was a relic from 20+ years ago when networks and computers were 1/100th the speed they are today. Let them enter invalid numbers. Let the server return an error (as it already does)
Similarly, once we did away with legacy electromechanical phone switches, the (phone area code) NANPA started allowing area codes with non-[0,1] middle digits. The big form of 10-digit numbers was retained and extended by relaxing a legacy constraint.
To play devil's advocate, it may be useful to know when the card expires for a merchant who mightn't charge immediately. And maybe it's significant that the cvv is on the back so you couldn't just use a photo. And mixing letters and numbers is scary. But I agree. Maybe the solution is just having lots of entropy and reading it electronically, who really needs to read out card numbers over the phone?
I agree, keep the exp date, just dont use it to validate the transaction so I dont have to fumble with the keyboard and mouse to select stupid dropdown boxes. Let the server handle the case where the card expires tomorrow. I agree the CVV should be on the back, so just take the 3 numbers off the front and put them on the back.
I think we can all agree the correct model is a card that generates a globally unique card number for each and every transaction (e.g. coin failed, final). It should also have a 2nd factor authorization like CVV which is not embedded in the magnetic strip (can't be read by swipers).
Plus, you still have to support plaintext between the EMV chip and the reader. This opens an entirely new class of places to steal card details (like PINs)
I don't agree about the unique account number every time. That's nice to opt into when you want maximum privacy but it screws up things like loyalty programs or recurring billing where you actually do want a merchant to remember you.
What we can agree on is that there should be strong authentication. Apple Pay is the best system I've seen. It creates a unique but static account number that can only be used with Apple Pay, which has strong authentication which is also convenient (Touch ID), so it can be mandatory. Thus it doesn't matter if the number gets stolen as it's useless without Apple Pay.
subscription billing, its definitely one of those big, ugly, nasty hard to solve problems that no one really wants to talk about or address. Definitely falls into the category of "if its not broke don't fix it."
But payments in general are just totally effed and can't seem to move forward without some sort of fix. as a consumer its both amazing and incredibly frustrating. as a merchant it's essential. Imagine how much money netflix would lose if you had to auth payments every 30 days.
1. Use your real card number. I never do this.
2. Use a merchant-locked card number. I use this commonly for online pizza and other online shops I don't trust much. Once a merchant uses it, only that merchant can use it.
3. Use a one-time card. The number is used once and disabled. Good for one-off orders or skeezy purchases.
Overall I've been pretty pleased. I think the idea that card numbers should be disposable is awesome.
Email me @ aaron@getfinal.com I'd love to hear more, if you don't mind. We encourage people to use the physical card and just treat it as disposable if it ever gets skimmed/breached/stolen/lost. We made sure it impacts none of your other relationships :)
this is pretty solid actually, ill have to check it out.
edit, i checked it out. so 1) its no open to sign ups, and 2) you have to have pretty stellar credit to even be considered. so that leaves out most people.
Email me at aaron@getfinal.com and we can get you a code to apply :) We're working on broadening our underwriting criteria, but this is a complicated business overseen by an incredible amount of regulation, while also taking risk when we issue new lines of credit. Large banks throw around a lot of $ to make it work (a lot in this statement), but to start a new provider takes a lot of tactical decisions and iteration to grow in a safe and sustainable way.
There are a tons of reasons to keep our signups closed for now. One non-obvious reason to most people is that it costs us money to lend out money to customers. Theres a ton of others we're working on solving in parallel too
never thought of this.Simpyfying the number system would be beneficial for the consumer but also for the companies who make money out of this CC system
People look at you funny for not knowing how a credit card has worked for the last 30+ years. Here chips got introduced mid-80's and all cards had chips circa early-90's.
Why did it take so long for credit card to feature chips in the US ? Because it took a while for CIA's in-q-tel to take over control of gemplus, the company who owned the smart card technology, which happened early 2000's. This is known as "l'affaire gemplus". Once they got control, the company HQ got moved to luxembourg tax haven and the R&D and tech moved to the US. A few years later in 2006 it merged with competitor axalto to form gemalto famous for making SIM cards and recently for their SIM crypto getting in NSA hands[1]. In 2009 french government tried to counter the takeover by becoming gemalto's major shareholder, but it was too late, CIA got what they were after as shown by in-q-tel selling its shares in 2010 which coincidentally was the years EMV credit card got introduced to the US.
[1]: https://theintercept.com/2015/02/19/great-sim-heist/