The card has a variety of risk counters on it that allow it to securely decide whether an offline transaction can proceed, at least some of which are also exposed to the terminal which can have its own separate policy. I imagine internally the banks and payment gateways have a huge variety of internal related tuneables.

Your experiences in the UK are almost certainly linked to the card issuer you were using (was it a Monzo card by any chance), and nothing to do with it being the UK. The vast majority of the legacy banks have always used offline transactions for contactless.

However there has been a bit of shift towards online transactions, driven by EU rules likes strong customer authentication, which requires regular pin entries determined by cumulative spending and duration limits (which ever is hit first). It’s a lot easier to reliably meet the requirements of SCA using online transactions.

As for how offline transactions work. It’s reasonable simply. The terminal asks the card to sign the transaction using the cards private key. Now there is an extremely complicated set of rules around how liability shifts in the event of a fraud claim, depending on many factors like the type of transaction, if a pin was entered and validated by the card, if the card ask to go online and the terminal ignored the request, they type of merchant, the exact region your in etc etc.

But regardless of all that nonsense. The technical process is very simple. The terminal has the transaction cryptographically signed using symmetric encryption with a private key that is only known to the card and the issuer of the card. That signed transaction can later be presented to the issuer so the merchant gets paid.

Given it’s a symmetric key, you may wonder what happens in the event of a dispute between the issuer and the merchant, where the issuer claims they received a forged transaction. To which the answer is, the issuer sends a signed and sealed letter to card network operator saying they have double checked the transaction signature, and believe it to be forged. And if anyone doesn’t believe them, they can sue em (this is not at all a joke, it’s literally the documented and contractual process used by the major banks and card networks).

Not just a bit of a shift: Offline-preferred transactions are basically a thing of the past. EU rules have nothing to do with it (offline EMV is fully SCA compliant as well, as the chip can keep count, although it's a bit annoying to keep counters in sync if there's more than one); it's mostly for risk management and simplification reasons, I believe.

> The terminal has the transaction cryptographically signed using symmetric encryption with a private key

