Redesigning how refunds look

So I just used a really cool app called Rappi in Colombia. It’s like Deliveroo but they can pick up anything from any store (apart from stores that boycott Rappi for their problematic workers’ rights).

Anyway, they split transactions into two. They take a couple of quid when you make the request and the balance after they confirm the cost of the product. They messed up and had to give me a refund, which littered my feed. And now they messed up again so I have SEVEN Rappi transactions in my feed for a single £4 purchase!

It would be nicer to visualise refunds as strikethroughs in the feed, so they only appear once. I understand this would be difficult/impossible if it happens post-settlement, but before the transaction settles, it should be fine, no?

What do legacy banks do with refunds pre-settlement? I guess these wouldn’t even appear on the statement at all (or am I wrong).

Anyway, instant notifications and updates are great - except when retailers press too many buttons!


With card tokenisation becoming more common, would be great if there is a way to link refunds to the original transaction in feed.

Something like a strikethrough, or italicising, or even just a note like the flight number feature to indicate the two are linked.


This would probably be possible…but only if the merchant issued the refund in the correct transaction lifecycle!

We see a lot of ‘unmatched presentments’ where not enough information to associate the transaction with the previous authorisation is provided :disappointed:

1 Like

What are these problems?

Would it be possible to have an option in app to link a transaction manually instead?

Flow in my head would be something like:

Press on refund
Press on ‘link transaction’
Pre filtered transaction list for that merchant appears
Select transaction

1 Like

I believe we can do this on our end :blush:

I don’t think we’d ever build it into the app as it’s hard for the customer to conceptually understand why they need to mess around “linking” transactions. The effort would be probably better spent doing fuzzy matching :slight_smile:


Hi @HughWells, yes these are the ones I’m talking about. Refunds issued before presentment. I have another example - I bought metro tickets yesterday in Washington and I had card clash on the machine (!) so every time I tapped my metro card the machine couldn’t read it, and immediately refunded my transaction to Monzo (I tried a few times because I couldn’t figure out what was going wrong). Guess what happened?

For those kind of transaction+immediate refunds, there should be a cleaner way to visualise them.

But yes, I totally get why you wouldn’t want to start linking debits and credits that are days apart.


Thanks for the example!

If it was immediate it looks like those are cancelled authorisations :slight_smile: I can totally see why strikethrough is better than spamming your feed!

I’ll feed this back :+1:


I was waiting for this question :slight_smile:

Apparently Rappi don’t employ their bikers, they’re self-employed (similar to Uber drivers as far as I understand), so Rappi apparently doesn’t cover insurance. This is what I understand, but I’m happy to be corrected if I’m wrong. Also they earn pennies from each ride, and they might end up earning less than the minimum wage.

However, since they operate in a legal grey zone, a lot of Venezuelan refugees in Colombia use Rappi to earn money since they can’t legally work. So it’s an important source of (low) income for some people.

Thanks @HughWells and here’s the Rappi mess from the day before :slight_smile:image

1 Like