# How to confirm a domain payment cleared before transferring How a seller confirms funds truly settled before pushing the domain, and how to make verification the safe default step. --- ## How to confirm a domain payment cleared before transferring Domain brokers and sellers sit in a uniquely exposed position at close: they hold the asset and the other party holds the money, and one of them has to move first. The sequence you choose — and how carefully you verify each step in it — determines whether the deal ends cleanly or unravels in a way that is nearly impossible to recover from. This article is about the verify-before-transfer workflow: the specific steps a seller or broker takes to confirm that payment has genuinely settled before a domain leaves the current registrar account. It is not a theoretical discussion. The decisions below are made under real deadline pressure, and getting them wrong on a six-figure name costs in ways no letter of intent will recover. ## Why "payment received" is not the same as "payment cleared" This is the foundational distinction, and conflating the two is the most expensive mistake a domain professional can make. When a buyer sends an ACH transfer, your bank may credit the incoming amount to your account within one to three business days — but that credit is provisional. Because the ACH network is unable to provide real-time authorizations, an authorized payment can be reversed due to insufficient funds, and such reversals typically happen three to five days after the date of the payment. That means you can see a balance, push the domain, and then watch the funds disappear — with no domain left to claw back. Auctioneers and asset professionals should generally prefer wire transfers over ACH transfers in higher-value transactions because wire transfers are final, and ACH transfers are not. The same logic applies to domain transactions. Under the core legal principle in UCC Article 4A, a wire transfer, once accepted by the beneficiary's bank, is final and irrevocable. Section 4A-405 states that once the beneficiary's bank "accepts" a payment order, the payment is final — this is essential for commerce, because businesses need to know that when they receive a wire, the money is theirs and cannot be clawed back. ACH does not carry this protection. Consumers can dispute direct debit payments up to two years after the settlement date, claiming they did not authorize the payment or withdrew their authorization. On a $250,000 domain sale, that exposure window is not a technicality — it is a standing threat. The practical rule for domain transfers: **wire transfer confirmed by your bank = cleared. ACH showing in your account = not yet cleared.** Any other payment method needs to be evaluated against this standard before the domain moves. ## The verification-before-transfer workflow, step by step ### Step 1: Confirm the payment method before the deal closes Verification starts before funds arrive. The payment method needs to be agreed upon in writing as part of the deal terms, not left open-ended. A buyer who insists on ACH, check, or PayPal on a high-value name should prompt a direct conversation about your settlement requirements. When significant assets are involved, risk management outweighs minor transaction expense. The friction of that conversation is nothing compared to the friction of an unwound transfer. For names priced above a threshold you're comfortable with — and most domain professionals draw this line somewhere between $5,000 and $10,000 — wire transfer should be a non-negotiable term. State it in the purchase agreement. Put it in the invoice. Make it part of the conversation the moment a letter of intent is signed. ### Step 2: Verify the wire with your bank directly, not from your online portal Once a wire is expected, the way you confirm it matters. Your online banking dashboard shows an account balance, not a legally verified inbound wire. Call your bank using the number on file — the number you already have — and ask them to confirm that the wire has been received, credited to your account, and that the reference information matches the transaction you're expecting. Make a call to the customer using the phone number on file, not any number provided in the email request, to verify the request. The same principle applies when you're verifying receipt with your own bank: use a known contact channel, not a link or a confirmation email that could theoretically be spoofed. What to confirm in that call: - The exact amount received - The originating bank and, where possible, the originating account or beneficiary reference - That the credit is final and not subject to recall Wire transfers are generally considered final and irrevocable once the receiving bank accepts the funds. In most cases, a fraudulent wire cannot be reversed — only recalled, and only within a narrow window of hours. That recall window is why you confirm immediately upon receiving notice, before you do anything with the domain. ### Step 3: Match the inbound wire to your deal documentation Confirming a wire arrived is not the same as confirming the right wire arrived. On transactions involving multiple parties — a buyer, a broker, a seller, and sometimes a third-party service — funds can be misrouted, sent for a different amount than agreed, or arrive with reference information that doesn't match what was documented. Before you release the domain, you need to verify: - The amount matches the agreed sale price to the cent (or the agreed net amount if any service fees are being deducted upstream) - The wire reference information, if present, corresponds to the deal - The payment hasn't arrived from an unexpected third party, which can itself be a flag Companies should keep a verification record that includes who performed the check, the date, the method of verification, and the contact information used. Storing call logs, confirmation emails, and screenshots of validated instructions helps maintain an audit trail and supports internal controls or future investigations. This documentation is not bureaucratic overhead. On any deal that later becomes disputed, your audit trail is your defense. ### Step 4: Wait on ACH; know the clearing window If the transaction was structured with ACH, you have a mandatory waiting period before the domain should move. ACH payments are processed in batches and typically take one to three business days to complete. But "complete" in that context means posted — not final. The key principle is simple: received funds are not always final funds. A practical ACH verification protocol for domain transactions: - Wait for the payment to fully post (not just appear as pending) - Call your bank and ask them to confirm the ACH has settled and is not subject to return - If your bank cannot give you that confirmation definitively, wait the full standard return window — which can extend beyond the initial posting date - For any name where the loss of the asset would be material, require wire instead The ACH return window exists for legitimate reasons, and sophisticated buyers understand why sellers of high-value digital assets require confirmed wire settlement. If a buyer pushes back on this, that pushback itself should be informative. ### Step 5: If using a third-party settlement service, wait for their disbursement signal — not just their receipt confirmation Many domain transactions route through a dedicated settlement service. In these structures, before transferring the domain, the seller will obtain payment verification — the seller is thereby also protected against credit card fraud, lack of funding, or credit card chargeback. But the critical timing distinction in these workflows is between the service confirming receipt (funds in their account) and the service clearing the payment and authorizing the seller to transfer. Once the settlement service verifies and secures the payment, the seller is instructed to transfer the domain name. That instruction — the explicit signal that payment is verified and secured — is the trigger for transfer, not the notification that the buyer has submitted payment. Those are two different events that can be separated by hours or days depending on how the buyer funded. Never transfer a domain before payment is secured. The service's receipt confirmation is not payment security. Their explicit transfer instruction is. ## How the transfer method affects the verification timeline Once payment is verified and you're cleared to release the domain, the transfer method you use determines what a clean delivery looks like and how quickly the buyer can confirm receipt. This matters because in structured transactions, disbursement to the seller — and to any broker or advisor splitting the proceeds — doesn't happen until delivery is confirmed. ### Registrar push (same-registrar transfer) A registrar push moves the domain to the buyer's account at the same registrar, usually within minutes. This is the fastest and cleanest delivery method when both parties hold accounts at the same registrar. The buyer can verify receipt almost immediately, and a WHOIS lookup reflecting the new registrant can be confirmed within minutes to hours depending on the registrar's propagation speed. For the seller, push transfers also avoid a material operational risk: 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. A registrar push does not trigger this lock. To avoid the inter-registrar transfer lock, you can push the domain to another account within the same registrar. This means that if the deal closes and payment is verified, a push completes the delivery without starting a 60-day clock that would prevent the buyer from immediately moving the domain to their preferred registrar if they choose to. ### Registrar-to-registrar transfer (EPP/auth code) A registrar-to-registrar transfer uses an auth/EPP code and can take a few days. Typically, it takes 5-7 days for a transfer to complete automatically. However, if the buyer manually approves the transfer at the losing registrar's end, the procedure often completes within a few hours. The EPP (Extensible Provisioning Protocol) code functions as your domain's transfer password. Also called an authorization code, auth code, or transfer key, this unique alphanumeric string typically contains 8-16 characters generated by your current registrar. Think of it as a security token that proves you have permission to move the domain. The mechanics of releasing an EPP code require that the domain is unlocked first. The ClientTransferProhibited status, commonly called a "registrar lock," represents a security setting you control through your registrar's interface. Unlike the 60-day locks mandated by ICANN policy, you can toggle this lock on or off at any time through your domain management panel. When enabled, ClientTransferProhibited prevents all transfer requests from processing, even if someone obtains your EPP authorization code. The EPP code itself has a finite validity window. Some codes expire in 7-30 days. If your deal timeline extends — payment delays, buyer financing complications, extended negotiations on the purchase agreement — regenerate the EPP code close to the actual transfer date so it's current when you need it. Unlock your domain at your current registrar before initiating the transfer. The transfer process requires both the correct EPP code and an unlocked domain status. Having one without the other results in transfer failure or delays. ### The 60-day lock and what it means for deal timing If the domain you're selling was recently registered, recently transferred into your registrar account, or had registrant contact information updated: ICANN policy mandates a 60-day transfer lock immediately following new domain registration or a recent transfer. When you register a brand new domain, you cannot transfer it to a different registrar until 60 days have passed from the registration date. This lock is absolute — no registrar can override it, and no exceptions exist regardless of circumstances. This is a fact that must surface before deal close, not after. If you are brokering or representing a seller and the domain is inside a 60-day lock window, you have two choices: structure the deal with a push transfer if the buyer will accept the same registrar, or set the buyer's expectation that the domain cannot move to a new registrar until the lock expires. Discovering this constraint post-close, with payment in hand and a buyer demanding delivery, is a position no professional wants to be in. After a new registration or a prior transfer, ICANN can impose a 60-day lock that blocks a registrar-to-registrar move. In that case, use a push within the same registrar, or agree to a hold until the lock clears. Set the expected transfer method and window when you open the deal so both sides are aligned. ## Verifying delivery: confirming the domain actually landed After you push or initiate the EPP transfer, your job is not finished until you have independent confirmation that the domain arrived where it was supposed to. In deals with structured settlement arrangements, one way to verify delivery is by checking the WHOIS database of the appropriate registrar to confirm it properly reflects the new buyer's name as the domain registrant. A WHOIS lookup confirms that the domain was actually transferred to the registrar account. Run this check yourself. Do not rely solely on the buyer's confirmation that they received it, particularly in transactions where you haven't worked with this buyer before. The WHOIS record is an independent, publicly verifiable source of registrant data that neither party controls in real time. For push transfers, WHOIS update propagation can take anywhere from a few minutes to several hours depending on the registrar's systems. For EPP transfers, WHOIS won't reflect the new registrant until the transfer is complete, which may take the full 5-7 day window. Structure your settlement process to accommodate that timeline — particularly if payment disbursement to any party is triggered by confirmed delivery. ## Splitting proceeds at close: getting everyone paid at the same time In domain transactions, the money rarely flows to one wallet. A broker who sourced the deal has a commission. A seller has their net. In some transactions, multiple advisors, co-brokers, or referral arrangements are in play. The conventional approach — receive funds centrally, then manually wire each party — introduces its own timing risk and creates a gap between when the deal closes and when everyone actually gets paid. This is exactly where Shaka fits. The professional who closes the deal builds the payment link in advance: recipient wallets, split percentages, and any tiered amounts are all defined before the buyer funds. When payment clears and the deal closes, every party is paid in a single transaction — directly to each wallet, simultaneously, with no manual disbursement step required. The broker doesn't wait for the seller to wire their commission. The seller doesn't wait for the broker to reconcile. The deal closes and the money lands, in the right proportions, instantly. The professional stays in control of how funds distribute without being the bottleneck that delays it. ## A real scenario: what a clean close looks like A $180,000 domain sale. The broker negotiated the deal, has a 10% commission, and the seller nets $162,000. The buyer is wiring from a US bank. **Day 1:** Wire is expected. Broker confirms with buyer that wire will include a deal reference number. **Day 1, afternoon:** Bank portal shows incoming credit. Broker calls the bank directly, confirms the amount is $180,000, the originating institution matches, and the wire is accepted — not just posted provisionally. Bank confirms finality. **Day 1, afternoon:** Broker verifies the amount matches the purchase agreement to the cent. Documentation logged. **Day 1, late afternoon:** If the transaction is running through a settlement service, broker waits for the service's explicit transfer instruction. If the broker is managing the transfer directly, they proceed. **Day 1, close of business:** Broker confirms the domain is unlocked, EPP code is current. Checks WHOIS to confirm no lock periods are active and registrant data is clean. If buyer has an account at the same registrar, initiates a push. If not, releases EPP code to buyer. **Day 1-3:** For push, WHOIS confirms new registrant within hours. For EPP transfer, broker monitors and buyer manually approves to accelerate completion. **Transfer confirmed:** Payment is released or disbursed. With a properly structured payment link, both the seller's net and the broker's commission move simultaneously — no manual wires, no waiting for the other party to send their portion. The clarity at every step — payment method defined in advance, verification performed against the bank directly, transfer method chosen based on lock status, delivery confirmed via WHOIS — is what separates a professional close from a stressful one. ## The verification step is not optional for high-value names The temptation to skip or shortcut payment verification increases as deal velocity increases. A motivated seller wants to close. A motivated buyer who has just wired funds is impatient to take control of their asset. There is social and commercial pressure to move the domain the moment payment is sent. The closing agent who sends a wire to a fraudulent account has, under the law, completed a final payment — regardless of the fraud that caused it. This is precisely why prevention and verification before the wire is sent is the only legally reliable protection. The same logic applies in reverse: the seller who transfers the domain before payment is truly cleared has completed a final transfer — regardless of the bank's subsequent reversal of the ACH. The domain cannot be recalled the way an uncleared payment can be. The asset moves first and permanently. That asymmetry is why verification is not a formality — it is the mechanism by which the deal is actually closed rather than merely appearing to be. Build the workflow before the deal is on the table, so that when close-day pressure mounts, you are executing a pre-defined checklist rather than making judgment calls under stress.