Offline transactions essentially always require card authentication as well, which requires asymmetric cryptography. (Otherwise, you could trivially forge valid-looking cards and offline terminals would be none the wise since they obviously don't hold the symmetric keys for every card issued; that would be way too risky).

EU rules have everything to do with it. Meeting EMV with offline counters is tricky to get right. The reason I can confidently claim the SCA drove the migration of online transactions is because I was responsible for the technical implementation of SCA for a bank, and was part of the industry wide conversations that happened as banks figured out who they would comply with the rules, and tried to figure out what wiggle room existed. So I know SCA was a driver, because I talked to the people making this decisions.

> which requires asymmetric cryptography. (Otherwise, you could trivially forge valid-looking cards and offline terminals would be none the wise since they obviously don't hold the symmetric keys for every card issued; that would be way too risky).

This is where you are simply wrong. Again speaking as someone with actual experience working on this stuff, and having dealt with actual forged offline transactions as well. I can tell you the card uses symmetric encryption, the terminals themselves have zero ability to validate the signature a card produces. The terminals include some data that allows them to validate if a card number is routable, and also a hot list of card numbers to always reject, and thus reject transactions that can never be fulfilled, but they have no way of validating that a specific card or transaction hasn’t been forged.

The entire system depends on the physical security of the chips in cards to make key extraction extremely hard, and to also make the correct mimicking of cards extremely hard. But it’s hardly impossible, and there’s plenty of demonstrated EMV attacks out there in the wild. It’s just that they all hard to replicate, require special equipment, and generally make you look very dodge in the moment because you have to have a weird card with wires running your shelves so you can intercept the card comms. The manufacturer and distribution of the chips in cards is extremely tightly controlled, so you can’t just buy them. In theory anyone with a million dollars and ASIC contract could manufacture their own ICs, but there simply easier ways to steal money.

Ultimately EMV only needs provide enough security to make other methods of stealing more palatable. Cards are used for pretty low value transactions, so breaking EMV isn’t a very scalable way to steal money. You would be better off stealing products from merchants using decent pair of running shoes, rather than creating crazy ways to trick their payment terminals. Running shoes are cheaper and much more accessible than ASIC production.

Ok, "nothing to do with it" was too strong: I don't doubt that SCA was the death knell for many offline implementations. However, I've seen online-only cards in the field by many banks well before SCA became effective.

And on the other hand, I also know SCA-compliant EMV implementations that do still support offline transactions. As you say it's tricky, but it's possible. Europe is large, and you probably haven't talked to every single bank/processor :)

> This is where you are simply wrong. Again speaking as someone with actual experience working on this stuff, [...] they have no way of validating that a specific card or transaction hasn’t been forged.

Huh? If you have worked on this stuff, surely DDA and CDA ring a bell? They're both based on asymmetric cryptography, and they absolutely allow the terminal to dynamically verify whether a given card is authentic or cloned, without having to go online.

Without that, you could indeed copy the static signature data from any EMV card and replay it to an offline terminal and get away with it. That's why SDA has long been deprecated for offline transactions.

> The manufacturer and distribution of the chips in cards is extremely tightly controlled, so you can’t just buy them. [...] In theory anyone with a million dollars and ASIC contract could manufacture their own ICs

You can absolutely get them on Aliexpress straight from the manufacturer for a few bucks each, cheaper in bulk. They run Java, so you can just write your own software – the EMV specs are public!

What you can't get there is the cryptographic private key specific to the card number that the issuing bank embeds into it at personalization time.

EMV is a cryptographically sound (if dated and very complex) scheme, and secrecy of implementation is actually much less of a security factor than you seem to claim, despite the industry's (largely historical) obsession with secrecy.

Yes I was a little wrong here. My most recent experience in this area is dealing with messages on the issuer side. It’s been a while since I’ve done anything serious at the card config level, and don’t have a huge amount of experience with the handshakes that occur between card and terminal.

The missing nuance is that the transaction cryptogram is symmetrical encrypted, and that’s the only cryptographic blob sent over the card network to the issuer. As the asymmetric stuff only happens locally between card and terminal, and isn’t included in any data transmitted from terminal to issuer.

So the terminal can check that the card is a real card using asymmetric encryption, and that the produced transaction cryptogram was produced by that card. But none of that evidence is passed on to the issuer, only the symmetric cryptogram, which can’t be used for non-repudiation is sent to the issuer later.

Hence the experience dealing with forged transaction cryptograms, which were forged by an acquirer in a systematic manner to try and gain stronger chargeback protection because their sloppy transaction processing resulted in them processing a lot of fraudulent transactions, and then being hit with a lot of chargebacks. The process of “proving” to the network that this acquirer was forging cryptograms was sending a letter signed by legal team attesting to fact we had evidence of forgery, plus a much nastier letter sent to the acquirer in question to knock it off, and stop doing obviously illegal things. Ultimately it’s the acquirers legal counsel that acts as the enforcement mechanism here, and the obvious threat of lawsuit they’re clearly can’t win tends to be a very strong motivator for companies to tidy up their act.

> EMV is a cryptographically sound (if dated and very complex) scheme, and secrecy of implementation is actually much less of a security factor than you seem to claim, despite the industry's (largely historical) obsession with secrecy.

I may have overstated it a little. Bad habits from spending too much time dealing with PCI rubbish. The difficult thing to get across in these threads about payment networks is how much of the systems “security” really comes from clever legal contracts, and smart distribution of liability and risk. Effectively making in everyone’s interests to not do anything really silly, but the actual technical security is almost secondary to legal mechanisms that exist to ensure that participants are highly motivated to make sure that fraudulent transactions are kept to a minimum.

There are other ways too to stop "sloppy terminal processing", but as far as I understand they're not cryptographically secure in a way that would provide an unambiguous and third-party verifiable protocol trace.

I suspect that all of that is a big reason why the networks don't love offline processing if it can be avoided.

And I couldn't agree more to your last paragraph – the industry does have an unfortunate history of propping up questionable security engineering with legal threats. But I'm slightly more optimistic on EMV, at least some implementations: Decades later, we can actually have some nice things :)

Also, thanks for the anecdote! Helped me confirm a theory I had on the motivation for a particular obscure protocol feature that I have so far not found solidly explained anywhere in the literature.

No, not even that. Remember that transaction settlement is based only on what’s actually sent over the network. All kinds of stuff can happen between the terminal and card, but if that info isn’t actually sent over the network, it may as well not exist (from a settlement perspective).

So we have no reason to believe that CDA wasn’t performed. Instead we had a network participant effectively mutating presentment messages so they no longer matched the cryptogram produced by the card. We already knew the presentment were mutated because they indicated our card were approving transactions offline that they were configure not to approve. But during the dispute process, we had the acquirer claim that they had valid cryptograms, so we had no right to chargeback. In turn we actually had to go and start decryption cryptograms, and as we expected, the decrypted cryptograms didn’t match the transactions they had been sent with. The transaction amounts didn’t match up.

The sloppy processing was a little more complicated, and was a bit more complex than just badly configured terminals. The types of transactions in question where fairly complex multi-step transactions, that to process correctly required properly supporting some of the slightly more niche network features by both issuers and acquirers. Due to a lack of proper support by many issuer (although we had proper support), the acquirer took some shortcuts to reduce customer complaints, but drastically increasing their own risk exposure. Unfortunately for them an OCG had figured out they could exploit this nuance.

I doubt the OCG had any understanding of the underlying transaction mechanisms. They had just figured out if they followed a specific set of steps, they got free money (or something trivially easy to covert into money).

But to deal with the losses the acquirer was seeing. Some bright spark over there decided they would start forging network messages to try and cover their losses, and shift them onto us. Unfortunately for them, we were more technically competent than most issuers, and more importantly, really couldn’t afford to take the losses.

> I suspect that all of that is a big reason why the networks don't love offline processing if it can be avoided.

Nah the networks don’t care. They get paid regardless, and they’re never on the hook for any losses that might appear. But certainly offline transactions carry a lot of additional risks for issuers (notably it’s impossible to ensure funds will exist to cover any offline payments that might have happened), which are easily mitigated by simply configuring your cards to always go online, and thus shifting the liability on to the merchant if stuff goes wrong.

> And I couldn't agree more to your last paragraph – the industry does have an unfortunate history of propping up questionable security engineering with legal threats. But I'm slightly more optimistic on EMV, at least some implementations: Decades later, we can actually have some nice things :)

