# How to structure a safe handover when selling a domain

The concrete order of operations for a domain deal handover — how to sequence payment confirmation, domain unlock, auth code release, and push or transfer so both sides are protected and the deal closes clean.

---


## How to structure a safe handover when selling a domain
Every domain deal reaches the same inflection point: terms are agreed, both parties are ready, and the question becomes mechanical — who does what, in what order, and when does the money actually move? Get the sequence right and the handover takes days, sometimes hours. Get it wrong — or worse, improvise it under pressure from an impatient buyer — and you end up chasing a domain that's already gone, or a seller who's waiting indefinitely on funds that are stuck in a manual payment queue somewhere. The broker's job is to close the deal, not to discover sequencing problems mid-transfer. This article lays out the full order of operations for a domain handover, including what changes depending on the transfer method, how each step interacts with the one before it, and where the payment side of the transaction has to be airtight before the asset side can move.

## Why sequence is everything in a domain handover

Unlike the sale of a physical good, a domain name transfer is simultaneously a financial transaction and a technical one, and those two tracks have to be coordinated precisely. The financial track — payment cleared, funds confirmed — must complete, or reach a verifiable in-transit state, before the technical track begins. The technical track — unlock, auth code, push or transfer, confirmation — must complete before any payment held in a pending state is released to the seller.

If the domain is held at the same registrar as the buyer's intended account, the process is a push transfer — moving from one account to another within the same registrar. If the registrars are different, you're doing an authorization code (EPP) transfer. These two paths have meaningfully different timelines and risks, which means the handover sequence isn't identical in every deal. Understanding which path you're on at the start of the transaction — not after funds are received — is one of the first things to confirm.

Timing coordination is critical. Authorization codes expire, sellers become unresponsive, and delays can jeopardize entire transactions. A domain broker who doesn't control the clock on each step is at the mercy of both parties' attentiveness and their registrars' response times.

## Step one: Confirm eligibility before anything else

The handover sequence starts before payment is requested, not after. The first thing to verify is whether the domain can actually be transferred at the moment the deal is expected to close.

ICANN enforces a mandatory 60-day lock period following specific domain events — this restriction applies after initial domain registration, after transferring a domain between registrars, and after changing the domain's registrant contact information. This is not a registrar policy that can be waived by calling support. This lock is absolute — no registrar can override it, and no exceptions exist regardless of circumstances.

The ClientTransferProhibited status, commonly called a registrar lock or domain lock, is a security setting the owner controls through their registrar's interface. Unlike the 60-day ICANN locks, this can be toggled on or off at any time through the domain management panel. These are two separate and independent blockers — both have to be clear for a transfer to proceed.

Practically, this means the broker needs to confirm three things from the seller before any payment is structured or requested:

First, check the registration date or last transfer date. A domain cannot be transferred to another registrar if it is under a 60-day ICANN security lock — this lock is automatically applied whenever a domain is newly registered, previously transferred, or if the registrant's WHOIS contact information is updated. If the domain is within that window, the buyer must wait or, as a workaround, the seller can push the domain within the same registrar to a neutral holding account if the buyer has an account there — internal pushes do not trigger the 60-day transfer lock. You can push a domain immediately after registering it, after receiving it in a previous push, or after updating contact information. This makes account pushes ideal for domain sales where you need immediate ownership transfer without waiting periods.

Second, verify that no WHOIS registrant information changes are pending. You cannot transfer a domain name to a different registrar within 60 days of making changes to the registrant name, organization, or email address. This is a common trap when a seller has recently updated their contact details — the 60-day clock resets.

Third, confirm the domain is not subject to any legal hold. A registrar must deny a transfer request in the event of a pending UDRP proceeding that the registrar has been informed of, a court order by a court of competent jurisdiction, or a pending dispute related to a previous transfer. Premium domains are more likely to have trademark sensitivity or active disputes attached, so diligence here is proportional to asset value.

Once eligibility is confirmed, you can structure the payment side with confidence.

## Step two: Structure and confirm payment before unlocking anything

Nothing on the technical side of the handover moves until payment is secured. This is the non-negotiable anchor of the sequence, and it protects both parties.

