Plastic Money
computer.rip
computer.rip
The system was called UzKart (do not confuse with UzCard, which is modern online successor of that system). On the day when salary was paid, you had to find an online ATM or internet-connected terminal in the shop, and "load" money to the card. Then, you could use the money on the card to pay in offline terminals. Balance could be checked directly in offline terminals, you had to ask the seller to print it.
Sellers had a special offline card, called "merchant's card". In the end of the day they loaded all the transactions from an offline terminal to a merchant's card, and then brought the card to an ATM or a connected terminal, to synchronize payments with the bank account.
If, for some reason, at the time of synchronization some payments failed to clear, payer's card was banned and they had an angry call from the bank.
When the system was introduced, internet connection was expensive and unreliable. It co-existed with online cards, but merchants strongly preferred to deal with offline cards. As soon as mobile internet become cheaper and more widespread, offline cards died because of the hassle with "loading" and "unloading" them.
More info on UzKart and UzCard can be found (in Russian) here https://gazeta.norma.uz/publish/doc/text97703_uzkart_ot_duet... and here https://uzcard.uz/ru/news/post/uzcard-bankovskaya-tranzaktsi...
The US has had free local calling for many decades now, so online card authorizations were always much cheaper than in many other countries, even long before the internet.
Still, there were some applications: The article mentions laundromats, but as far as I know, US military ships have also had a similar system.
There’s an interesting recent legislation proposal today that argues for a very similar system, but primarily for the sake of privacy (although network/power failure resiliency would be nice secondary benefits): https://ecashact.us/
They are still extremely popular in those region. One of the thing I dont understand is why these type of payment never took off in the West. Even things like Oyster card in the UK is only for transport but not for any other sort of payment.
Another point worth pointing out, Offline payment are much faster, with Sucia based on FeliCa capable of doing the transaction in less than 100ms. This is important in a transport system as heavily used as the Japanese transport. For people who are used to these type of payment, everything else just felt so slow.
With every iPhone now getting a Felica Chip built in, I was hoping this type of payment could take off. And yet nothing happened.
In the old days, you could use an imprint machine to run the card, and mail in the charge slip. Raised numbers and imprint machines are uncool now, but they lasted a long time as backup in case the terminal wasn't working or the power was out.
As far as I know, most US cards include the metadata for offline charges, where the terminal processes transactions in bulk, but there's more risk for merchants than doing an online transaction.
Stored value cards are popular in transportation, where speed is important, fault tolerance is required, and connectivity is intermittent. But even for gift cards, it's more common to use the card as an identity token, and get the value from an online ledger; it makes alternate uses much simpler.
The card readers we're supposed to navigate ourselves aren't perfect either, but it's much better when the card never leaves your hand. Honestly though I pretty much expect my card number will get stolen at some point. As long as I can keep an eye on my statements and my bank doesn't give me much hassle about reversing fraudulent charges when I see them it's not a huge deal.
Is this a real thing? Germany is horribly behind on payment options, but even we have mobile terminals that you yourself handle.
* Many transport cards were NFC or RFID or otherwise "you don't have to take the card out of your wallet" years before general-purpose cards were. Now, many transit systems just promote "tap-on and off with your Visa and don't bother loading money into our closed-loop network." (Interestingly, I will note that Toronto's system at least is cheaper to ride if you do use the closed-loop card)
* Conversely, merchants-- especially large merchants-- have desperate desire to get away from the general purpose card networks due to high fees and sometimes clunky chargeback rules. Notice the handful of "Walmart Pay"/"Kroger Pay" apps that they'll support rather than enabling Apple or Google Pay at the till, or even things like Target and some petrol stations offering propriatery cards that connect to debit for settlement.
Transport cards could be appealing for the merchant audience-- they're likely cheaper to process and represent funds already confirmed by the transport operator. But they're not federated, so it would turn into a nightmare of a thousand individual integrations and a UX like the early days of (pre-Visa/MC branded) debit where you'd have to check if the merchant supported the specific network your card was on.
Octopus takes an 1.5% cut, I'm not sure if it applies to the founding transport companies but I assume the money will flow back to them anyway.
Recently, some transport services started incorporating Chinese e-wallets like Alipay and WeChat Pay which utilizes QR codes, and the agony of seeing people (mainly Chinese tourists) repeatedly scan and fail at the gates blocking the whole queue during rush hours is quite depressing after years of smooth access.
Cheers.
From my memory, some newsagents etc. did allow payment by Oyster. But there just wasn't demand for it.
In Japan at least, many people don't have credit cards and are scared of any kind of debt (perhaps because debts are more enforceable here). So that might be a factor.
I have some friend who have made millions over the years in selling international calling cards and routing them through their SIP networks...
There is the ability to make a completely separate transactional system outside of of Central Bank Control, using these stacks for card loading and calling (network access) etc... but generally fighting against Money Monopolies is suicide for your business.
And on the one hand, rightfully so - EXCEPT in cases like SBF... that guy is such a criminal, the central banks like him, and his parents, and his donations, and his fraud...
The whole system has holes in every facet.
Robot Voice: Hello, you have a local collect call from "mig39 is ready to be picked up" -- do you accept the charges? Then my parents would just hang up and come get me.
Until 2010, most people will get their salary on a card, go to ATM, withdraw paper money and pay with that. Actually, cards only became relevant with the advent of contactless/NFC cards, which started around 2012. Then they spread like wildfire.
I wonder what caused the adoption of UzKart compared with plain old cash. I also wonder if any neighbouring countries had similar systems and what their adoption levels were.
One of the main reasons to introduce UzKart was to force the "gray" economy back under the eye of the tax authority. So adoption was forced by the government by mandating paying a certain part of the salary to UzKart and limiting cash withdrawals.
One of the cooler things Mondex could do was an early form of online banking. Some households were issued special phones from Bell Canada that looked like regular Nortel phones with a yellow card reader attached to the side and a much larger screen. You could log in to your bank directly from the phone and transfer money out of your account into the card. You could also use an ATM if you didn't have the phone.
It was a pretty neat technology but at just around the same time Interac debit payments really started to take off and people were much happier to have a card linked to their accounts rather than a card with a balance you could lose. The payments were also pretty slow, so anyone paying for the bus slowed the line down.
I still have my card and reader somewhere and I think it has a few dollars left on it. The last time I looked, many years ago, the only transactions that showed up on the reader were coffee purchases at Tim Hortons.
Edit:
Can't find technical details on Wikipedia[0] but the fact that funds could be added online indicate it wasn't offline? I would love if someone here worked on it then.
If both parties are offline, can you still make a secure transfer of stored value? Yes, with a trusted execution environment and cryptography, you can do it. So, yeah, smart card works; a smartphone works, a feature phone with NFC smart card works etc. For each, the risk profile is different which affects the answer to the next question.
Then, when does reconciliation happen? When either party goes online? What if it is not a closed loop system? Then, reconciliation needs to happen for both parties independently. How long can either party stay offline and continue to make transactions? Is it both send and receive or only send on one side and only receive on another side? What if one party (merchant/receiver) is more likely to be online (almost always). Does it just become online payments problem then? NFC tap and pay is exactly this scenario.
In India, right now, we have NETC stored value cards for closed loop systems like metro. For open systems like UPI we have recently introduced offline payments capability with very small stored value stored as tokens on the mobile phone and used for very small transactions. As the banks learn the real-world operational risks, the wallet limits and transaction limits will be increased.
Sounds interesting! I read about India's UPI for the first time a couple of months ago in an Economist article: https://archive.ph/WoqQp
Then the users and merchants can decide if they wait to click the verify button. And the default for anyone with data connectivity should probably be auto-verification. There is an incentive to verify, because if any double-spending has happened, the first to verify is the one who gets the money.
Double-spends will happen in any system that allows offline transactions, because a user has to be allowed to log into a new device (if they lose their old one), and there is no way to know if the money spent from their old device was synced to the server yet.
You can solve for that by having short validity of the offline tokens on device and having that equal the cool-off period for reclaiming those funds when new device is provisioned. If I had ₹100 unspent tokens in my offline capable device that I lost, and got a new device provisioned the same day, then that ₹100 will show up in my account and be available to load on my device only after, say 7 days, of cooling-off period. In those 7 days, if someone who found your device could spend it and if so you lose it. If you know you are likely to be offline only sporadically for few hours and not for days, you can reduce the validity (and hence cooling-off period) significantly to just 12 or 24 hours.
Who would accept "provisional money" though, if there is a realistic risk of it being double spent and therefore effectively worthless?
> Double-spends will happen in any system that allows offline transactions
Only if you assume untrusted devices. That's why in most past and existing stored-value systems, smartcards are being used – these have different security properties.
It's up to the receiver whether they want to walk to the internet cafe and connect to verify it, or if they just trust the person they got it from.
If all the devices are trusted, but can be lost/destroyed and re-issued, you have the same problem.
But these aren't mandatory: Physical cash also can't be replaced when lost, and only rarely when physically destroyed. That model might be preferred in some scenarios.
Apart from classical robbery held at knifepoint or gunpoint and taken to an atm and being robbed or being blackmailed to actually do instant money transfer online which do happen, there are other lower threshold but more frequently occurring and more painful cash "thefts".
One eye-opening story I learnt a while ago was this: the women daily wage workers (or the household help that comes to my home) who are typically the breadwinners for the family are coerced by their drunk husbands to give their hard earned cash which they will waste on more alcohol or gambling. This was the situation for decades. Now, with zero-balance, zero-cost bank accounts being made available at scale in India, these women can now keep their money safe and provide care for their children by refusing to give money to their husbands (usually it involves telling them they don't have the money to give when in fact they do in their banks). Such is the social reality for so many.
I do not think the loss of privacy is worth the convenience when talking about replacing cash in a society.
Most existing stored-value systems use "shadow accounts" for reconciliation (in case one of the card-level private keys gets compromised and makes it possible to "double-spend" electronic cash), but that's not really a required part of the system. If it's secure enough, it's possible to just leave these out!
It's probably also possible to create some kind of hybrid system which does create pseudonymous traceable logs which offer some trade-off between privacy and security, similar to how banknotes have serial numbers which can theoretically be traced, but practically mostly aren't.
And the enormous advantage of a privacy-preserving e-cash/stored-value system over cash is that it works on the internet too.
See here for one example where the indian state denied citizens access to their money by freezing their UPI accounts after unproven allegations. https://www.thenewsminute.com/article/bank-acs-can-be-frozen...
With one or more bank accounts, the woman must now keep her phone safe and inaccessible from the husband too. Or she must be very quick and diligent in deleting all the SMSes sent by banks for all kinds of transactions. This adds more hassles than saving cash with someone else.
In all the cases of alcoholism and men snatching money from the women/household without any other care, it's violence that keeps that relationship and "contract" alive. That violence isn't going to disappear just because physical cash is replaced by a bank account.
In summary, I don't buy the conclusion you've quickly jumped to.
You can solve that by actually having the money in the device so that reconciliation is not required, digital cash like the abandoned Mondex stored value system.
In many existing systems, there's a split between "merchant" and "customer" cards, of which only merchant cards are allowed to accept payments. Merchants often have to go online once per day and batch-submit all of the day's payments in order to be guaranteed settlement.
Among other advantages, this allows for a "lost/stolen" card feature: If a user loses a card, that card can be denylisted on a global list synchronized to all merchant terminals daily. After another day of waiting for straggler transactions, it's possible to determine the remaining balance of the lost card from the backend, and reimburse its owner, since further funds on the card can no longer be spent anywhere in the system.
One day is essentially just an arbitrary timespan here – you could make it 14 days, or an hour. In the systems I've looked at closely, one day makes sense because these are historically transit-focused, and e.g. buses don't have continuous network connectivity, but do go to a depot in the evening, which is a good opportunity to clear and settle all of the day's payments.
Customer cards never need to be online in such a scheme.
lol, literally less than 20 seconds.
> Then, when does reconciliation happen? When either party goes online? What if it is not a closed loop system? Then, reconciliation needs to happen for both parties independently. How long can either party stay offline and continue to make transactions? Is it both send and receive or only send on one side and only receive on another side? What if one party (merchant/receiver) is more likely to be online (almost always). Does it just become online payments problem then? NFC tap and pay is exactly this scenario.
Again, literally the exact problem statement and value proposition of Lightning, but stupid, stupid me for daring to mention it here, I guess. Feel free to ignore that the idea behind Lightning could be useful without being tied to crypto, but can't possibly have a conversation about that. Nope.
What conversation? You just dropped in here with flamewar bait and complaining about some self-imagined persecution without contributing any substance. Hence your comment is now gray.
thanks!
https://sv.m.wikipedia.org/wiki/Cash_(betalsystem)
I'm also reminded of the magstripe stored value cards used by our public transit agency. These were trivial to rewrite, but since most people who tried this did it to save money on their commute rather than random joyriding, it was easy for the agency to reconcile the usage logs to find out where they went every day and wait for them at their station...
These days I think the main advantage to offline systems is performance. When you have a busy subway station in Tokyo with massive crowds passing through the gates, nothing beats the throughout of offline Felicia Suica cards. Their gates default to open and you walk through while swiping without stopping, the gates only close if there is a failure. Vs EMV-based systems like London where you have to stop and wait for the card reader
I know of at least one person who had to spend the night in a detainment cell at JFK and then had to take a plane back to Sweden the next morning because the customs agent concluded that they didn't have any money for their stay in New York.
As to the gates being default closed, well, gates at train/tube stations can accept a range of things being presented to them including smartphone/watch payments, bank card contactless, Oyster card, Oyster season tickets, paper tickets with magnetic stripes, paper/magnetic season tickets, and Freedom passes (technically a special sort of Oyster season ticket, I think).
If you're traveling with a paper/magnetic ticket, you're going to have to insert it into the mag reader and wait for it to spit it out before it opens the gates. Can't be swiped.
That, combined with the fact TfL already have a problem with revenue protection (some people jump gates), albeit not quite as bad as you'll see in most of Paris or Rome, means they're going to keep the gates closed by default.
Fare dodging in Tokyo is almost unthinkable. Social constructs mean they can do something at those gates few other cities of that size can get away with.
So why then are the EMV card readers so damn slow? Is it just a NFC vs FeliCa thing?
The Tokyo metro system also supports paper (mag stripe) tickets through the same fare gates. Those are also spit through the gate super fast.
On a failed read, the gates close nearly-instantly, I don't think they would actually aid in fare avoidance, you do see people run into them painfully when their card has too low balance.
I'm talking about the instance where somebody doesn't even scan: they just walk through. That is possible in some stations in London, and it's perhaps not a coincidence that's where the worst fare avoidance occurs.
Throughput depends on the people being ready.
In London the TfL gates (both train/underground) have a delay on closing, so it's possible for the next person's pass (whatever it is) to be scanned before the gates close. At busy times there are enough people already ready with their passes that the gates don't shut at all between scans and there is steady flow of people passing through. It only fails when someone faffs a bit too long with their pass/phone/watch/etc and you get a temporary stall.
Even approaching a closed gate it's possible, with a bit of practice and an outstretched arm, to walk through without having to break stride.
You do have to be careful of some people intentionally using an invalid card, resulting in the gates closing, and the person behind them letting them through with their subsequent scan whilst being left at the gate themselves (easily solved by then going to see one of the gate operatives and explaining the situation).
The things that aren't quite there yet, in terms of speed, are the QR codes being used for digital rail tickets, they have a separate optical reader (obviously) that doesn't work quickly/easily enough to walk through without breaking stride as you have to faff with a piece of paper or your phone rather than a simple NFC.
Their transit system relies on bog-standard bank-issued Visa / Mastercard payment cards, the kind most Polish people already have in their wallets. When you buy a ticket (usually at a ticket machine at the stop or in the vehicle itself), the machine temporarily remembers some of your card information. If a ticket inspector comes, you just tap your normal credit / debit card to their terminal, which queries the vehicle's systems somehow. It's basically the reverse of a storage-value system, they use a payment card for a kind of identification.
All transactions are performed offline, usually the next day. Tickets are cheap enough that fraud is not a big concern, and there's a system in place to blacklist cards that can't be credited. If you end up on that blacklist, you have to go to their website or office, enter your card number / tap your card and pay the missing amount.
If you're a resident and not a tourist, there's also a system of transit cards I believe.
Back in the day, paying with a credit card was a hassle. There was a machine that would take an imprint of your card and you would sign the imprint. There was no authorization.
Most places seemed to have 'swipe in the terminal' only by late 90s.
It was called a 'kerchunk machine', - which is a fun onomatopoeic - and the article does mention it.
I'd like to comment on this part, about actually writing on cards:
> you can create an account online and associate the card with your account, and then you can add value online. This is convenient, but confronts the offline nature of the system. You add value to the card, but there's no way to write the new value to it.
> The solution, or at least partial solution, to this problem looks something like this: fare payment terminals have to receive a streaming log of value-add operations so that they can apply them next they are presented with the relevant card.
I think that's why new systems often use NFC, since smartphones can do NFC this has the potential (because many NFC transit cards don't allow it yet) to actually charge cards from smartphones. In practice, none of the transit systems I regularly use allow it, and although it's in beta in Paris they only whitelist a handful of specific smartphone models so I can't do it either. But it's a possibility.
It could work the same with ISO 7816 smartcards if people just had card readers at home, but in practice here in Belgium where most people have such card readers (used to authenticate online with one's national ID card, although this is becoming less common now that there's a smartphone app for that), this has never been used for anything else basically.
And for some reason, smartcard companies seem to be totally unable to devise user-friendly interfaces. It's been more than 30 years now so you might think they have had the time to think about it, but... no. I wish there was just a web standard for that with a standard browser-provided UI.
Browser development is driven from the US. Smartcards development is driven from Europe. I expect that the same frictions that happens in deployment of smartcards for banking also happens in the browsers world.
Given how common US things are in Europe, I'm surprised there isn't more of a trading war over things like this. Personally, I think the EU should penalise foreign all social media companies, and fund local start-ups to replaces them.
I totally believe that the first two points reject 90% of international influence and standardization.
That US corporations are so focused on revenue / a large market that they are not influenced by government?
Or that the US market is so big international corps cannot complete (which is irrelevant in the context of my own comment).
But there's a bit of irony where, post 9/11, the US federal government decided they needed to really pick things up when it came to secure identity for federal employees and military personnel. So they developed and adopted the PIV standard now used for all federal credentials, which is a very soup-to-nuts smart-card based identity solution complete with PKI certificates and offline biometric authentication. The problem is that smart card technology, clearly the way to achieve this, hadn't taken off in the US, so they ended up having to buy pretty much the whole solution from France. Not that big of a deal in practice as Thales is a major defense contractor to the US anyway, but sort of a disappointment considering all the interest in keeping a strong domestic military technology capability.
One wonders where the NSA was during this process, but the NSA has a tendency to both overengineer things to a degree that widespread use is infeasible, and keep things secret to a degree that widespread use is undesirable. So the more homegrown solutions to similar problems, things like the Fortezza cards, were complete nonstarters as a widespread solution to identifying federal personnel. So we have one of the factors here in the United States general lag in adoption of identity technology compared to other, especially European, countries.
In my city's implementation the offline-ness of the system is very apparent. If you add value to your card online, you have to come to a subway station to stick the card into a reader to have your new balance written. The turnstiles at the same station don't do that either despite definitely having a network connection, you have to specifically use the balance-checking or ticket-selling machines.
The only application I've seen that isn't transit is at arcades. You'd buy a "member" card that you'd put money into. Each machine would have some sort of terminal where you tap or swipe that card to add credits to the game. But then I'm not quite sure if these systems are offline or these terminals are connected into a network.
I think they were magnetic or magneto-optical?
Over the past 20 years, I've used mobile cellular telephones that take mini-SIM, micro-SIM, and nano-SIM. I didn't get to experience the full-size SIM card, but learned about this obscure fact from online photos and museums. Example: https://twitter.com/phone_museum/status/1287310071907713024
> Why is it that SVCs gained so little traction for payments in the US?
Another obscure point is that during the Bitcoin craze of the mid-2010s, the Canadian government tried to pitch MintChip as a competitor. It fizzled out and went nowhere. https://en.wikipedia.org/wiki/MintChip
> Offline systems simplify payment networks in some ways, but also add complexity, which is often apparent in transit systems that combine offline terminals (for example in buses) and online terminals (for example at train platforms). [...] If you add value to a card with a zero (or near zero) value and then try to board a bus, it is likely that you will be rejected: the value-add hasn't been written to the card yet, and the bus terminal hasn't been told about it. The transit operator often sets an expectation of one business day for online value adds to be available if your first trip is an offline terminal If you add value to a card with a zero (or near zero) value and then try to board a bus, it is likely that you will be rejected: the value-add hasn't been written to the card yet, and the bus terminal hasn't been told about it.
This perfectly describes the situation in Toronto/Ontario with PRESTO, adding value, and tapping on buses.
> Of course you can see the problems with this scheme: couldn't anyone just write a bigger number to the card?
In my college days we had a vending machine which worked with a NFC card.
I bough a NFC reader/writer, and quickly found out that the amount of money was exactly as described above. After a couple of tries I found out that the maximum amount of money was 22€. Free snacks for a couple of years until they changed the machine to accept only cash.
No, I'm not ashamed.
EDIT: The cards were anonymous, even if the machine somehow tracked the card use (I have no idea if they did), there was not way to trace it back to a person
I have fond memories as a young teenager topping up the card at my bank ATM (just transferring money from my current account to the proton bit of my debit card) and buying my weekly & monthly computer magazines at the local newsagent. I'm surprised it survived until late 2014, a nearly 20 year long run.
Like others also already mentioned, we also had a system like this 30 years ago for vending machines and cafeteria in a large corp.
Banks want tracking (for customer profiling). Governments wants tracking (for anti-terrorism and anti-money-laundering). So it won't happen.
But I suspect that your reasoning is correct nonetheless.
I mean. It’s already happened. Thanks to some clever non-intuitive use of escrow contracts one can create fungible cash-like electronic money for offline transactions.
I think I even feel the same dynamic with something as banal and informal as home automation. With some kind of computer (eg microcontroller) at every node I certainly could keep the local control local. Or I could just focus on publishing data to the "network" [1] and getting commands back, and making the interface a given device exports as simple as possible.
We see the results of this harsh dynamic for platforms that allow for hub-less control (eg Zwave I think). Nifty and more robust, but it adds to the bespokeness and siloing/lock-in. It's just so much more complexity that then has to be configured, and then grokked to know what the system will actually do. Whereas backhaul state and control to a general purpose Linux machine running python and you can do "whatever you want" (modulo that singular machine having a problem).
Not a great dynamic for those of us that like freedom.
[0] or really any entity, corporations and governments can just fulfill the imperative at scale
[1] full extrapolation in the corporate context - "cloud"
Now some stores are starting to add special fees for Credit Card use, which the Banks are trying to eliminate these fees via the US Congress. They know as well as I do, if stores start charging fees for Credit Card use, many people would jump right back to cash. This would decrease their profits.
https://www.statista.com/statistics/191235/reported-robbery-...
Wikipedia has a similar table somewhere, but the Statista link is easier to find on mobile.
The product is still mentioned in a couple of articles...
https://www.afr.com/companies/smartcards-offer-a-world-of-op... https://www.finextra.com/newsarticle/3534/first-data-selects...
It had a chip with the ubiquitous brass contacts almost any card has today.
My uncle had participated in the patent filings for some of the tech, years earlier, for his employer. He had explained to me, already in the 80s, how this would be the future of carrying money around.
It never took off. My personal take is that it was simply an oversight in UX.
There was no way to check the balance on the chip without going to an ATM.
Furthermore only some ATMs of some banks carried the hardware/software to do so. I also don't recall if you could even check your balance if the ATM belonged to another bank.
Also paying by card was far from common in Germany then so few shops carried the readers. It was mostly only big supermarkets and department stores.
I.e. it was double inconvenient compared to cash.
And Germany being a safe country, the added security in case of theft didn't help. It was also a minor factor since a thieve that would steel your purse would simply throw the card away. The money would be gone either way.
The first time I used that feature, I instinctively thought that by adding my clipper card to my smartphone, my smartphone merely has another manifestation of the same clipper card as the original plastic card, much like a credit card but with a special device-specific card number, or like a Unix hard link. Of course I was wrong. The actual card itself was transferred.
NETS has been slowly transitioning from a contact based card (similar to a SIM card) to a NFC/RFID contactless card. Some car parks do NOT accept the new type contactless card which means that you really need to have both flavors of NETS cards when driving.
There were startups focused on smart cards in the 90s: https://www.nytimes.com/2000/03/24/business/publicard-busine...
It used to be simple:
- buyer hands the money to the merchant.
- merchant verifies monetary value. If monetary value is valid then merchant gives buyer the item. Otherwise, tells them to piss off/get bent.
- buyer walks away with item
But major credit/debit card processors (visa, mc, amex) had to insert their hands into the pockets of every buyer and merchant to get their 3-5% cut on each transaction.
Now it’s a much more complicated process that happens more “seamlessly”:
- buyer presents debit or credit card
- merchant checks if debit or credit card is accepted by their payment processor —> if not accepted, tell buyer present diff card or “get bent”
- merchant swipes/taps/keys-in card information and attempts to process the transaction. A decision is typically reached within less than <1 second —> if declined, try again. If further declined, tell buyer card declined. Buyer insists it’s good and to run it again. Merchant runs it again, it’s successfully processed (wtf?). If not, tell buyer to get bent.
- buyer walks away with the item
In the background, in order to accept debit and credit cards the merchant had to sign a deal with the devil and pick one of the many payment processors. Merchant could have gone with his bank’s processor but turns out the merchant doesn’t have the right paperwork or lacks the revenue to qualify for a “premium” account. So the merchant looks elsewhere and finds a promising payment processor elsewhere but fails to read the fine print. In addition to the 3-5% fee charged by the major CC networks, the processor will take a 5 cent transaction fee to process, in addition to a 1 cent “inter network” processing fee. ALSO, the “free” equipment that’s provided to your business has a $50 month maintenance fee in perpetuity. On the flip side, if you transact 100K per month, they will cut the transaction fees by 25%, oh how generous!
Oh did I forget to mention that some cards have “premium” fees? So if a buyer presents a “black card”, the merchant is then charged by the bank issuing the card another fee. Sometimes it’s included in the payment processing terms but this is YMMV. So as a consumer, if you ever wonder why the small business takes “visa” but not your “chase ultra sapphire pearl max black” card with visa logo. That’s why.
Unfortunately, it doesn’t end there.
(2 days later) buyer that bought that item actually stole/cloned the credit card and the actual credit card owner initiated a dispute.
Merchant has now been charged a $25 dispute fee and is now in the resolution process. If bank and/or credit card processor rules in consumers favor, merchant loses $25 in addition to the cost of the item(s).
At the end of the day, merchants get fucked. Merchants pass on costs to consumers/buyers. Buyers get fucked with increased cost of goods.
Only winners are the useless middlemen.
This is america, in France (and more generally in Europe) all credit / payments cards are standardized thru governmental intervention. Vendors are allowed to say cash only and refuse cards in general but this is getting real rare. In some countries (Norway), you can have a real hard time paying cash in big cities, vendors refuse it.
I'm not running "classic" retail, just stalls at school events. The cost of cash is the cost of my time and that of other volunteers making sure we know how much cash we brought in, and getting to the bank. It's absolutely worth 1.69% to avoid having to deal with cash. And that's even before worrying about having a float to make change with.
The cost of cash handling is part of what has allowed card payments to proliferate, but then that created the conditions for card processors to ratchet up fees.