Eh, ultimately everything in this world boils down to who has the larger capacity for violence, regardless of what may be correct. Thankfully in most countries we’ve replaced violence with government, police and courts. So now it’s more a question of who has the larger capacity to hire lawyers.

Even if the technical layer supported non-repudiation, I doubt it would make much difference in a court of law. It’s extra evidence for sure, but ultimately most of these things are resolved via settlement based on what makes the most financial sense for the parties involved, which includes many more factors than just the state of the transactions are the heart of such a dispute.

The offline card was from a current account with an overdraft and also worked as a cheque guarantee card, for cheques up to £250 under the (discontinued ~2011) cheque guarantee scheme[0] and had a special hologram on the back. The retailer would watch you sign the cheque and write details about you, the card and any CCTV etc. on the back of the cheque. I imagine the offline behavior of the card was similar, and was a carry over from that.

The online card was from a basic account with no overdraft facility and acted a bit like a prepaid debit card.

[0] https://en.wikipedia.org/wiki/Cheque_guarantee_card

When offline contactless payments first emerged in the U.K., there was a significant spike in unplanned overdraft usage and disputed transactions, as people rapidly realised it essentially worked as a free line of credit, up to £100 or £250 depending on your issuer.

This quite quickly caused issuers to push up prices on offline transactions, which made them less appealing to merchants - add to that that people were talking about them being a hotbed of fraud, and merchants err away from offering them, PCNs start dropping the capability due to lack of demand, and here we are today.

