We had stored value card payment system in Uzbekistan somewhere from 2003-2005 to 2010-2012. But no-one ever called it "stored value card", basically, I learnt the word today :) Everyone just called it "offline cards", in contrast with "online cards" which required Internet to do transactions.
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.
Which is similar to T-Money in South Korea, Octopus in Hong Kong, and later Suica in Japan. All of which if I remember correctly came before 2000.
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.
I don't know about Europe, but in the US, offline payments with regular credit cards are/were a thing.
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.
We sort of have two forces pushing in opposite directions:
* 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.
The Octopus is the de facto transport pass in Hong Kong (well, it's started by the major transport companies) and commonly used in many shops, it's also used by some for building access.
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.
> 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.
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.
We used to have a popular system like that in the Netherlands (which I totally forgot about until reading GP) called Chipknip ('knip' being Dutch for 'wallet'). The system was eventually discontinued in favor of contactless debit cards, though.
In the early 90s I lived in Guelph, Canada. We were one of a couple of pilot cities for Mondex, a stored value card system that I think was owned by MasterCard. The city got a bunch of funding to get Mondex working everywhere from parking meters to buses, payphones, and of course private businesses. Everyone who wanted one was sent a Mondex card and a portable card reader which looked like a small calculator. You could put your card in it and press your thumb on a button to make the display show your balance. That little device allowed you to transfer money between cards if I recall, but I never figured out how. You could also see your past transactions and set a card PIN.
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.
In the mid 90's in Canada we had similar cards, but they were only for pay phones. Before cell phones became cheap, parents would buy these pre-loaded cards for their tweens and teens so they could call for a ride when they were done at the mall or whatever.
Personally, I did the collect call thing to my parents, especially after the system was automated.
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.
There was also a "ewallet" card in France when I was a teenager, but it was mostly targeted at children and senior. Now I'm wondering if it was a true offline card or not.
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.
I'm surprised we don't have something like this in the U.S. Just last week I was withdrawing cash from an ATM because I was worried the power would be out for a few days and my debit card wouldn't work.
Almost-ubiquitous, almost-free network connectivity can be a curse when it comes to the development of resilient systems.
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/
That's interesting. In Russia, cards didn't really catch up for a long time, but once they did, they were online cards with GSM-enabled card terminals.
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.
> I wonder what caused the adoption of UzKart compared with plain old cash.
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.
Reminds me of minutes loading of SIMs in Philippines in the early 2000s... Loading was available every single tiny soda stand to bodega to major shopping - they were Uzbek-quitous :-)
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...
In more recent times, we had to think about this problem in Indian market context. I saw this problem as online vs offline payments problem.
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.
The real solution is to let the receiver of the money have a "verify" button which will, if connected to the internet, contact a central server and check that no double-spends etc. have happened. Up until verification is done, the money shows as "provisional" in your account - but you can still spend it. Only one person in the chain needs to verify for the whole chain to become permanent.
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.
I get the idea, but I think this is a terrible UX. People shouldn’t have to worry about whether they have real money or not. Either the system is secure or it isn’t.
> because a user has to be allowed to log into a new device (if they lose their old one)
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.
> Up until verification is done, the money shows as "provisional" in your account - but you can still spend it.
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.
> Then, when does reconciliation happen? When either party goes online?
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.
:-) that assumes cash is trivial. It is not for so many reasons. Cash is bulky and discrete. Cash is visible and easily snatched/coerced from you.
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.
>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.
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, 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
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.
Please don't scorch me HN, this isn't an endorsement, just a question for thought -- but isn't this one of the things Lightning is sort of meant to solve?
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.
>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.
Wow this discussion unlocked a long-lost memory: the Swedish "cash card" - a stored value card where you'd use a terminal to load money off your bank account onto the stored value card and then use it in participating stores. If you lost the card you lost the money. The fees to merchants were too high so it never gained any adoption, it looks like it only was available from 1997-2004. The Wikipedia references a German version, Geldkarte, which apparently had a renaissance when it could double as proof of age for tobacco vending machines...
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
As others have said, EMV doesn't have to phone home, and London's TfL system often doesn't straight away because they might not even have a connection (my bus this morning definitely didn't). It's also not charging the payment immediately, because the charge is unknown at that point - you might not know until the end of the day or week what the charge is, because travel rates are capped and dependent on the zones you're traveling in.
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.
Interesting. So there's no verification of the card validity at all? I assumed at least they took an auth hold like gas stations do. If I call and get my card blocked I can use that now-invalid card and ride for free?
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.
> Vs EMV-based systems like London where you have to stop and wait for the card reader
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.
The wonderfull Cash-chip was embedded into Visa debit card issued by the bank. It also had "Valid in Sweden only" printed beside it, on an othervise internationally recognized debit-card.
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.
Germany: Geldkarte (German: "money card") is a stored-value card or electronic cash system used in Germany. It operates as an offline smart card for small payment at things like vending machines and to pay for public transport or parking tickets. The card is pre-paid and funds are loaded onto the card using ATMs or dedicated charging machines. The system will be abandoned from 2024.
The similar Austrian system was called 'Quick' and has been defunct for a few years now. I only ever used it for vending machines, mostly cigarettes
https://de.wikipedia.org/wiki/Quick_(Geldkarte)
It depends on both issuer, acquirer and the particular merchant. Second step of the EMV transaction (after the terminal verifies that the card was issued by known issuer) involves the card and terminal comparing their authentication and authorization policies, which might very well result in no-op being acceptable to both. The system is not designed to be secure against fraud, but to assign liability for the fraud to particular party in cryptographically verifiable way. So as a merchant (think public transport) you can very well accept cards offline without any kind of CHV step, but the possible fraud is your problem.
I kind of like the solution adopted by the Polish city of Wrocław (and many others, but Wrocław is the one I'm personally familiar with.)
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.
Am I the only one here that remembers credit cards before they used any sort of online processing?
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.
I worked a retail mall job in the early 90s. We had a computer/POS system that had a built-in swiper for credit cards. You'd swipe, hit a key, then listen to it dial out, connect, beep, etc. A CC payment took minimum 30 seconds, usually closer to a minute. December was always a huge slowdown for cc payments. Occasionally we'd pull out the imprint machine and do a few of those, and... for some reason, I seem to remember we had to use it for amex or diners club or discover or some other 'non-traditional' card, but those were a rarity - I think I may have done 2 or 3 of those a year.
Most places seemed to have 'swipe in the terminal' only by late 90s.
I used to be the one running those cards through the machine! We actually would call someone (credit card processor?) to give them the details and we'd get an auth code back that we wrote down.
I worked in a gas station taking credit cards w/ an imprint machine. We had a book, updated monthly, of card numbers to decline. That was in 1990. By 1994 we were calling a toll free number and reading (part of?) the account number for authorization.
I’m curious to know when exactly that practice ended in Western Europe and North America. As a millennial, the only time I ever encountered it was in 2008 in an outdoor shop in Thamel, Kathmandu’s backpacker ghetto. The owners said that they could not accept my Visa Electron card (standard European debit card) because it was not a real credit card, and they showed me the machine they used to take imprints of real credit cards. Of course, this was all gone by my next visit to Nepal a couple of years later.
I remember doing the authorisation by phoning up a Streamline who would give you an authorisation code to put on the credit card form. I worked for Electronics Boutique and we couldn't give the games out without the code
I'm of that vintage of credit card user that remembers this. I used to keep my counterfoils (I think that's what they were called) to reconcile what was remaining on my available credit. I seem to remember there was a printed list of that some merchants used to look up invalidated cards before electronic terminals replaced mechanical card swipe machines.
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.
I've just used this in Malaysia, they have a card called Touch n Go that is very widely accepted.
You can load up the card using cash terminals or via a smartphone app with NFC, you can use that to check the balance as well
> 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.
Charging the Paris transit card (Île-de-France Mobilités) via NFC is out of beta for at least one year now. Much convenient to bypass queues at the start of each month.
My grandfather was at the head of a French company that pioneered the smart card for banking use. They started with the payphone, continued with the Vitale card (public health system card), then did the credit card. He told me stories of him going in many countries to sell the tech and concept, and this article nails it: this is a French thing, so the US did not want it. They did not want it so badly that magstripe is still commonplace. Its quite nice to listen to him about the beginnings of computing, the notion of "datacenter", etc.
> this is a French thing, so the US did not want it
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 spent a few years with a Mondex card[1] (I assume Exeter university was one of the test locations?) and it was vaguely useful: most places on campus accepted it so you could use it to pay for a pint, print or photocopy, or buy course books. Looking through the list of what it could do though it seems it was pretty underutilized. In the test location I was in you couldn’t transfer funds to another person or use multiple currencies, and I don’t remember any personal readers.
Readit News
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...
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.
* 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.
Deleted Comment
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.
https://i.imgur.com/aD6ihh8.jpg
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.
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.
[0] https://fr.wikipedia.org/wiki/Moneo
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/
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.
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.
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.
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.
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.
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.
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
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.
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.
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
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.
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.
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.
https://en.wikipedia.org/wiki/Geldkarte
Deleted Comment
Deleted Comment
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.
[1] https://en.wikipedia.org/wiki/Mondex