Premium domains — typically valued at $10,000 or more — require professional handling to protect both parties from fraud. The process adds complexity: buyers deposit funds, sellers provide authorization codes and initiate the move, and payment is released only after confirming successful completion.

The practical implication for the broker is this: the seller does not unlock the domain, does not generate an auth code, and does not push anything until there is a confirmed, irrevocable record that funds are in transit. "I've sent the wire" is not that confirmation. A wire reference number is not that confirmation. The confirmation is a verified, in-process record from the payment or settlement mechanism you're using — at which point the transfer sequence can begin.

For domain sales, do not initiate the transfer until payment is confirmed — this prevents the situation where you need to cancel.

This is also where a deal involving multiple recipients — a broker commission, a co-broker split, a referring agent's cut — has to be structured before any funds move. If the gross sale price is $75,000 and the broker's commission is 15%, that's $11,250 coming off the top, with $63,750 going to the seller. If there's a co-broker sharing that commission 50/50, each side receives $5,625. Those splits need to be encoded into the payment structure before settlement, not chased after the fact. Trying to manage a three-way split through sequential manual transfers after receiving a single lump sum is how commission disputes start. Shaka lets the broker set those recipient wallets and percentages upfront, so when payment lands, every party gets their share in the same transaction — the deal closes, and everyone is paid simultaneously without a second round of transfers.

## Step three: Unlock the domain

Once payment is confirmed and in process, the seller unlocks the domain.

Most registrars apply the registrar lock automatically when a domain is registered or transferred. While it provides essential security protection, it must be manually disabled before initiating a transfer. The process varies by registrar — some offer a simple toggle switch in the domain management panel, while others require contacting support.

After unlocking, the change propagates through the registry system within minutes to a few hours. You can verify the lock status by checking the domain's EPP status codes through any WHOIS lookup service — look for the absence of ClientTransferProhibited in the status field before proceeding.

Do not request the auth code at the same time as unlocking, or before confirming the unlock has propagated. Some registrars — GoDaddy being the most notable — sometimes require a 24-hour wait after unlocking before the auth code becomes usable. If you generate the auth code before the unlock has fully processed, you may get a valid-looking code that the receiving registrar will reject. That wastes a day while everyone waits for a fresh code.

## Step four: Generate and deliver the auth code — with timing discipline

The Auth-Code (also called an Authorization Code, Auth-Info Code, or transfer code) is created by a registrar to identify the domain name holder. It is required for a domain holder to transfer a domain name from one registrar to another.

Auth codes expire — most are valid for only 24 to 72 hours at many registrars. Request a fresh code immediately before initiating the transfer at the new registrar. Some registrars generate codes with longer validity windows, but the safe professional practice is to treat every auth code as if it expires in 24 hours. Generate it when the buyer is ready to enter it immediately — not the day before, not on a Friday afternoon before a weekend.

Check that the domain is fully unlocked — some registrars take hours to process the unlock before the auth code becomes valid. Some registrars send the auth code to the WHOIS registrant email — ensure that inbox is accessible before unlocking.

The auth code goes directly to the buyer (or to their broker, who relays it). It is not published, not included in an email thread with multiple recipients, and not shared through unsecured channels. Treat EPP codes like passwords — keep them secure and only share when actively transferring. An auth code in the wrong hands allows anyone to initiate a transfer. Unauthorized access to an EPP code enables domain hijacking. An attacker with the code can initiate a transfer to a different registrar. Once transferred, recovering the domain requires legal action, proof of ownership, and potentially weeks or months of dispute resolution.

If for any reason the transfer doesn't proceed immediately after the auth code is shared, regenerate a new one. If you shared a code with someone for a transfer that ultimately didn't proceed, generate a new code to ensure the old one can't be used later without your knowledge.

## Step five: The buyer initiates — push versus EPP transfer

Now the buyer acts. What they do depends on the transfer method agreed at the start.

### Same-registrar push

Use account push when both parties have accounts at the same registrar. Pushes are instant, free, and bypass EPP requirements entirely. If you're selling a domain and the buyer can create an account at your registrar, pushing is simpler than transferring.

A push is the cleanest and fastest handover mechanism in a domain deal. The seller initiates from their account, designates the buyer's account by username or email, and the domain appears in the buyer's account — often within minutes. Transferring domain ownership between two users at the same registrar requires just a few clicks and completes immediately.