Auth before capture doesn’t generally reduce interchange. What it primarily does is shift liability in the event of a dispute. If a chargeback is raised, and no auth happened, then the merchant simply looses immediately. They have no mechanism for fighting the chargeback. If they auth first, and got an approval, then it’s the banks problem in the event of a customer dispute. The merchant can reply to the chargeback by pointing out the valid auth they received from the bank, and the bank has to go pound sand.

You may see this as different “interchange” rates from a specific gateway. But that’s simply not true at the network level. The difference in pricing just exists so the gateways themselves can price in the additional risk associated with auth less captures, given the gateways are always on the hook, even if a merchant goes bust. The major networks force gateways to have funds kept in escrow that are guaranteed to cover any shortfall that might occur due to individual merchant failure, or failure of the gateway itself. That how networks make sure that zero real risk every accrues with them, they make everyone else put up huge stacks of cash to ensure that every virtual cent that’s in flight at any moment, is backed by a real cent in escrow somewhere.

Plus you need to analyse how the different messages types and sequence of messages interact with the transaction processing rules, which are also hundreds of pages long.

Suffice to say, the entire system is insanely complicated, and just about everyone out there implements it all incorrectly, with the whole system on working because partners are only allowed to complain about the insanity if they actually loose money. Until that point they’re expected to just handle everything as best they can.

I find that super annoying, as it's bitten me more than once in the past when I used the wrong card for a given order without instant feedback.

Instead they effectively make all the parties that connect to the network responsible for rule enforcement. If a merchant follows all the rules correctly then they receive extremely strong chargeback protection, I.e. if an issuer sends a chargeback, and the merchant has plenty of grounds to dispute the chargeback and win.

If merchants don’t follow all the rules, then issuers can send chargebacks, and it’s much harder for the merchants to defend themselves.

In all scenarios it up to the issuers and merchants to explain in the chargeback what rules have been broken, by which party, and thus who should win based on network transaction rules. The networks themselves don’t even make a ruling directly, instead the issuer and merchant decide who wins via a back and forth process that includes escalating fees paid to each other, until one side gives up. The networks only get involved the two sides can’t resolve the issue themselves, and will charge the looser a significant fee for the privilege, so there’s a strong incentive for the parties to resolve the issue themselves.

How does of this interact with 2FA, auths etc etc. Basically 2FA, and ordinary auths are all just things a merchant can do, or trigger, to reduce their liability and get better chargeback protection. If the merchant performed a full 3DS auth, where the issuer is asked to perform 2FA, then they have pretty complete chargeback protection in the event of fraud, because they’ve basically asked issuer to make absolutely 100% that this transaction has been approved by the issuer’s customer, so there’s zero grounds later to claim that a stolen card was used or something similar. If the issuer’s customer wants to dispute the transaction, that’s the issuers problem.

But all of these mechanisms reduce checkout rates, and thus merchant revenue. As a result some extremely large merchants make a trade off of basically accepting all the risk of fraudulent transactions, and give up chargeback protection, but not following all the rules. The merchant does this because they’ve basically asked believe they have enough data to prevent fraudulent transactions, without using any of the tools the card networks provide.

For merchants that can do this (like Amazon), they build in-house fraud detection systems, and payment systems that evaluate the risk of each transaction, then change the exact way they perform the transaction to either reduce friction (because the transaction is very low risk) or increase friction (because the transaction is higher risk), thus allowing them to capture more revenue, without taking on more risk (because they have confidence their ability to detect fraud, and thus don’t need help from the issuers).

But there are very few merchants that can even do this, as it generally requires either a very collaborative payment gateway (who are ultimately on the hook for merchant misbehaviour), or a direct connection to the card networks (who aren’t interested in talking to people not moving millions of dollars every day). Which is why it tends to pretty rare.

