It was a problem caused by certain types of bank account and their interplay with EMV ‘transit’ mode, where monies are not debited instantaneously as they are (for example) in a shop.
I‘m not sure what you mean. Transit mode is what is is. Liability for declined transactions over £10 lies with the operator. It was this liability coupled with a certain client base using a certain selection of banks that caused the problem. It would be unwise of me to say more.
I think the confusion may stem from a misunderstanding about how transaction processing works for dual-message system cards. It's important to note that mass transit transactions
are different from a 'shop', and that's why separate processing rules are in place.
DMS cards never debit money 'instantaneously'. When you (the customer) transact with a shop, they obtain a technical authorisation with your issuer to debit your account (PAN) for up to an amount. The issuer is then guaranteeing that the acquirer (representing the merchant) will get their money at a future point in time. It is possible to adjust the authorisation amount by sending an auth advice after the initial auth, but that's a bit beyond scope here. At this point the card machine prints and reciept and you walk out of the shop with your item, but
no money has changed hands.
The second part of a DMS transaction is clearing. The acquirer will submit the authorised transactions it wishes to clear to the network in a batch file - this is known as presentment. The network will then sort out who owes who what (multiple issuers, refunds etc.) and send the clearing files to the issuer, debiting their account (this is
net-settlement). The issuer then sends a big CHAPS payment (or even a BoE transfer) to the network, which dishes it out to the acquirers.
There are rules about how the acquirer must present - for example, you must present within a certain timeframe (ie. the time for which you have obtained authorisation) and you must have an authorisation correctly identified and linked in the presentment.
It is of course possible to just submit presentments without authorisations - this sometimes happens for technical reasons, or if the Acquirer messes up and doesn't submit to clearing in time. Those are known as unauthorised presentments and the issuer is entirely within their rights (under scheme rules) to submit authorisation chargebacks (4808), and they will.
---
So how does what people are calling 'transit mode' work? Well, the difference is that for 'transit mode' the final amount is not known.
It is helpful to think about how TfL do this, as they have implemented it very well.
When you 'tap in', TfL will authorise a small amount (10p) on the card correctly identified as a 'transit mode' transaction. This tells them that the PAN is active, the cryptogram the card generated was valid etc. They need to do this otherwise they will have no authorisation to present against, which would be against scheme rules.
When you ride around TfL you'll accrue a number of fares (and maybe hit a cap), but TfL won't submit any more auths (mostly, see below). At the end of the day, TfL calculates the total amount you owe them and takes into account any caps you've hit.
They can then submit a presentment to clearing for the total amount you owe and crucially, because they correctly identified the transaction as a mass-transit auth, they are allowed to present above the amount they authorised (ie.
without authorisation) by the scheme rules. This is important because it means that even if you
don't have enough money in your account with the issuer, TfL will still get their money and be protected from chargeback - the issuer takes liability.
There are various caveats to this, including the liability shift ceiling (ie. the maximum amount).
---
So, what can go wrong in 'transit mode'?
Well, if you don't identify the transaction properly as a mass-transit transaction then the rules I've described above simply don't apply.
Likewise, if the acquirer/merchant tries to present for an amount higher than the liability shift ceiling then the liability shifts back to them. TfL will re-auth your card if they think you're about to go over the ceiling, and split your fares across the auths - that's within the rules. They have some business logic about how they do this which I don't know and will be quite sensitive.
---
I don't really know what has happened in this specific situation we're discussing in the thread, mostly because I haven't read in detail about what has happened and can't see the transaction data. However, if you are selling a fixed price product (ie. a day/season ticket) then that should be authorised correctly for the
full amount - not as a mass-transit transaction - and especially not if it exceeds the ceiling. If it declines, don't issue the goods as you won't be able to collect any money!
I believe the Ticketer approach is to submit separate auths for each transaction you make (ie. for each single, for example) and not batch transactions for clearing. That's a much simpler approach and is entirely within the rules AIUI. (TfL has a much cleverer system because the delay in obtaining auth for each 'tap in' at a gateline would cause serious backlogs at stations, and their gatelines need to be able to operate 'offline' at peak times).
