Any time saved by ordering online and picking up the order has vanished chasing customer support people to fix something that would have taken a few seconds through their website.
It’s almost like buying and refunding are two completely different processes that are handled under entirely different protocols by credit processors, and one part working has no bearing on whether or not the other part works.
I never claimed they share the same components, but I do claim they have very different prioritization.
And I never claimed they don’t have different prioritization. I’m just saying that one working doesn’t mean the other will also work.
and this screenshot clearly shows an issue with Walmart not loading a page, not MasterCard delaying operations.
The page may have not loaded because of a failed API call to the credit processor when requesting a refund. Charges and refunds are different API usages, and it’s wholly possible that an issue on the processor’s side can break pages on a merchant’s site. If for some reason Walmart’s site can’t communicate with Visa/MC/AmEx/whoever and their page isn’t configured to handle a specific failure, it will likely go to a default error landing page as a failsafe.
I’m not defending Walmart or anything; just explaining some of the technical reasons a refund page can break. API failures happen even to non-scummy stores, as well.
Regardless of how these protocols may be handled, they advise customers to use the refund option within the order screen on the website, which is what I did.
If it’s broken, why even direct people there? I wouldn’t expect a half-working website from one of the largest retailers on the planet.
Links generally don’t know if the service on the other end of the link is up or down at that time. I mean you could have it go out and prefetch the headers but that’s a lot of overhead for every link.
