Any customer-to-provider interaction can result in a dispute, whether over a defective product, an unfulfilled promise, or, as in the case we’ll cover here, something completely different. In this blog post, I’ll share a recent case where a guest claimed they were wrongfully charged for a reservation they supposedly canceled months ago. What started as a routine investigation into a potential bug quickly turned into something much more interesting.
The Beginning
I remember it as a cold September morning, a hot cup of coffee in one hand and my company-issued Logitech mouse in the other. The sound of the Slack notification ping cut through the room. It was my manager, asking me to look through a case. At that time, I was part of a team which routinely dealt with customer reports and system defects, so it was not uncommon for files to come across my desk, but there was something different about this one…
It started in early February when a guest made a group reservation through our booking system at a picturesque property with clusters of floating accommodations in an Indonesian bay. “Must be nice,” I thought to myself as I scrolled through the property images, imagining a holiday getaway there. The reservation was set for mid-August, with stunning views and memorable experiences waiting to be had. Total cost? A few thousand euros.
The property was smart, and had a fair cancellation policy: Cancel two weeks before arrival for a refund, otherwise you pay the full amount. It’s a way of protecting themselves and making sure they have their rooms booked.
Fast forward a few months to August, just a day before the guest was supposed to arrive and enjoy the breathtaking location. The property marked the reservation as “no-show”, and the guests card was charged the full amount.
However, we had an issue here, The guest was requesting a prompt refund, on the basis that they have canceled the reservation through our Guest Portal.
The Start of the Investigation
A colleague of mine had looked, and there was no record of the reservation being canceled in our system, nor could they find any emails sent to the guest from our system. Yet the guest provided an email screenshot with a timestamp of June 30th, stating that the reservation was canceled. It didn’t make sense. Although the saying goes “The customer is always right,” something wasn’t adding up here.
I rolled up my sleeves and started to look deeper. What had we missed here? Did our automated tests fail to catch this? I created a similar reservation in our development environment and canceled it just like the guest would. With my heart racing, I worried: “How long has this bug been there? How did we overlook such a crucial operation?”
After a tense wait, relief washed over me. The cancellation worked perfectly, updating the action log with the correct details, and sending out the automatic cancellation email as it should. It seemed our system was functioning correctly now, but that didn’t mean it wasn’t bugged in June…
Digging Deeper
With no obvious technical issue in sight, I looked deeper into the guest’s specific reservation. Everything seemed in order — the profile hadn’t been touched since the reservation was created, no online check-in had been completed, and all logs showed only employee actions. Nothing indicated that the guest had canceled the reservation.
Still unsatisfied, I expanded my search. Combing through reservation reports, filtering for guest-initiated cancellations around June. The system showed that other guest cancellations were processed correctly during that time, closing off that lead. Our system was working, but there was still no trace of this guest’s alleged cancellation.
Want to uncover the unexpected twists behind customer disputes firsthand?
Check out our open positions!
As frustrations mounted, I turned my attention to the email logs. I searched both the property’s email queue and the system-wide mail queue, hoping to find any record of the June 30th email the guests claimed to have received. Nothing. All the emails sent to the guest were accounted for, and while there were automatic cancellation emails during that day, none were for this specific guest.
The Hypothetical Lightbulb Moment
At this point, we were at a crossroads. I felt confident that the guest had not canceled the reservation, but I couldn’t prove it conclusively. After taking a step back, I started thinking through some hypotheticals. How could the guest access the Guest Portal to cancel their reservation if their sign-in token had expired months earlier?
This token, sent as part of the reservation confirmation email, allows the guest to log in without a password. However, the token has a set expiration time. This means they shouldn’t have been able to sign into the app at the time they said they had without requesting another token, which would have been recorded in the system. Based on these findings, I was ready to close this case and call it a day… or so I thought.
The Twist: Legal Threats and New Evidence
Later that evening, things escalated, and escalated quickly. The guest was now threatening legal action. They provided additional evidence, including the full email header of the supposed June 30th cancellation email.
It looked authentic, and my stomach sank. All our information says one thing, while the guest-provided information clearly says another thing. I began to doubt our own data and even started to feel bad for the guest. Was this a case of a guest being wrongfully charged thousands of euros due to the mistake of one R&D team? The investigation continued into the next day. I scrutinized every detail of the email and email header the guest provided. Desperation crept in as I pored over the email, zooming in and out of the screenshots, inverting colors, and applying every trick in the book for signs of tampering. But alas, nothing was out of place.
The Breakthrough: Cracking the Code
Just as I was about to give up, something caught my eye in the email header, and there it was, as clear as day:
“…TG9jYWxpdHkiOiJNYW5nZ2FyYWkiLCJhZGRyZXNzUmVnaW9uIjoiLSIsInBvc3RhbENvZGUiOiI4N CJhZGweGWSyZXNzUmVnaW9uIjoiWxpdHkiOiJwkiLCJhZGRyZXNzU …”
For those unfamiliar, this was a base64 encoded section. This encoding is a way of converting data into a string format. It’s often used in email headers to store metadata about the email, such as timestamps and content information.
I rushed to decode the base64 string and, sure enough, there was the smoking gun, handed to us, by the guest themself. The metadata in the email’s encoded section showed the actual timestamps of when the email was sent, and they didn’t match the guest’s claims. The reservation wasn’t canceled on June 30th, as the guest had stated. They had altered the email header, carefully crafting their fraud, but had overlooked one crucial detail: the encoded metadata still contained the original date.
This was the conclusive evidence we needed. By comparing the decoded timestamp with the system logs, we confirmed that the guest had fabricated the whole thing. But in their rush to cover their tracks, they’d left behind a breadcrumb trail, one we were more than happy to follow.
The evidence was handed over to the property and the case was filed away as closed as I took the last, cold sips of yesterday’s coffee.
Key Takeaways
This investigation taught us some important lessons, both serious and lighthearted:
- If you’re going to do something, do it right: Whether it’s resolving a customer dispute or writing code, attention to detail is a must. Skipping the small details can lead to huge oversights.
- Always spend time on the details: The customer’s attempt at fraud was undone by a single overlooked detail in the email metadata. In our work, it’s often the little things that make the biggest difference.
- Never give up: Persistence pays off. Digging deeper and exploring every possible angle helped us uncover the truth and protect the property from significant loss.
- If you’re going to commit email fraud, at least remember to update the metadata: While we don’t endorse fraudulent behavior, this case is a great example of why it’s important to understand the full scope of what you’re doing.
A Challenge for Dev Teams
Now that we’ve shared this information, we challenge you, the reader, to think about how you would handle a situation like this. Are you confident that your fraud prevention systems are secure and provide the protection you need?
Interested in our GuestPortal? Check out Jan Marek’s blog post on how scaling the GuestPortal from a monolithic backend to microservices unlocks greater scalability, domain independence, and operational efficiency.