The API call is labelled "sale", but it performs an auth and at the end of the day the system still generates a capture or settlement-style message.

If the gateway allows you to complete a sale request at 7am that doesn’t start an auth until 9pm, you have an offline payment by any other name.

If you’ve already tokenized the card on a gateway for a particular merchant, for example, they may allow you to keep pushing multiple charges while on their end still using the original network auth from the first tokenization - which ends up being entirely opaque to you, the client of the gateway.

Essentially you don’t have to care what the card network rules are, just how your gateway presents functionality to you.

For various reasons, they're mostly used in closed-loop systems these days (think laundromats, transit systems etc.), but historically there were open-loop deployments in many European countries, and in some countries, stored-value POS payments are still very popular, e.g. in Japan.

It's a real shame that the entire world moved to online-only. Sure, it's much easier and there's less opportunity for various kinds of fraud as a result, but in terms of availability during outages or cyber attacks, it was a big unforced step backwards.

Indeed, there used to be things like "Moneo". The problem is that banks never trusted really these systems, so you were limited to, say, 50E of stored value. Also for some reason in Europe the readers of such cards have never been great, I guess because most devices were built on the cheap, so even if the transaction is offline and supposedly fast, you would have to wiggle your cards all around most readers for 2s until it's picked up.

In Hong Kong there is the Octopus card, which started as a closed loop subway card, but ended up being so loved that now you can pay litterally anything with it. It can store up to $500, and you can set it up to automatically top-up to $500 more per day linked to your bank account. Also accepting payments from octopus cards is very easy, you don't need a physical device and small businesses can just have the customer card tapped on their phone with a merchant app.

There were single-use chip cards that you bought and kept in your wallet. Plain eeprom.

I remember I built a reader for them as a teenager...

Stored-value payment cards usually contain at least a secret key and some logic that allows them to establish a secure channel to another trusted entity, such as a merchant smartcard (which can be embedded in a terminal) or a backend server (and a corresponding HSM).

It also wouldn't work as you describe, as the terminal at the point of entry doesn't know how much to charge you since it doesn't know where your journey ends.

