TfL payments on Monzo Flex being automatically flexed across 2/3 months

UK Help
28

Sorry for the slow response!

It sounds like what you’ve been told in chat is correct - but I can add a bit more context to it.

This is caused by the way TfL (and apparently now the pay-as-you-go Lime :melting_face:) first charge a nominal amount when you tap on / start a hire, and later update the same transaction using the same authorisation codes to the full amount.

We currently have very basic logic for when this happens:

  • If purchase is on an interest free plan, we update the amount and put it over the longest interest free plan.
  • If the purchase is on an interest bearing plan, we update the amount to put it over the longest interest bearing plan.

We designed it that way so if this happens and a purchase goes from e.g. £1 to £1,000 and they don’t notice it’s set to pay in full we aren’t overburdening people on their next payment date, causing them to potentially miss payments.

The fix here is obviously to make that logic smarter, which is on our list of things to fix. The complexity is in the various edge cases in this edge case! For example:

  • If someone had a default set but changed the purchase to a specific monthly payment
  • If someone has already made a payment towards a purchase

Thanks for sharing this through the community. It helps us see and prioritise fixing issues - which we’re doing for this soon!

6 Likes
29

Hi Tom

Thanks for looking into this and providing a very clear and detailed response.

Now, this makes sense to me. It’s more a design feature than what I wrongly assumed was a bug. It’s a shame that I wasn’t just told that earlier :slight_smile:

Anyway, in the meantime, a suggestion for this could be that before the payment is defaulted to an instalment plan (when the user has pay-in-full selected), it prompts the user to either choose the change or reject it and remain pay-in-full. If no response within a certain timeframe, it places the payment on an instalment plan anyway.

However, I now think there is another nuance/complication to this.

My payment date is 25th of the month and I keep track of my finances with Account Tracker (smartphone app).

I have had my 25 April payment in the app (£576.74) since the 14-day mark on 11 April. On 22 April, I was transferring some money between accounts - the Flex payment on the front screen for 25 April was still showing as the amount above. However, when I looked at my app yesterday (23 April) I noticed it had gone up slightly by £0.55 (only a small amount, but still, I wouldn’t expect a payment to go UP during the 14-day period between “statement” date and payment date).

Customer Service have been unable to provide an explanation at this point, but I think I’ve worked it out for myself.

I went through some of the transactions and noticed that a Lime pay-as-you-go payment from 7 April was on a 2-month instalment plan rather than pay-in-full. I had remembered this transaction from earlier in the month (£2.45), it had defaulted itself to an instalment plan rather than pay-in-full (as per the process you have outlined in your message) and I had changed it back to pay-in-full.

I used a Lime bike on 21 April for £2.74 (and it had now appeared on this same transaction (presumably using the same auth code) from a full 2 weeks prior(!) and increased the payment amount to £5.19. It had changed it back to a 2-month instalment plan and as a result, because the original authorisation code was prior to the 11 April (my 14-day cutoff period for 25 April payment), it therefore increased my payment amount 2 days prior to the payment being due even though the transaction (if it had it’s own new unique auth code) should be paid on my next payment date in May.

The increase in £0.55 was the increase of the payment due to the plan. If I edit the transaction to just a 1-month payment, it increases my credit card payment by that amount (£2.74)

I suspect this is another complication of the Flex/instalment system.

Anyway, thanks again for the explanation - I really think there would be a benefit to prompting the user.

“This transaction amount has been updated by the retailer. We will change this to a 2/3 month Flex instalment plan in 2 days. If you do not want this to happen, please edit the plan and change it to pay-in-full”

… or words to that effect…

1 Like
30

Thanks again for sharing - very helpful to see how this plays out in ‘real life’. And sorry that the experience has been a bit painful.

Yes, I think you’re right that telling users when this happens is a good first step. I’ll see what we can do :hammer_and_wrench:

1 Like
31

But then there’s a problem with that if the payment is due within the “cooling off” period, whether that be 2 days or whatever.

32

@TomMills you mentioned that what I had been told in chat is correct. Below is what I was told:

“ Thanks so much for your patience.
I had a look and see Transport for London uses authorization for a number of transactions. This results in the same instalment plan being amended rather than a new one created for each transaction. These are still pay in full, except each month Transport for London debits come from the same instalment plan. Unfortunately there’s nothing we can do, its how Transport for London process their payments.
Let me know if there’s anything else I can help you with today otherwise have a great day.”

This message was copied and pasted to me multiple times, at least 3 times.

This doesn’t read correctly to me and added to my frustrations regarding my interactions with customer service.

They keep referring to “instalment plan” when really I think they mean “authorisation”. And they even say “these are still pay in full” but then refer to an instalment plan in the same sentence. It can’t be both.

In my opinion, the stock response needs amending because it’s convoluted and confusing as it is at the moment.

1 Like