4 ms·
> Billing and Accounts Payable will always seem like a "how could you mess that up?" problem to engineers, but it literally is difficult and complicated and rif
by nickjj 3y ago
> Billing and Accounts Payable will always seem like a "how could you mess that up?" problem to engineers, but it literally is difficult and complicated and rife with ways to very seriously and permanently fuck your relationship with your customer
Yep.
Over the years I've seen some pretty crazy payment related errors that you can't think is possible, like a 12+ year old publicly traded company who generates $60 million dollars a year and their business model is a platform that lets other people sell products, in other words their customers have their own customers and buying things with money through a hosted checkout page is a focal point of their business.
One bug was during this checkout flow:
- Open checkout page for product A and see a buy price of $99
- Open a new tab and visit product B's checkout page and see a buy price of $199
- Switch back to the first tab and buy product A for $99
- You get charged $199 and credited for purchasing product B
I was only the end user of such a system so I don't know what their code looked like but I'm guessing their checkout page had stuff stored in a session and the last page loaded new data in the session but it didn't match what was shown on the checkout page. That's a massive assumption but that's how I imagine it happened.
- VHRanger 3y agoWhy wouldn't you do the reverse bug on the checkout flow? You'd at least gain
- reaperman 3y agoNo, as described at least, you'd always get the product you paid for. Just not necessarily the one you wanted.
- pkphilip 3y agoBelieve it or not, I have seen the same problem on an insurance website for a very large insurance company. The issue was that the developers were storing the rates in session variables and so when you open a new product in a separate tab with a different rate, it would overwrite the session variables with the rates for the newly opened product. Then when the user went to the previous tab to purchase the product they ended up buying it at the rate for the product opened in the new tab. It is amazing that this mistake wasn't caught for a long, long time.
- echoangle 3y agoI hope they didn’t store the literal rate, but only the selected product id, in the session. Otherwise, you could just modify your request and set a low rate…
- pkphilip 3y agoNope. They stored a WHOLE RANGE of fields which was also used to display the rates directly to the customers. A total mess!
- disgruntledphd2 3y agoYeah, I had this problem with the world's only ultra-low-cost airline. We were working on an analytics system and this sortof stuff was pervasive. The entire frontend basically didn't handle multiple tabs. Mind you, this was in 2012, I assume they've fixed it by now.