Actual chipcards don't bill you at the end of the month either -- they reload a fixed amount through direct debit (which takes a few days) the moment your balance crosses zero. If the direct debit isn't setup for a card (because it's not a personalized card) or the debit was rejected, the card is blocked.

For business chipcards cards it works somewhat the way you described.

I'm not trying to find a gotcha, but wonder how that works with paying by phone nfc and then by card?

Here,

https://en.m.wikipedia.org/wiki/Credit_card_imprinter

Calling a call centre to verify every transaction is too expensive so only purchases over certain limits came in following BofA/Visa - and that stated that way till the late eighties when larger stores started using back office to talk to Visa network etc. but even so the ability to do live updates and verification was too much and there were weird cacheing tricks

So banks could easily approve or be liable for transactions they would prefer not to approve - so they only gave credit to the rich at first, and then to those who paid back regularly. This info was shared and became credit reference agencies - because the credit card companies shared it initially like casinos but the abuse and mistakes brought legislation

I think what i am saying is our consumer credit culture was not designed, it just grew.

I last used a carbon credit card in the early 00s. Electronic swipe and sign for a credit card had gone pretty much everywhere I went except the US by about 2010

I am not sure how valid it was, though they would take a deposit and a card imprint until we got the car accessories back.

It put all the transaction risk onto the employer, and had a high fee per-use, but since they only had these 'stock clearance' sales to employees once a year it was fine.

IIRC, the merchant gets paid if hitting a credit limit or similar decline reason. The card holder then gets hit with a financial penalty (usurious interest rates, or extra charges). If the card has been stolen, it ends up in a big phonebook-like book for offline use (otherwise the merchant just called it in for big purchases).

If you mean chargebacks: I believe imprinters had card issuer liability for the longest time, at least as long as the transaction was under the (network-defined) "floor limit".

So if these were relatively low value transactions, the bank would simply not have any standing to decline payment.

If you had any interest in any topic you read about on the web or in a book, that was the only way to get things even if you had the money otherwise.

Btw, what typography magazine was it?

In the backlog of my things to do is a best-of compilation of articles from the published (and one planned but unpublished) issues.

Gave me a bit of a surprise when he cashed in the paper copy two years later and I hadn't been to Australia since...

I think there was a limit of something like 60 days. At least my bank apparently refused all transactions that were settled too late.

I had a job which involved a lot of taxi trips, and when I cross checked 30% of the trips where never charged my account. I suppose they just filled up the glove box with old slips until they couldn't shut it. Hotels never failed.

And I guess if one has never seen these, I need to explain. In order to leave an impression on the carbon paper (I should probably explain that, too, huh?), a fair amount of pressure was needed (those old card imprinters didn’t require a gym membership, but a child could not operate one). That rolling pressure would eventually wear on the surface of the card, and turn the numbers white when the outer layer wore through.

In the past embossed credit and debit cards were both accepted on planes. That's why they were embossed in the first place: for offline processing which in even more distant path was the only option. Later CC machines and offline chip/stripe transactions co-existed with online transactions.

Normally (at least in Europe) you couldn't get an embossed card, even a debit one, without proving your credit worthiness. The possibility of offline transactions assumes overdraft — the same as with check books.

When online transactions appeared, banks started to issue Visa Electron and Maestro cards which didn't work offline, could explicitly prohibit overdraft and were easier to get.

But nowadays all boundaries gradually disappeared. Nothing is embossed, Visa Electron doesn't exist, bank issue debit cards with credit codes. It's all much simpler and more confusing at the same time.

I didn't try it on an active card, though, and I suppose the problem solves itself by time.

star/plus/cirrus etc - pure debit-only networks - aren't accepted on a plane

debit cards that are on one of the credit card rails (visa, mastercard, etc) are very common. those work because they're just a normal visa transaction

I wouldn’t be so sure about that. In some payment situations you’re asked whether you’d like to have the transaction go through as debit or as credit—so those two must be different somewhere. And probably in more than just a bit in a packet, as, for example, paying with debit Visas or MasterCards (normal ones, not Electron resp. Maestro) in the Netherlands (where locals almost universally have credit cards) is something of a crapshoot.

Some payment providers ask up front to simplify the flows as it's not totally trivial to determine what sort of card it is, and also because different fees apply - historically some merchants added specific fees to basket etc. (less so nowadays but the UI convention sticks)

And because the same card can be both. At least here in Brazil, most bank cards have multiple uses (credit, debit, ATM) in the same card. AFAIK, they're separate applications within the same chip, and the terminal has to select which one to use before starting.

The BIN will tell you which bank was the issuer and which class of card you have, like standard or premium, though most readers probably don't take that into account beyond the card scheme and card type associated with the range that the individual BIN is in. Many banks will have multiple BINs for the same card type if they are large.

Credit / online debit / offline debit usually get different ranges. The reader gets a list of the ranges when it updates and they don't change super often. Offline readers can be configured to reject cards with a number in an online only range.

Before that, there was the service code on the magnetic stripe, which also can convey things like "online only" or "domestic use only".

The BIN is only involved in risk management on the terminal's side: Many of these in-flight terminal accept deferred online transactions, which means that, even though they're completely offline, they take the risk of accepting an online-only card. (For truly offline capable cards, the risk is often with the issuing bank.)

That type of risk management can benefit from knowing what type of card it is, and prepaid cards are often seen as riskier (because customers might intentionally drain them before a flight). Of course, debit and credit cards can also be empty/marked as stolen, but these are marginally harder to get and replace.

Your correct on the risk spread. I wasn't confident last night (I'm not totally versed on the terminals) but looked it up. As I understand if you choose to accept offline only payments then you accept the risk of the transaction failing. If it's the issuers choice they own the risk.