The broker's job here is to coordinate registration — confirm the buyer has an account at the correct registrar, or facilitate the buyer creating one, before the payment confirmation step. Nothing stalls a push faster than discovering the buyer has no account at the seller's registrar and needs to sign up before the seller can execute.

### EPP (inter-registrar) transfer

When buyer and seller use different registrars, the formal transfer process applies. Transferring a domain from one registrar to another follows the formal ICANN transfer process with multiple verification steps and a multi-day timeline.

The buyer enters the auth code at their receiving registrar to initiate the transfer. The receiving registrar sends a transfer request to the current registrar, which then has up to five days to approve or deny the request. Both the current owner and the receiving party receive verification emails during the transfer process. Responding to these emails or using manual approval options at the losing registrar accelerates transfer completion.

For most domain extensions, a transfer between registrars will take five to seven days from the time you authorize it. Some country-code domain names may take longer to process or require additional steps.

This waiting period is one of the most operationally sensitive moments in the deal. The seller has given up control of the auth code. The buyer has initiated the transfer. Neither party can do much except wait — and during that window, the broker needs both sides to be responsive to their email. Both parties receive verification emails. Responding to these emails or using manual approval at the losing registrar accelerates transfer completion — without manual intervention, transfers typically complete within five to seven days through automatic approval.

Tell the seller explicitly: when you receive a transfer-out confirmation email from your registrar, approve it immediately. Every hour of delay on a transfer-out approval is a day added to the timeline in practice.

## Step six: Buyer confirms receipt, payment releases

Once the domain is in the buyer's account, the buyer confirms receipt. This is not a formality — it is the trigger for final payment release.

Once the domain is transferred, the buyer typically has a set amount of time to inspect the domain and asset transfer. If there are issues between the buyer and seller, they can be facilitated at this stage. After the buyer confirms that they're satisfied with the domain name, they notify the payment service and funds are released to the seller to finalize the transaction.

The buyer's inspection window typically runs five to seven days. In the vast majority of domain deals, nothing goes wrong here. The domain arrives, the WHOIS reflects the buyer as new registrant, and they confirm. But the broker should set clear expectations with both parties at the start of the deal: the inspection window is not an opportunity for buyer's remorse, and a domain not confirmed within the specified window will auto-close per the deal terms. Without that framing, some buyers treat the inspection period as a renegotiation window.

The domain's DNS settings — nameservers, A records, MX records — remain active during transfer. Website and email continue working throughout the transfer period. This matters when the domain is in active use. A buyer taking over a live domain should not expect any downtime during the transfer itself, though they should be aware that not all registrars automatically migrate DNS records, and recreating complex configurations incorrectly can take the website and email offline. Alerting the buyer to this possibility before they initiate any DNS changes after receipt is part of a clean handover.

## Special scenario: The domain can't transfer yet — working around the 60-day lock

Occasionally a deal closes while the domain is still within its ICANN 60-day lock window — perhaps it was recently acquired by the seller, or they updated their registrant contact recently. The deal is real, the buyer is ready, but the transfer can't proceed between registrars.

One workaround is to push the domain to another account within the same registrar. If the buyer is willing to create an account at the seller's registrar, the seller can push the domain immediately — no lock applies to same-registrar pushes. The buyer then holds the domain at that registrar until they want to transfer to their preferred provider after the 60-day window clears, which they can do independently.

This is a practical solution that serves both parties. The seller has delivered the asset. The buyer has ownership. Payment can release. The buyer's subsequent transfer to their own registrar is a separate, post-deal event that doesn't involve the seller or the broker.

ICANN specifically advises: if the ultimate goal is to transfer the domain name, consider completing the transfer process before changing contact information. For a broker managing repeat seller relationships, this is worth building into the pre-deal checklist — don't change WHOIS contact details on a domain you're about to sell without understanding what it triggers.

## The multi-party payment problem at closing

The mechanics above describe the domain handover. But in most professional domain deals, "the seller gets paid" is actually shorthand for a more complex disbursement: the seller receives their net proceeds, the broker receives their commission, and in deals with co-brokers or referral arrangements, additional parties need to be paid simultaneously.

