Over the years, I have investigated and consulted on hundreds of domain name disputes, and a particular pattern keeps resurfacing. A business hires a web designer or developer to build and maintain its website. The developer, as a matter of convenience, registers the company’s domain name and is listed as the registrant of record. The relationship later sours over money — real or imagined — and the developer responds by seizing control of the domain name, transferring it into an account the business cannot reach, and refusing to release it until a demand is paid.
I want to address this situation directly, because I recently encountered another version of it, and because the person holding the domain name was operating under a belief that is both common and wrong: the belief that a signed agreement authorizing him to “keep the domain until the client pays” makes the practice legitimate, and that dispute panels have sided with him because of it.
The details below are anonymized. The facts are drawn from a real matter, but the individuals and the business are not identified, because the domain owner intends to pursue the matter through the courts. What I want to focus on is not the personalities involved but the principle, because the principle applies to every business owner and every developer who has ever wondered who really owns a domain name when there is a dispute over an invoice.
The Situation
A business owner hired an independent web designer to build and host a website. As is common in these arrangements, the designer registered the exact-match domain name — the domain built around the company’s own business name — and for a period was the registrant of record. The business paid for the work. According to the owner, every invoice was ultimately satisfied, with the final payment made through PayPal, leaving no outstanding balance.
The designer, however, operates under a standard practice he says he has used with clients for years. Each client signs an agreement stating that if the client fails to pay, the designer may take control of the client’s domain name and withhold it until payment is made. In this case, the designer moved the domain into his own control and asserted that the client still owed roughly five figures. The client disputes that any balance exists and has payment records to support that position.
The designer also told me something more striking. He said he had prevailed in domain name disputes before — specifically, in proceedings under the UDRP (Uniform Domain-Name Dispute-Resolution Policy, the arbitration system ICANN uses to resolve domain ownership conflicts) — precisely because he had a signed agreement allowing him to keep the domain until he was paid. That claim deserved to be checked, so I checked it.
The Most Important Finding: The Controlling Precedent Goes the Other Way
Here is the finding that matters most, and it is the one I want business owners and developers alike to understand clearly.
I searched the published decision databases of the two providers that actually decide UDRP cases for United States disputes — WIPO (the World Intellectual Property Organization) and the Forum (formerly the National Arbitration Forum) — along with the general legal indexes. I was looking for the scenario the developer described: a web designer or developer who registered or seized a client’s domain name, held it over an unpaid invoice, and won the resulting dispute because a contract said he could.
I was not able to find a single UDRP decision reflecting that outcome. Not one in which the designer or developer who held a client’s domain hostage for nonpayment ended up prevailing on that theory.
What I found instead was the opposite. The published decisions run consistently against the party holding the domain. When a developer takes a domain that belongs, in substance, to the client’s business and uses it as leverage in a payment dispute, panels treat that as bad-faith use and order the domain transferred back to the business. The contract clause does not rescue the developer; if anything, it documents the intent to use someone else’s property as collateral.
I want to be careful and precise about the limits of this search, because accuracy matters more than a good headline. A UDRP case would not appear under an individual’s name if that person had used a WHOIS privacy service, and disputes that settle or are withdrawn before a decision is issued are never published at all. So “no public decision” is not the same as “provably never involved in a proceeding.” But the specific representation — that a developer wins these cases because of a pay-or-I-keep-it contract — is not supported by any decision I could locate, and it is contradicted by the body of precedent that does exist.
What the UDRP Actually Says
To win a UDRP proceeding, a complainant must establish three elements: that the domain name is identical or confusingly similar to a trademark or service mark in which the complainant has rights; that the registrant has no rights or legitimate interests in the domain; and that the domain was registered and is being used in bad faith. A business name that has been used in commerce for years generally supports common-law trademark rights, which is why the exact-match domain built around a company’s name is exactly the kind of domain the UDRP was designed to protect.
The key move in a developer-hostage case happens on the third element, bad faith. Developers often argue that they registered the domain legitimately — after all, the client asked them to build the website — so there was no bad faith at the outset. Panels have repeatedly rejected that framing. Even where a domain was first registered with permission, using it as a hostage to extract payment is itself bad-faith use under the policy.
A clear illustration is Alaska Health Fair, Inc. v. Chris Jacobson (National Arbitration Forum, 2013). A web developer had lawfully come to hold his client’s domain name for development work. When the business stopped paying him, he kept the domain and posted a message stating that the site was “paused for non-pay on overdue invoices,” demanding payment of a specific invoice before he would release it. The panel ordered the domain transferred back to the business, holding that leveraging a client’s domain to collect a fee is bad-faith use — regardless of how the developer first came to control it. The debt, whatever its merits, did not entitle him to hold the domain.
The reasoning in these cases is captured in the WIPO Overview of WIPO Panel Views on Selected UDRP Questions (the “WIPO Overview 3.0”), the reference panelists rely on for consistency. The recurring theme is straightforward: a domain that corresponds to a client’s own business identity belongs to that client, and a vendor’s financial grievance is a matter to be resolved separately, not by seizing the domain.
The Courts Go Even Further
The UDRP only decides who keeps the domain. It cannot award money, and it cannot punish. When a business goes to court instead, the exposure for the developer is considerably greater, and the case law is even less favorable to the hostage-taker.
The landmark decision is DSPT International, Inc. v. Nahum, No. 08-55062, 624 F.3d 1213 (9th Cir. 2010). The facts should sound familiar. A man was hired to help develop a website for a clothing company and registered the domain name in his own name. When he later left to work for a competitor, he took down the company’s website and demanded payment of alleged unpaid commissions before he would return control of the domain. A jury found him liable for bad-faith cybersquatting under the ACPA (the Anticybersquatting Consumer Protection Act, 15 U.S.C. § 1125(d)), and the Ninth Circuit affirmed, holding plainly that “using a domain name to get leverage in a business dispute can establish a violation of the ACPA.” The award was roughly $152,000, covering the company’s actual losses, including lost profits while the site was down. The important point is that the developer’s grievance about money did not matter; using the domain as leverage was the violation.
Behind that ruling sits an even more foundational principle. In Kremen v. Cohen, 337 F.3d 1024 (9th Cir. 2003) — the well-known Sex.com litigation — the Ninth Circuit confirmed that a domain name is a form of intangible property that can be owned and, critically, that can be the subject of a conversion claim. Conversion is the civil wrong of wrongfully exercising control over someone else’s property. Once you accept that a domain name is property, seizing one that belongs to another party and refusing to return it looks a great deal like converting — or simply stealing — something that is not yours.
Why the Contract Clause Does Not Save Anyone
The pay-or-I-keep-it clause is where developers place their confidence, and it is worth explaining precisely why it fails.
A contract can create a debt. It cannot manufacture a right to hold property you are not otherwise entitled to hold. Parties are free to agree that a client owes money for services, and a well-drafted agreement can make that debt easier to prove and to collect. But a private agreement cannot convert the client’s own domain name — the domain built around the client’s business identity — into the developer’s property, and it cannot license the developer to take and withhold it. Courts do not enforce contractual terms that authorize what amounts to self-help seizure of another party’s asset as leverage.
Put simply, the clause changes the analysis of the debt. It does not change the analysis of the domain. Those are two separate questions, and conflating them is the mistake at the center of every one of these disputes.
The Cybercrime Dimension
There is a further dimension that developers who engage in this practice rarely think through, and business owners are often surprised to learn. Transferring a domain name, or changing the registrant of a domain name, without the owner’s authorization is not merely a civil wrong. Depending on how it is carried out, it can expose the person to criminal liability.
I am not an attorney, and nothing here is legal advice. But the relevant framework is worth understanding, because it explains why a police report is a legitimate option and not an idle threat.
Domain theft is frequently analyzed under several bodies of law at once. The Computer Fraud and Abuse Act (CFAA), 18 U.S.C. § 1030, criminalizes accessing a protected computer without authorization or in excess of authorized access. When someone uses registrar account credentials they were not authorized to use, or accesses an account to move a domain they have no authority to move, that conduct can implicate the CFAA. Federal wire fraud, 18 U.S.C. § 1343, reaches schemes to obtain money or property through interstate electronic communications, and domain hijacking — which is executed entirely through internet-connected systems — has been charged as wire fraud. On the civil side, the ACPA discussed above provides a direct cause of action, with statutory damages available in appropriate cases. And most states have their own computer-crime, theft, and extortion statutes; conditioning the return of property on payment of money that is disputed or not actually owed can, in some circumstances, resemble extortion under state law.
Whether any particular statute applies always depends on the specific facts and on how the transfer was accomplished — which is exactly why these matters warrant careful documentation and, where appropriate, review by counsel and by law enforcement. The point for a business owner is that unauthorized transfer of a domain name is treated by the law as the taking of property, and it can be reported as such.
Separating the Two Issues
The way through one of these disputes is to keep two questions rigorously separate, because the party holding the domain has every incentive to blur them.
The first question is the debt. Does the client actually owe the developer money, and if so, how much? That is a contract question, answered by invoices, signed agreements, and payment records — including, as in the situation above, PayPal receipts and bank records. If a genuine balance exists, the developer has legitimate avenues to collect it: an invoice and demand, a collections process, small-claims court, or civil litigation. Those avenues are open regardless of who controls the domain.
The second question is control of the domain name. Who is entitled to be the registrant of a domain built around the business’s own identity? That is answered by the WHOIS record (the public registration record for a domain) and its history, which typically shows a continuous chain of ownership by the business. A real debt does not give anyone a right to seize the domain, and holding the domain does nothing to establish that a debt exists.
When these two questions are kept apart, the outcome becomes clear. The debt, if any, is collected through proper channels. The domain goes back to the business it belongs to.
A Prevention Checklist for Businesses and Domain Owners
If you own a business, the goal is to never be in this position in the first place. The following measures prevent the overwhelming majority of these disputes:
- Register your domain names yourself, in the company’s own name, using a company email address and a company-controlled account at a reputable registrar. Ownership of the domain should never be delegated as a convenience.
- If a developer registers a domain on your behalf, confirm in writing that the company is the registrant and beneficial owner, and get access to the registrar account — not merely a promise that you can have it later.
- Keep the registrar account credentials under the company’s control. Grant your developer delegated access if needed, rather than making the developer the account holder.
- Review your WHOIS records periodically to confirm the company is listed as registrant, and preserve screenshots of the ownership record over time.
- Enable registrar-level security: two-factor authentication, a registrar lock, and — for higher-value domains — a registry lock, which requires manual verification before any transfer.
- Keep every invoice, contract, and payment record. The payment trail is what resolves the debt question, and the WHOIS history is what resolves the ownership question. Both are evidence, and both should be preserved.
- Put the domain-ownership terms in your development agreement in plain language: the company owns the domain, the developer is granted access to perform work, and control returns to the company on request.
What to Do If Your Domain Is Being Held Hostage
If you are already in the situation — your developer, former developer, or vendor is refusing to release your domain — the following steps reflect how I approach these matters:
- Document everything immediately. Capture the current WHOIS record, the WHOIS history showing your prior ownership, all communications, and every invoice and payment record. Evidence assembled early is far more persuasive than evidence reconstructed later.
- Separate the money question from the domain question in your own mind and in your communications. Acknowledge that a debt dispute may exist, if it does, while making clear that it does not justify holding the domain.
- Make a clear, firm, written demand for the return of the domain, addressed to the person holding it, and keep it factual rather than emotional.
- Contact your registrar. Registrars have dispute and account-recovery processes, and if the domain has not yet moved to a different registrar, they may be able to help. If the registrant contact information was changed without your authorization, say so explicitly.
- Consider the UDRP where the domain corresponds to your business name or mark. It is faster and less expensive than litigation and, as the precedent above shows, it favors the rightful business owner in these fact patterns.
- Consider a police report and a complaint to the FBI’s Internet Crime Complaint Center (IC3) where the domain was transferred without your authorization. Unauthorized transfer of a domain name is the taking of property and can be reported as such.
- Consult an attorney about civil claims, including cybersquatting under the ACPA and conversion, particularly where you have suffered losses from downtime or lost business.
- Bring in an experienced domain investigator or consultant. The WHOIS history, DNS records, and transfer trail often contain the evidence that settles the matter, and interpreting them correctly is its own discipline.
The Bottom Line
The belief that a signed “pay me or I keep your domain” agreement is a winning position is not supported by the decisions. The controlling precedent goes the other way, and I could not find a single UDRP decision in which a developer who held a client’s domain hostage over nonpayment came out ahead on that theory. The arbitration panels order the domain returned. The courts, under the ACPA, have gone further and awarded damages. And unauthorized transfer of a domain name can carry criminal exposure on top of the civil liability.
A business dispute over money is a business dispute over money. It is resolved with invoices, records, and, if necessary, a courtroom. It is not resolved by taking control of an asset that belongs to someone else. Whether you are a business owner protecting your most important digital asset or a developer deciding how to handle a client who has fallen behind, the distinction is the whole game — and getting it wrong is far more costly than the invoice ever was.