Nope, even this is identical. These days the difference between a debit/credit card is pretty much aesthetic, from a transaction processing perspective there generally isn’t any actual differences. Differences that people see today are most artificial for the purpose of justifying extra fees, or higher interchange based an entirely arbitrary factor that has zero correlation to any risks that appear in the transaction processing and clearing mechanisms.

Basically the only reason anyone really bothers keeping the difference between credit/debit cards around, is as a technical excuse for discrimination and abusive fees. Notably in the EU nobody cares if a debit or credit card is used, because the EU outlawed all the crazy fees and other bullshit, so now there’s no commercial reason to differentiate between the two 99% of the time.

But to your wider point; from a transaction fee point of view you are dead right. Of course a credit card has other attractions; for example it's credit :D but also things like section 75 protection.

From the perspective of the card network and the merchant, there is no difference here. The card network has a contract with the issuer, so all transactions, in all scenarios, are always first paid by the issuer. It’s then the issuers problem to figure out where they get the money from.

It’s entirely possible to perform transactions on debit card that will place the account attached to it in a negative balance, and for the person owning that account to vanish. The card issuer is still on the hook for the money, neither the card network, nor the merchant, care if the issuer recovers the funds or not, they always get paid.

But there is a lot more complexity than, I think, you are glossing over. For example, you also likely have at least one technical services partner in the flows, probably two.

Additionally, money often doesn't move in real time, especially when credit cards are involved. The process is, intentionally, split.

Your point on that is fair, but remember, many credit providers are also not banks, and the money is in a bank account owned by a third party. So, as a trivial example, I can't just assume money coming to me from Bank A is related to transactions from Bank A's cards.

A lot of people don't realise that the main way all of this works is through very large batch files with lists of transactions in moving back and forth between various parties behind the scenes.