In sell-side representation, the seller pays the broker from their proceeds. Some high-value deals involve split commission structures where both parties contribute. A $250,000 domain sale with a 10% commission, split 50/50 between a sell-side and buy-side broker, means $125,000 to the seller, $12,500 to one broker, and $12,500 to another — all from the same closing event.

The traditional workflow is to receive the gross proceeds into one account and then execute three separate outbound transfers — one to the seller, one to each broker. Each transfer has its own banking friction: wire fees, processing time, potential holds. More practically, each transfer is a new opportunity for an error — wrong account number, wrong amount, a recipient who's traveling and not monitoring their inbox. On large deals where speed matters, this friction isn't trivial.

This is where Shaka belongs in the domain broker's toolkit. Rather than collecting a lump sum and disbursing it manually, the broker configures the deal's payment link with each recipient's wallet address and their share percentage before anything is sent. When the buyer's payment arrives, it routes automatically — the seller's 90% and the broker's 10% land in separate wallets in the same transaction. If there are two brokers, each gets their share. There are no follow-up wires, no waiting on bank processing, no post-close arithmetic. The broker closes the deal; Shaka handles how the money lands.

## What a clean handover actually looks like in practice

To make this concrete: a $180,000 domain deal between a U.S. seller on GoDaddy and a European buyer on Namecheap, brokered by a single domain broker at 12% commission.

The broker confirms eligibility first — the domain was registered 18 months ago, no recent registrant changes, not involved in any proceedings. The registrar lock is active. WHOIS shows it's free to transfer.

Payment is structured: $180,000 gross, $158,400 to the seller, $21,600 to the broker. Those destinations are set in the payment link before it's sent to the buyer.

The buyer's payment is confirmed. The seller unlocks the domain in GoDaddy's dashboard, waits a few hours, then generates a fresh auth code and delivers it securely to the buyer. The buyer initiates the transfer at Namecheap. The GoDaddy confirmation email arrives in the seller's inbox; the seller approves it immediately rather than waiting for the five-day auto-approval. Transfers typically take 5-7 days to complete, but the seller can help the process by approving the transfer promptly.

Three days later, the domain appears in the buyer's Namecheap account. The buyer confirms receipt. Payment releases. Both the seller and the broker are paid simultaneously, directly to their wallets.

No one chased anyone. No one waited a week for a wire. The broker didn't have to manually send a second transfer for their own commission. The deal is done.

## What goes wrong and how to prevent it

**Auth code delivered before payment is confirmed.** This is the single most common sequencing error in DIY domain deals. The auth code is the key to the domain — once transferred, you cannot reverse the transfer without the buyer's cooperation. Never release it before payment confirmation is in hand.

**Domain locked at the start of the inspection window.** Some sellers unlock the domain, hand over the auth code, and then re-lock it — either accidentally or because they're nervous about the delay. A locked domain during an active transfer causes the EPP process to fail partway through. Once you've unlocked and initiated the transfer, leave the domain unlocked until the transfer completes.

**Auth code expires mid-transfer.** The buyer entered the code, then their new registrar had a processing delay. By the time the transfer formally initiated, the code had expired. The seller has to generate a new one. Auth codes expire — most are valid for only 24 to 72 hours. Request a fresh code immediately before initiating. Don't generate the code until the buyer is at their keyboard, ready to enter it.

**Verification email goes unanswered.** Both the seller's and buyer's registrar will send confirmation emails during the EPP process. If either party misses or ignores one, the transfer stalls or fails. Set expectations explicitly: watch for these emails and respond within hours, not days.

**Post-close payment chasing.** The broker completes the handover, the seller is paid, and the broker is waiting on a manual transfer of their commission. This is operational and reputational risk. Structuring payment disbursement upfront — before the deal closes — eliminates this entirely.

A domain handover is not complicated when the sequence is respected. Confirm eligibility, secure payment, unlock, generate the auth code at the right moment, initiate the correct transfer method, manage the email confirmation loop, and release payment on buyer acceptance. Every step depends on the one before it. The broker who controls that sequence is the one whose deals close cleanly, whose clients repeat, and who gets paid without chasing. The mechanics aren't magic — they're discipline.