Unauthorized overdraft, transaction declined, later on accepted, why?

UK Help
43

It sounds like Lenovo have a seven day authorisation hold, and usually expect to ship within 7 days. In this case you wouldn’t notice anything.

As explained above there are two parts to a MasterCard transaction - an authorisation and a presentment.

When the merchant authorises the payment it is “pending” and the funds are ring fenced but haven’t technically left your account. Later on the presentment happens and the money leaves your account - this is what Lenovo are saying when they “charge” your card.

Nobody has done anything wrong in this situation, but it sounds like Lenovo could have made things clearer with some plain English.

44

The second one wouldn’t go into an unauthorised because it was presented using a new auth code. We see that as a new transaction (because it’s a new auth code) and so have no obligation to accept it if funds aren’t available.

When they then presented on the original auth code, which had been authorised when the customer had funds available, we were obliged to honour it despite the fact it pushes the customer into an unarranged overdraft.

Edit: I should add that they’ll have been able to attempt to charge using a new auth code as the customer likely consented to credential on file when they were checking out / agreeing to the terms and conditions of the sale.

45

Wouldn’t that only be possible if the transaction was a CPA to create a new auth without the customer entering CVV

46

Nope - once you’ve handed your card details over then they can create a new auth to attempt to take the payment.

Edit: on the second point companies can, and do, process card transactions without the CVV. Amazon is a good example of this. There are different forms of AVS and depending on which method the merchant uses depends on where the liability for fraud falls.

47

They can’t store CVV though only 16 digit and expiry

48

See my edit above - there’s no requirement to use the CVV (actually with MasterCard it’s technically CVC2 I believe) to authorise a transaction.

49

Amazon is pretty much alone though when it comes to not taking CVV

50

They really aren’t - there are a huge number of transactions we see which aren’t processed using the CVC2. These transactions are usually verified only by address and postcode -even then we only tell the merchant whether they match or not. It’s then up to the merchant whether to accept the liability if the billing address doesn’t match the account address.

Some merchants mix and match too, so they might process the first transaction using CVC2 but then future transactions without (because they can’t store it).

52

Spotify uses CPA (continuous payment authorities) basically giving them permission to take from the account. You’ll find it on things like domain registrars for auto-renewal, or selling on eBay for billing purposes etc

If you have a PayPal account there’s a section that lists all the places that processed as a reoccurring payment in a similar way. (Edit they called them Automatic payments now)

53

I had the same experience a year or two ago buying a laptop from Lenovo.
From memory, they took an authorisation when I ordered, that was reversed a day or two later, and then they placed another transaction when they shipped the order

It’s not a great experience, but I imagine if you were looking at this on a traditional bank’s online banking, you wouldn’t have noticed the reversal

54

It sounds like what happened is

  • Lenovo submitted an auth request, coded as a “normal authorisation” (7 day expiry)
  • It expired
  • They submitted a second auth request, which was declined for insufficient funds
  • They submitted a clearing record, which debited £600

It would have been better if the initial request had been coded as a pre-authorisation (which lasts 30 days), or if Lenovo had renewed it rather than allowing it to expire.

Clearing records aren’t requests - they’re “I’m taking £600 from the customer” messages; Mastercard just move funds as indicated. If the funds weren’t authorised originally, then you can raise a charge back.

In this case, you entered into an agreement to pay with the merchant. If you didn’t cancel the order, you’re still bound to that agreement. It’s not possible to raise a customer dispute chargeback - it’s an order you placed. Even if you won such a chargeback, legally you’d still have an obligaiton to pay Lenovo.

Now, this situation isn’t risk free for the merchant. The bank can raise a “financial loss” chargeback since the transaction wasn’t properly authorized (the hold was allowed to expire), but they have to close your account first

55

Thanks Erin - I always enjoy the insight you bring to the community.

I’ve highlighted a bit of your message above. Could you expand on why a bank would have to close your account? I can’t quite work out why, aside from some form of punishment for working the system?

56

The bank must terminate the customer’s account because the customer is considered to be the party at fault. The customer entered into a transaction with an obligation to pay the merchant, and the customer has failed to do so.

Normally, the bank would be the one holding (and responsible for recovering) such a loss. In cases where the acquirer/merchant has not followed the proper protocols - lettting the authorisation expire or failing to acquire proper authorisation from the card for offline transactions being examples - in order to allow the issuer to protect itself from such losses, then the issuer may chargeback the transaction and make it the merchant’s problem to recover

One way of looking at it is to turn it around somewhat: if a customer’s account is closed due to default, the bank may transfer any debt which was incurred due to merchants processing payments incorrectly back to them

57

Basically the take away from this thread is always cancel your order from the merchant and wait for acknowledgement before buying elsewhere unless you have the balance to cover this scenario.

58

Right

When I talk about merchants “not following proper procedures”, I should clarify: All a merchant needs to bill you over one of the major card networks is

  • Your card’s PAN, and
  • Your agreement

At that point, they can submit a clearing record to debit your account (or credit, they don’t need your agremeent for that)

This is pretty much how things worked back in The Beginning, except clearing records were peices of paper (somewhat like cheques, in a way) normally with your card’s details captured using an embossing machine.

Of course, there’s a bunch of risk in doing that: The network might reject the transaction (because there’s no issuse to route it to) or the issuer might reject it for a bunch of reaosns (no such card, cardholder didn’t authorise transation i.e. fraud due to stolen details/card, customer didnt have the money and the issuing bank has suffered a loss)

The “issuer finanical loss” case wasn’t there originally: issuers were expected to vet who they gave credit cards to. It was added later, as access to credit cards widened and as ATM cards started “merging” with credit cards to form debit cards, and online authorisation became the norm. Note that an issuer can’t use it just because you failed to repay the issuer - it can only be used when the issuer wouldn’t have authorised the transaction if the acquirer attempted to do so.

Every step beyond those two is about managing (and transferring) risk:

  • Online authorisation checks that you are good for the funds and lets the issuer disable stolen cards
  • Chip cards remove static, duplicatable credentials from in-person payments
  • Offline authorisation (i.e. where the card will approve a transaction entirely offline) lets the issuer place caps on their liability for these types of transactions
  • 3DSecure (and Digital Secure Remote Payments - Apple/Google Pay for ecommerce) lets the issuer implement controls to validate that you are you and not some fraudster that has stolen your card details

(Authorisation holds expire to prevent a merchant from forgetting one and accidentally blocking funds in your account indefinitely. Merchants are not supposed to place them and allow them to expire - and they’re certainly not supposed to place them and then e-mail PANs to random people at your card issuer to reverse them - My Monzo e-mail address averaged several of those a day! The networks are slowly ramping up enforcement of the requirement for acquirers to properly reverse auths they don’t intend to clear, and also to stop the £$€1 active card check nonsense)

The Mastercard Transaction Processing Rules (and the Chargeback Rules, and the others) are all about setting the parameters of these liability shifts. Broadly, the merchant/acquirer have a bunch of options available to them which enable them to shift liability for fraud to the issuer; they need to trade them off against the friction they may introduce and how that may cause people to “drop out” of payment flows. These options generally give the issuer more information and place them more “in the loop” - allowing them to make more informed decisions.

But at the end of the day, it boils down to the fact that if you enter into a transaction, that comes with an obligation to pay.

The above said: The way the Monzo app says “refund from Merchant” when an authorisation expires is misleading, and was one of the things on my todo list when I was a Monzonaut. Unfortunately, it was structurally hard to fix because the payments team never had any mobile developers.