(We are on semantic points, though, but I just wanted to clarify the complexity behind the scenes that most people don't see or understand)

> I wouldn’t be so sure about that.

I would be very sure about that.

> In some payment situations you’re asked whether you’d like to have the transaction go through as debit or as credit—so those two must be different somewhere

Yes, that is correct.

Edit: OK maybe there's different level of trust and some take a leap of faith :) In my experience debit didn't work but it appears that its not the same everywhere.

When a debit card prompts for a PIN, don’t enter it, press submit, and it runs as credit instead of debit, but functionally works the same as far as the card-holder is concerned. It might take slightly longer to settle, and the merchant likely gets charged higher fees, but it works just fine. When I got my first debit card 20+ years ago my bank specifically told me to select credit and using it, instead of using it with the PIN as a debit card.

These days I’ve noticed the systems tend to auto-prompt for the PIN instead of asking credit or debit. But skipping it functionally works the same as pressing credit used to.

Plenty of places allow debit cards that don’t allow prepaid cards.

Edit: I've also seen it when paying on the cafe car while on train trips in Spain. Even without any cellphone/internet coverage they'll let you pay, but only with credit.

What would asking for the ZIP code help if it can't be validated on the spot? If the terminal submits the transaction in batch later, it's too late for that to catch a stolen card.

Providing an incorrect ZIP code also makes the transaction more likely to be declined than not providing one at all for card-not-present transactions (and is also allowed), so it really makes no sense for a merchant to do that.

That said, I still don't think that that's too common – building out cabin Wi-Fi for card authorizations only is probably not worth it, given how hard it is to get away with fraud in an environment where every seat has a passenger name to it, and that name is often verified by the airline or government at the airport or at boarding time.

The novelty was more that this was the first time I'd seen anyone buy the expensive perfume, I don't remember any more.

It usually does, it requires quite a bit of equipment and it doesn’t make economical sense to install it and not sell it to passengers. Airplanes have other means communicating with the ground and airline offices though.

In-flight credit card fraud is an incredibly bad idea, given that most countries check your ID at least at some point during getting on the plane, and seats are usually assigned as well. (Doesn't mean that nobody tries, of course [1]).

Sometimes airlines also use ACARS (basically airline-specific telex over VHF, HF, or satellite) to send the card number to their backoffice for authorizations of large amounts, such as business class upgrades.

These days, of course, Internet connectivity is getting more common, and with that the problem will likely go away.

[1] https://www.sunderlandecho.com/news/pair-spared-jail-after-a...

I still remember them taking my card which I think was a debit card on a flight and shoving it into carbon copy paper and basically billing me whenever we landed. This was late 2000s. From Puerto Rico to Florida.

Paying offline used to be the norm for credit cards, from their introduction in the 1960s until some two decades ago.

Wikipedia: [...] until always-connected payment terminals became ubiquitous at the beginning of the 21st century, many merchants accepted all charges, especially those below a threshold value or from known and trusted customers, without verifying them by phone. Books with lists of stolen card numbers were distributed to merchants who were expected in any case to check cards against the list before accepting them, as well as verifying the signature on the charge slip against that on the card.

https://fragrant.mobiletransaction.org/wp-content/uploads/20...

I remember a bar I worked at had trouble because some customers had begun writing wrong signatures and the receipt had been rejected by the bank the following week.

Essentially, you (the merchant) just write down their card number, and how much they paid you, and then later you send that list to your bank who sends it to the credit card network.

There is no big technical hurdle. There is a big social hurdle in convincing your bank and the network that you should be allowed to do this. Also the card number gets copied by a little pressing machine onto carbon paper or something like that, not just written down.

Being able to spend money you don't have is not a new thing, and poses no technical problems. American readers will know you can easily do that with a cheque. It's your responsibility not to do that, and that's one reason why the bank wants so much personal information to open an account, so they can send the police over to break your kneecaps.

https://en.m.wikipedia.org/wiki/Proton_(debit_card)

In a grocery store line once, I remember a distraught customer whose card was declined due to insufficient funds. The store manager came over, yanked the ethernet cable from the payment terminal, and told the customer to try again. "Accepted with signature."

So it's not _just_ blind trust.

I think something similar to this https://en.wikipedia.org/wiki/Credit_card_imprinter

Considering that the card has memory on it, you can store there how much balance you have when you do an online payment. The bank can send back your available balance, so you cannot spend offline more than you have.

I can't think about anything simpler than this.

I remember writing an app in Java to read the balance on a card with my laptop which had a built-in smartcard reader, because I was too lazy to go to a station. Everyone in the classroom then promptly asked me to check their balance... and a few asked if I could top it up somehow.

My thinking is that in this day and and age, unless something bad really happens (war, volcanic erruption), the chances of using a card for offline transactions for an extended period of time are very close to zero.

The merchant was guaranteed payment. You, on the other hand, were indebted to the bank. The concept of a “credit limit” was the line over which the bank insisted you not step, lest you incur fees galore.

Take a debit card for example. It's connected to a bank account, and cannot give credit. Garmin must be taking some of the risk on board, since the bank or card provider do not.

There's also the fact that anecdotally people are reporting different spend limits. On a thread I saw one person claim that £30 was their limit and another saying "My largest payment so far on the watch has been £275"

There can be other limits in place (like those controlling whether or not a PIN has to be entered), but those are on top of the requirement to obtain online approval from the issuing bank.

"Starbucks does not use two phase commit":

https://www.enterpriseintegrationpatterns.com/ramblings/18_s...

phone auth was added later for "online" auth, then machines that automated it

It's basic life goods and everything is still signed for, tracked and registered. Besides, banks love to collect interest.

They physically imprinted your card numbers on some special paper with a mechanical device. Wild.

And even paper based.

Offline, without double spending risk? Absolutely not, or at least not without a lot of extra headaches.

For that, you'll need at least some trusted hardware (generally an antithesis to trustless crypto schemes) and/or a clever incentive system (e.g. with senders staking a multiple of their balance as collateral, and never being quite sure if receivers are really offline, or only pretending to be, ready to claim their stake once they get publicly verifiable proof of double spending).

If it became common I imagine it would stop being so quickly as fraud would rapidly catch up.