How to refund an onchain payment if you need to
Onchain payments are final — that is the whole point of using them. But finality does not mean the money can never move again, and any professional who routes payments for a living will eventually face a situation where funds that have already settled need to go back to where they came from. A deal falls apart after a commission has been disbursed. An overpayment lands in the wrong proportion. A co-broker relationship dissolves mid-transaction and a pre-paid advisory fee needs to be returned. The mechanics of how you handle that return matter enormously, both for the relationship and for your books. This article is the practical guide: what a voluntary onchain refund actually is, how you execute one cleanly, what the edge cases look like, and how to stay protected at every step.
What “refund” actually means onchain
Before anything else, you need to discard the mental model that comes from traditional payment rails. When a card transaction is refunded, the original payment is reversed — the network unwinds it, credits the account, and the ledger treats it as if the transaction never fully settled. In crypto, a refund is simply a new payment going the other direction, initiated at the recipient’s discretion. The original transaction is not undone. It cannot be. On public ledgers, coins move irreversibly between addresses. That is why “chargeback” in a crypto context is shorthand for provider policies that credit a customer’s balance or send a compensating transaction after a dispute.
The practical consequence of this for you as a professional is significant. When you return funds onchain, you are generating a brand-new transaction — with its own transaction ID, its own timestamp, and its own permanent place in the ledger. For a legitimate return, the process is straightforward: you ask for a return address and send a new transaction. The refund has its own TXID for reconciliation. Two transactions now exist where one did before, and your recordkeeping needs to reflect that clearly.
This also means there is no mechanism that compels you to return funds. Although crypto transactions cannot be reversed, they can be refunded by the recipient, but this requires the recipient’s voluntary cooperation. You are not a bank. No one can reach into your wallet and pull the money back. If you decide to return funds, that is a decision you make and act on — which is precisely why the workflow around that decision matters more, not less, than it does in traditional finance.
When does a refund situation actually arise for dealmakers?
For brokers, attorneys, advisors, and anyone else who structures and receives payments in a deal context, the scenarios that require a voluntary return are narrower than you might expect — but when they happen, they tend to involve real money and real relationships.
The deal falls apart after disbursement. This is the scenario most professionals worry about. Commission structures vary, but it is not uncommon in complex deals for advisory fees or finder’s fees to be wired at signing rather than at closing. If the underlying transaction then collapses — a financing contingency triggers, a title issue surfaces, a counterparty exercises a termination right — the question of whether that advance payment must be returned falls back to the terms of the engagement agreement. Various contingencies in a purchase agreement allow either party to withdraw from a deal under specific conditions, influencing whether money is refunded or forfeited. The same principle applies to your engagement terms. If your fee agreement is contingent on closing, and the deal does not close, you owe the funds back regardless of what payment rail was used.
Overpayment. A buyer sends too much. A split is calculated incorrectly. A disbursement that should have been $47,500 arrives as $50,000. If an invoice is for 9,500 USDC and the counterparty accidentally sends 10,000 USDC, the clean resolution is to retain the correct amount and refund the 500 USDC overpayment back to the same — or a confirmed alternate — address. This sounds simple, and operationally it is. The complexity is in the documentation, not the mechanics.
An incorrect split was set. In multi-party deals — where a lead broker, a co-broker, a referring party, and possibly legal counsel are all being paid from a single closing — the split percentages need to be right before the transaction is sent. If a payment goes out with the wrong distribution, the party who received too much is effectively holding funds that belong to someone else. Returning the excess is not optional from a professional standpoint; the mechanics of how you do it onchain are what this article is for.
A relationship unwinds mid-deal. Co-brokerage arrangements, referral agreements, and advisor engagements sometimes break down before the deal closes. If a retainer or advance fee was paid onchain and the engagement subsequently terminates, the refund workflow applies directly.
The mechanics: how to actually execute a voluntary onchain refund
Step one: confirm the destination address before touching anything
This is where most refund errors happen, and an error here is not recoverable. Sending to the wrong address or network can mean permanent loss of funds. Before you initiate any return transfer, you need to confirm — in writing, through a separate channel from the original payment conversation — the exact wallet address where the funds should go.
Do not assume you can send back to the address from which the original funds arrived. In many professional contexts, wallets are single-use or managed by a treasury function, and the address that sent the payment may not be the right address to receive a return. Ask explicitly. Get a written confirmation of the address. Then check it against the blockchain explorer to confirm it is active on the correct network.
The network question matters. USDC on Ethereum is not the same thing as USDC on Base or USDC on Solana. Sending stablecoin to the right address on the wrong network is functionally the same as sending it to a wrong address. If the counterparty’s wallet is a Solana address and you send from an Ethereum wallet, the funds will either fail to arrive or land somewhere inaccessible. Confirm the network explicitly, even if it feels pedantic.
Step two: determine the exact amount and asset
For stablecoins used as USD-equivalents, most professional payment flows keep it simple: return the same stablecoin and the same unit amount. If you received 15,000 USDC and you are returning the full amount, you send 15,000 USDC. Do not subtract a convenience fee. Do not offer to pay in a different asset. Unless your engagement agreement specifically addresses these alternatives, the clean professional move is to return what was received, in the same form.
Partial refunds work the same way. If you are returning an overpayment of 2,500 USDC on a correctly received base amount of 22,500 USDC, you send 2,500 USDC and note the reason in the accompanying documentation. In your internal records, mark the original payment as partially refunded and note a corresponding credit in your accounting system.
One practical note on gas fees: when you initiate an onchain return, the outgoing transaction carries a small network fee paid from the sending wallet. This is not a deduction from the refund amount — it is a separate cost of sending the transaction. The recipient receives the full amount you specify. If your wallet is running low on native token (ETH, SOL, or whichever chain you are on), top it up before initiating the transfer.
Step three: execute and capture the transaction ID immediately
Once you send the transaction, capture the TXID from your wallet immediately. This is the onchain fingerprint of the refund — the permanent, publicly verifiable proof that the funds moved. Voluntary crypto refunds can be nearly instantaneous since they’re just new transactions from the sender. Settlement does not take days. The counterparty will be able to verify receipt within minutes by checking the TXID on a block explorer.
Document the TXID in every relevant place: your deal file, your accounting system, and any correspondence with the counterparty confirming the return. This is not bureaucratic overhead — it is the professional standard of proof that the return was made.
Step four: document the refund in writing, formally
This step is the one that separates a clean professional return from a messy one. An onchain refund is a one-way transfer that, once sent, cannot be reversed. You need a paper trail that establishes why it was sent, what it covers, and what it resolves.
Send a formal written notice to all relevant parties: the counterparty who is receiving the funds, any co-professionals involved in the deal, and your own compliance or accounting function if you operate inside a larger firm. The notice should include the original transaction reference (the TXID of the initial payment), the refund TXID, the exact amount and asset returned, and a one-sentence statement of the reason — “Return of advisory retainer per Section 4 of the engagement letter dated [date], transaction did not close” or “Return of overpayment on co-brokerage commission, deal ref [reference number].”
A clear, written policy protects you legally and gives your counterparties predictable expectations. Even if you operate as a solo practitioner, maintaining a written record of every refund — the trigger, the amount, the address, the TXID — is what protects you in the event of a later dispute about whether funds were returned and when.
The split-payment refund: the scenario that catches most people off guard
When payments are structured across multiple recipients — a split commission where one amount goes to the lead broker, another to a co-broker, another to a referral party — a refund is not a single action. It is a coordination exercise.
Consider a deal that generated a $90,000 commission split as follows: $54,000 to the lead broker (60%), $27,000 to the co-broker (30%), and $9,000 to a referring advisor (10%). All three payments went out in a single transaction at closing. The deal subsequently unwinds within a contractual rescission window, and the commission must be returned in full.
Each recipient is now independently responsible for returning their portion. There is no mechanism to reverse the original multi-party transaction. The lead broker sends back $54,000. The co-broker sends back $27,000. The referring advisor sends back $9,000. Each produces their own TXID. The party coordinating the refund — typically the closing attorney or the lead broker — collects all three TXIDs and assembles a consolidated return confirmation for the client’s file.
This is operationally heavier than a single-party refund, and the coordination risk is real. If one party delays or disputes whether they owe a return, the other parties’ funds are already back in transit while that conversation plays out. The best protection against this scenario is not reactive — it is proactive. Engagement agreements in multi-party deals should specify explicitly what happens to disbursed commissions in the event of a post-closing rescission. The more precisely that is written in the agreement before the deal closes, the less friction there is if the deal later unwinds.
When Shaka is used to route the original payment — with split percentages set in advance and funds moving simultaneously to each wallet — each recipient can see exactly what they received and from which transaction. That transparency makes the refund coordination straightforward: everyone knows their number, and the refund confirmations map directly back to the original split.
Confirming receipt and closing the loop
You have sent the refund and you have the TXID. Do not stop there. Follow up in writing with the recipient and ask for written confirmation that the funds have arrived and that the return is accepted as complete. This closes the loop formally.
In a deal context, an unclosed refund loop is a liability. If the other party later claims they did not receive the funds, or that the amount was wrong, and you cannot produce both the TXID and a written acknowledgment of receipt, you are in a dispute. Get the acknowledgment, even if it is just a reply email that says “Confirmed, received $27,000 USDC on [date], TXID [hash], account settled.”
Refunds for stablecoin payments are returned to the originating wallet as stablecoins and typically arrive within minutes. There is no good reason the loop should take longer than a few hours to close, including the back-and-forth of confirmation. If it is taking longer, something is wrong: either the address was incorrect, the wrong network was used, or the recipient has not checked their wallet. Follow up directly.
The partial refund: overpayment and mid-deal adjustments
Partial refunds are more common than full-deal reversals and deserve their own practical treatment. An overpayment of even a few thousand dollars on a large transaction needs to be handled with the same rigor as a full refund, because the documentation requirements are identical.
When you process a partial refund, your internal ledger needs to clearly reflect three numbers: the original amount received, the amount being returned, and the net amount you are retaining. The hard part in a partial refund is the ledger: tracking original amount, refunded amount, and net amount, then matching against the deal record. Fail to do this cleanly and your books will show a payment received that does not match your fee schedule, which creates problems when your accountant reconciles against the deal file or when you are subject to a trust account audit.
For practical reference: if you received $52,000 USDC as a brokerage commission and the correct amount was $50,000, you return $2,000 USDC and your ledger should show: Original receipt $52,000 USDC, TXID [hash]; Partial refund $2,000 USDC, TXID [hash]; Net retained $50,000 USDC. That is what goes in the deal file, what goes to your accountant, and what you reference if either party ever asks about the transaction.
When a counterparty refuses to accept a return
This situation arises less often than you might think, but it does arise — usually in the context of a disputed deal termination where one party believes the commission is earned and the other party is demanding it back. The onchain refund workflow does not resolve that underlying dispute. It is the mechanism you use once the dispute is resolved.
To receive a refund, the paying party must cancel the underlying agreement according to valid contractual terms and within the specified timeframe. The escrow holder or the professional holding the funds then releases them once both parties sign a release agreement or the cancellation terms are legally resolved. The same principle applies in an onchain context: the refund is the final act, not the beginning of the resolution. The resolution happens through your engagement agreement, through your legal counsel, and through professional negotiation. Once that process is complete, the onchain return is simply how the funds move.
Do not send a voluntary onchain refund while a dispute is still active and unresolved unless you have legal advice to do so. An onchain transfer is final, and sending a partial return during a live dispute can be construed as an acknowledgment of liability that complicates your position.
Accounting and tax treatment of a returned payment
This is not tax advice, and your accountant or CPA should weigh in on the specifics for your jurisdiction. But as a practical matter, a refund of a previously recognized fee is not a simple deletion of income — it is typically a reduction of income or an expense, depending on your accounting method and when the original fee was recognized. If the original payment and the refund occur within the same tax period, the net is straightforward. If they straddle different tax periods, the treatment is more nuanced.
If your records show a dollar-denominated invoice, your accounting system holds stablecoin, and a refund moves in the other direction, you need an audit trail that explains every step. Otherwise the payment may be fast and still create month-end pain. Document the refund TXID, the valuation of the returned amount in fiat terms at the time of the transaction, and the reason for the return. Give all of this to your accountant at the time it happens, not at year-end.
Building a refund policy before you need one
The cleanest refunds are the ones where everyone already knew what would happen if a return was required. Every professional who moves money in a deal context should have a written position on refunds embedded in their engagement agreements, not improvised at the moment a deal unravels.
Start by documenting a policy that covers the scenarios in which you will issue refunds and how. Key elements include overpayments, duplicate payments, cancelled deals, and failed delivery situations. The agreement should specify the timeframe within which a refund claim must be raised, the format in which the return will be made (same asset, same network, to the originating wallet unless otherwise confirmed in writing), and any situations in which fees are non-refundable.
This is not about being defensive. It is about being professional. Ensuring that fee agreements explicitly outline the conditions for refunding gives all parties protection. Documenting communications with counterparties provides added security when disputes arise. A clear written policy means that when a deal falls apart at 10pm and someone sends an urgent message asking for their money back, you can point to a document rather than making the decision under pressure.
The professionals who handle refund situations well are rarely the ones who react fastest. They are the ones who set the terms clearly at the front end, document everything as the deal progresses, and execute the return with the same precision they brought to the original payment.
That is the standard. The mechanics of onchain payments — transparent, traceable, and permanent in both directions — make that standard both reachable and verifiable.
