Last week I was renewing one of my domain names (actually this one). The present domain provider was charging double the price, so I decided to transfer it to another provider. This was supposed to be standard admin — it ended up being tech whack-a-mole.
I ended up discovering how quickly an entirely legitimate online transaction can begin to look suspicious when several automated security systems interact with one another.
A simple domain transfer
I opted for Porkbun, funny name yes, and if you don’t like the name, this is what they say about it if you don't like their name ":'(".
The reality is it’s a well known domain registrar known for its simple pricing and good customer service.
The problem was the transaction to pay kept on failing.
At first, this looked like an ordinary payment problem. I worked through the obvious possibilities. I disabled Adguard, Custom DNS and adblocking, tried incognito mode, and saved the payment card to my account. Each time, credit card authentication appeared and completed fine, yet the transactions were still rejected. I even tried with PayPal, with the same result.
The card transactions appeared initially to go through and were subsequently cancelled. Porkbun support was helpful. They told me the account “was being caught up in security restrictions that affect newer accounts” and they unblocked the account. Still no luck.
I could have just gone with another provider, and maybe I should have, but instead decided to investigate further.
A clue, but not an answer
During my correspondence with Porkbun, support pointed out that the email address associated with my account used SimpleLogin.
I have, shall we say, an "optimised" email and internet security system. I use email aliases extensively. Rather than giving every company the same email address, I can create a unique address for a particular service. If that address subsequently starts receiving spam, I know where it was exposed and can simply disable the alias. I combine that with adblocking, custom DNS and VPNs.
Could that information have mattered to an automated fraud-detection system? Possibly, although I have no way of knowing for certain.
I don't know whether such a lookup happened in my case, whether SimpleLogin played any part in the failed transactions, or what other signals may have been involved. I have no visibility into the relevant risk models.
The irony is, I get it. As a lawyer, we have to run know-your-client and anti-money laundering checks. We ask additional questions, weigh risk factors and sometimes decide we cannot act for a client; there are also circumstances where we cannot tell the prospective client exactly why. I know what that looks like from inside the decision-making process, but this time I was experiencing it from the other side. The opacity can have legitimate reasons, but that does not make it any less frustrating for the person on the receiving end.
Authentication is not the same as trust
The most interesting part of the experience wasn't actually SimpleLogin. It was what had happened earlier. I had successfully completed authentication with my credit card provider, yet the transaction still wasn't completing.
Authentication asks, in essence: are you really the person entitled to use this payment method?
Risk assessment asks something broader: given everything we know about this transaction, are we prepared to accept it?
Successfully answering the first question does not guarantee the answer to the second. A merchant or its payment infrastructure may have legitimate reasons to decline a transaction even after the cardholder has authenticated.
But from the customer's perspective, the distinction is striking. I had just completed an additional security step specifically designed to provide greater confidence that I was the legitimate cardholder. Somewhere else in the process, that still wasn't enough.
I don't know precisely why. It would be misleading to pretend otherwise. What I could observe was the paradox: identity and trust had become separate things.
I could authenticate who I was without satisfying whatever combination of signals the transaction needed to be considered acceptable.
And then things became stranger.
The problem followed me to Uber
Later that day I was taking an Uber. My usual payment method was the same credit card I had been using during the Porkbun saga. I had used this card with Uber many times before and had never had a problem with it. Uber declined the card and I had to use another card to pay Uber.
The card provider confirmed that security controls on my account had affected the transaction. The representative believed this was related to the rapid sequence of activity during my attempts to pay Porkbun—transactions that had initially been authorised and were then cancelled. Luckily the card itself wasn’t blocked.
I had started the day trying to save seven dollars on a domain renewal. I had somehow ended up needing to reset the relationship between my credit card and Uber.
When legitimate behaviour starts to look suspicious
Consider some perfectly legitimate choices a privacy-conscious internet user might make: use a unique email alias rather than handing the same address to every company; use a custom domain; use encrypted or custom DNS; use a VPN when appropriate; block advertising and tracking; limit the information companies can use to correlate activity across the internet. There are perfectly reasonable reasons for each choice.
But fraud-prevention systems face a difficult problem. They have to distinguish legitimate customers from fraudsters quickly and at an enormous scale. They cannot ask each person what their intentions are. Instead, they infer risk from observable signals surrounding an account, device, network, payment method and transaction. Increasingly, those judgments are assisted by automated systems and machine-learning models.
It also brought me back to something I wrote about recently in the context of AI: technology can help identify patterns and surface issues, but judgment still lies in deciding what those patterns actually mean.
Some signals can have more than one explanation. A legitimate user may use an email forwarding service to protect their primary address. Someone committing fraud may use one to make themselves harder to identify. A legitimate user may use privacy tools to reduce tracking. Someone committing fraud may try to obscure characteristics of their network or device.
The observable signals can look pretty similar. In my professional world, an unusual KYC result is often the beginning of another question rather than necessarily the end of the process. Human judgment can take account of an explanation, ask for more information or escalate something that does not quite fit. My experience here exposed a second problem as well: the way a legitimate customer responds to a security system can itself start to resemble suspicious behaviour.
My payment failed, so I tried again. I contacted support, and then tried again. From my perspective, I was troubleshooting a legitimate purchase.
From the perspective of an automated system observing a rapid sequence of transactions, authorisations and cancellations, the pattern could look very different.
The irony is difficult to miss: repeatedly trying to prove that a legitimate transaction was legitimate apparently helped create the sort of transaction pattern that security systems are designed to question.
Security versus security
Fraud prevention is an adversarial problem. Merchants, payment providers and banks have to make decisions under uncertainty, and false positives are an inevitable consequence. The complication is that many behaviours which can look unusual are also sensible security practices: unique email aliases, custom domains, privacy tools and additional authentication all have legitimate purposes.
At the same time, each participant is applying its own controls. The customer protects their privacy, the merchant protects itself against fraud, the payment provider applies its risk rules and the bank authenticates its customer. In my case, repeated attempts to resolve one failed transaction then generated a sequence of authorisations and cancellations that triggered further security controls. Every participant could be behaving rationally, yet I still ended up unable to buy an $11 domain and temporarily unable to use my usual card for an Uber.
That is the awkward part. Automated systems make e-commerce scalable, but a merchant may have limited visibility into why a particular transaction has been rejected and a customer may have no obvious way to recover from a false positive. The natural response is to retry, change something, authenticate again or contact support. But those actions generate new signals too.
Convenience depends on being recognisable
We tend to think of frictionless e-commerce as a technological achievement, but perhaps it also depends on something we discuss less often: recognisability. Behind a simple checkout, systems are making rapid judgments about who we are, whether our behaviour looks normal and whether a transaction appears trustworthy.
Privacy tools deliberately interfere with some forms of recognition and correlation. That is partly their purpose. The uncomfortable possibility is that reducing our digital trace may also reduce some of the signals automated systems use when deciding whether to trust a transaction.
That isn't an argument against privacy or fraud prevention. Both serve legitimate purposes. The more interesting question is whether we can build systems where privacy does not become a proxy for suspicion, and where a legitimate customer can recover from a false positive without making themselves look even more suspicious.
All this for seven dollars
I started this exercise because I noticed that I could renew a domain for $11 instead of $18. The economically sensible decision would probably have been to pay the extra and get on with my day.
Instead, a domain renewal gave me an unexpected glimpse into the infrastructure of digital trust. Behind an ordinary checkout button sit merchants, banks, payment networks, authentication protocols, fraud models and countless signals most customers will never know exist. When everything works, all that complexity disappears.
It is only when something goes wrong that you realise how different proving who you are can be from persuading the machinery around you to trust you. All because I wanted to save seven dollars on a domain renewal.