How Does Mercari Pay Sellers? Release Rules, Fees, and Withdrawals
Mercari seller payments involve two separate steps: releasing earnings after transaction completion and withdrawing the available balance. Here is how the US payout process works—and where timing, fees, and eligibility matter.
Mercari pays US sellers by releasing earnings into their Mercari balance after the transaction’s rating process is complete. Sellers can then withdraw available funds through free ACH direct deposit to a bank account or fee-based Instant Pay to an eligible debit card. A sale is therefore not the same as money arriving in your bank.
This guide covers Mercari’s US seller payment flow, based on research dated October 7, 2026. It does not describe Mercari Japan or establish eligibility for cross-border withdrawals. Because Mercari has changed its fees, confirm the terms shown in your account before requesting a transfer.
When does Mercari release seller earnings?
Mercari separates the buyer’s payment from the seller’s ability to withdraw the proceeds. Its Getting Paid guide explains that earnings are released through transaction completion and rating. If the buyer does not rate the transaction, it is normally auto-rated after three days following delivery.
The practical sequence is:
- The buyer purchases the item. The order exists, but the proceeds are not yet withdrawable earnings.
- The seller ships and the item is delivered. Delivery starts the normal buyer review window.
- The rating process completes. Buyer rating or automatic completion allows the earnings to become available, subject to any unresolved transaction issue.
- The seller requests a withdrawal. Available funds move through the selected payout method.
- The receiving bank or card account is credited. This is the point at which the withdrawal becomes usable cash outside Mercari.
The three-day review window is not a bank-transfer estimate. Likewise, an Instant Pay estimate does not start when an item sells. It applies to withdrawing money that is already available.
If a return request or another transaction problem is open, do not treat the ordinary automatic-rating timeline as an unconditional release promise. Check the order’s actual status before forecasting the cash.
ACH direct deposit vs. Instant Pay
Mercari’s official fee schedule distinguishes free successful ACH withdrawals from paid Instant Pay and failed-transfer charges. The published withdrawal terms summarized below apply to the US service; timing is an estimate, not a guaranteed delivery deadline.
| Withdrawal method | Destination | Fee | Typical timing | Limits and requirements | Best for: editorial assessment |
|---|---|---|---|---|---|
| ACH direct deposit | Linked bank account | Free if successful; $2 for a failed withdrawal | Within five business days | One request per day; bank-account restrictions apply | Routine withdrawals without a speed premium |
| Instant Pay | Eligible debit card | $3 per withdrawal | About 30 minutes | ID verification; one use per day; $600 monthly maximum | Urgent access within the available limit |
ACH: lower cost, but allow for business days
ACH direct deposit is the straightforward option when speed is not critical. Count the transfer window from the withdrawal request, not the sale or delivery date. Business days also make this different from a calendar-day countdown.
Mercari restricts bank-account linking: an account uses one bank account, and a joint bank account cannot be connected to multiple Mercari accounts. Sellers sharing household banking should check that restriction before assuming each person can withdraw into the same joint account.
Free does not mean error-proof. A failed withdrawal can carry a charge, so reviewing bank details before submitting is more useful than repeatedly retrying an unsuccessful transfer.
Instant Pay: faster withdrawal, not faster release
Instant Pay requires identity verification and an eligible debit card. Its daily frequency restriction and monthly withdrawal cap mean it is not an unlimited substitute for ACH.
Most importantly, paying for Instant Pay does not bypass the transaction-completion requirement. It changes the withdrawal method after earnings become available, not the point at which the seller earns access to them.
How much does Mercari deduct from a sale?
For listings created or updated on or after January 6, 2025, Mercari charges a 10% selling fee on the item price plus buyer-paid shipping. Mercari’s fee-structure FAQ explains the change and the removal of the separate payment-processing fee under that structure. Do not automatically add the older 2.9% plus $0.50 processing charge when estimating a current listing’s proceeds.
The shipping treatment is easy to misread:
- If the buyer pays shipping: that shipping amount is included in the selling-fee calculation. Buyer-paid shipping is not simply extra seller margin.
- If the seller offers free shipping: the selling fee applies to the item price, while the seller absorbs the shipping cost.
- If the seller chooses a paid withdrawal: the withdrawal fee is separate from the sale-level selling fee.
The Buyer Protection fee is charged to the buyer rather than deducted from seller earnings. Other applicable adjustments can still affect an individual transaction, so use the order’s earnings breakdown rather than assuming every payout equals the item price minus the headline commission.
For an older, untouched listing, inspect its actual fee breakdown. Mercari’s historical fee changes make it unsafe to infer legacy treatment from a current calculator—or to combine fees from different policy periods.
Keep sale proceeds and withdrawal receipts separate
A useful reconciliation separates the amount earned on each completed order from the amount received through each withdrawal. The order record explains selling fees and shipping deductions. The withdrawal record explains transfer fees and movement out of the available balance.
This prevents a common accounting mistake: assigning a withdrawal fee to every sale when it was charged once for the transfer, or treating a completed sale as proof that the bank has received the money.
Why has the money not arrived?
Start by identifying the last completed step. “Mercari has not paid me” can describe several different problems, and each needs a different check.
- The order is delivered, but earnings are unavailable: inspect rating, transaction completion, and any open return or dispute issue.
- The balance is available, but nothing is in the bank: confirm that a withdrawal was actually requested.
- An ACH withdrawal is pending: compare the request date with the business-day estimate and confirm the destination.
- Instant Pay is unavailable: review identity verification, debit-card eligibility, and daily or monthly limits.
- A withdrawal failed: inspect the failure information and receiving details before retrying. Preserve the original request record.
If support is needed, gather the order identifier, delivery and completion status, withdrawal date, selected method, amount, and displayed error. Share sensitive banking information only through an appropriate secure support channel.
A checklist before withdrawing
- Confirm that earnings appear as available, not merely attached to a sold or delivered item.
- Review the transaction’s selling-fee and shipping breakdown.
- Check the receiving bank account or eligible debit card.
- For Instant Pay, confirm verification and remaining withdrawal eligibility.
- Choose the method based on urgency, fee, and limits—not its name alone.
- Save the withdrawal confirmation and reconcile it to the eventual receiving-account credit.
What marketplace finance teams can learn from this flow
Mercari illustrates a useful distinction for marketplace operators: earnings release and money delivery are separate controls. A faster payout rail cannot resolve an incomplete order, missing verification, or incorrect receiving details.
Platforms should expose those stages separately in seller-facing status messages and internal records. Track the order, release event, available balance, withdrawal request, and receiving outcome without collapsing them into one ambiguous “paid” status. Our guide to marketplace split payments and seller settlement explores the broader separation between collecting a payment and settling seller obligations.
For sellers, the next step is simple: verify that the transaction is complete, then choose the withdrawal method that fits the cash need. For finance teams building their own seller-payment operation, explore Payouts.com’s payout automation to evaluate automated disbursements across payment rails. Treat Mercari’s US flow as a specific example—not a universal template for international payout eligibility, FX, or settlement times.
Created with AI assistance. Sources are linked in the article; this content is general information, not legal, tax, or financial advice.
Discussion
36 commentsRelated resources
Marketplace Split Payments: From Checkout to Seller Settlement
Splitting a checkout payment is only the start. Build a marketplace money flow that keeps seller entitlements, release conditions, FX, and refunds connected through settlement.
Established Common Standards for Cross-Border Payments
Cross-border payments rely on several standards, not one global rulebook. Learn what each standard governs, where local requirements still apply, and how to turn standards into enforceable payment controls.
Xero Supplier Payment on Account: Record and Allocate Advances
A supplier advance should remain visible until it is allocated or refunded—not disappear into a reconciled bank transaction. Here is how to manage that workflow in Xero, including cross-border payment checks.
Run your entire money cycle on one ledger
Global payouts, AP/AR automation, and AI agents with their own wallets and spend limits.
Get started
The language around 'available' versus 'released' versus 'withdrawn' is subtle but critical for settlement reporting—we've had sellers show us screenshots of completed orders and insist the funds should be in their bank that same day, and this breakdown makes it clear why that's not how the flow works.
We added a similar three-state model in our seller dashboard after support tickets spiked around month-end. The reconciliation pain is real when sellers are trying to close their books and can't distinguish between 'Mercari owes me this' versus 'Mercari released it but my bank hasn't cleared it yet.'
We built status labels for exactly this reason—'pending rating,' 'available balance,' and 'transferred'—and it still took three rounds of customer support training before the team stopped promising same-day deposits on completed orders.
The distinction between selling fee on buyer-paid shipping versus seller absorption on free shipping is a subtle margin trap. If your P&L model treats shipping revenue as passthrough, you'll overstate seller take-home by exactly that 10% on every prepaid label transaction.
Exactly. We started tagging shipping-paid-by-buyer as a contra-revenue line item rather than a receivable offset once we saw how the 10% landed. The order detail JSON treats it as part of gross proceeds but your GL needs to strip it back out if you're matching to actual seller deposit amounts.
We made that exact mistake on our first monthly close after launching a reseller program. Treated buyer-paid shipping as net zero on the seller side, then discovered we'd underprojected platform take by 9.2% across the category. Had to restate the whole cohort analysis.
The Instant Pay monthly cap of $600 is more restrictive than I expected for a seller-facing marketplace. If someone is doing even modest volume, they're basically forced into the ACH wait or they hit the ceiling after a few transactions. Would be interesting to know if Mercari has considered tiered limits based on seller history or verification level.
Agreed, and the one-use-per-day frequency cap compounds it. Even if you're under the monthly limit, you can't batch multiple small withdrawals if you need liquidity mid-month. We see similar caps on card-based payouts across marketplaces—usually set by the issuing bank's dispute exposure rather than the platform itself.
It's clearly a fraud and credit risk constraint more than a product choice. The combo of ID verification, single daily use, and the $600 cap looks like they're keeping Instant Pay inside a low-exposure envelope while ACH handles the actual volume.
The joint bank account restriction is a subtle but real pain point if you're running a household resale operation with multiple Mercari accounts. We discovered this when setting up our client's multi-seller reconciliation workflow and had to map each seller ID to a unique bank account, which complicated their cash pooling setup considerably.
We ended up opening separate business checking accounts for each seller entity in that scenario. It's annoying overhead, but it simplified both the reconciliation and the tax reporting since each account mapped cleanly to a Schedule C.
We hit the same constraint when consolidating household 1099 reporting for a couple selling separately. The workaround we used was routing through a business entity with sub-accounts, but that introduced tax complexity that wasn't worth it for casual resale volume.
The auto-rating trigger after three days is standard marketplace behavior, but counting it separately from the ACH window is the part that most payment ops teams miss when they model working capital needs for sellers—you really need T+8 minimum if you're conservative about delivery confirmation lag.
Exactly, and if you're dealing with remote-area deliveries where carriers take longer to mark delivered, or weekends eating into the ACH window, T+10 is honestly safer for forecasting purposes.
We use T+9 in our cash flow models for similar reasons, but also because delivery confirmation itself can lag a day if the carrier's status feed doesn't sync immediately—so you're conservative on both ends of the window.
The reconciliation advice at the end is underrated—keeping sale-level deductions separate from withdrawal-level fees prevents a lot of downstream P&L noise, especially when you're dealing with hundreds of transactions per month and only a handful of batched transfers.
We do the same thing now, but it took a messy quarter-end close to get there. The CFO kept asking why transfer fees didn't scale with volume, and it turned out we'd been accruing them per-order instead of per-batch. Fixed it by splitting the GL codes and hasn't been an issue since.
We ran into this exact problem when building our first consolidated payout report. Ended up creating two separate GL mappings—one for marketplace commission at transaction close and another for transfer fees at withdrawal execution. It's tedious but the alternative is restating months of books when someone finally notices the mismatch.
The split between when earnings are 'released' and when they can actually be withdrawn is a reconciliation nightmare if you're building reporting for sellers at scale. We built a two-stage settlement ledger for a gig platform specifically because users couldn't understand why their dashboard showed available funds but their bank account hadn't updated—Mercari's three-day auto-rating plus up to five business days for ACH means a seller can be waiting 8+ calendar days from delivery to cash, which is rough for liquidity planning.
Exactly this. We solved it by surfacing both timestamps in the UI—'earnings available' and 'transfer initiated'—but sellers still conflate the two when cash flow is tight. The three-day auto-rating window plus the five-day ACH estimate means you're looking at eight calendar days minimum in many cases, and that's assuming no weekend overlap.
We ended up building that same two-stage model after sellers started filing disputes because the 'available balance' shown didn't match what they could actually request for payout. The article's point about the three-day auto-rating window not being a transfer estimate is exactly the confusion we kept seeing in support tickets.
The three-day auto-rating window is a useful safeguard for buyers but it complicates cash flow forecasting for sellers who treat marketplace sales like working capital. We built a buffer assumption into our treasury model specifically because marketplace platforms rarely release funds on delivery—there's always some contingent hold period, and Mercari's is actually shorter than some others we've seen.
Same problem here. We ended up modeling marketplace proceeds as T+6 at the earliest (3-day rating window plus ACH settlement) and flagging any forecast that relied on same-week availability. The instant pay option doesn't help much once you hit the monthly cap.
We do the same thing but use T+7 as the conservative assumption because ACH can stretch over a weekend. The marketplace release schedule is predictable enough, but the banking calendar adds another variable that sellers usually ignore until they need the cash on a Friday.
The ACH failure fee is a good reminder that payout errors cost money on both ends—we've seen treasury teams treat failed transfers as zero-cost retries and then get surprised when provider invoices show per-failure charges accumulating across thousands of sellers.
We added per-failure cost tracking to our reconciliation dashboards after a similar surprise. The other thing that caught us was retry logic amplifying costs—one bad account file triggered dozens of automated retries before the queue paused, and suddenly a $2 unit cost turned into a material line item.
We started tracking failure reasons in addition to counting failures and found that about 60% were stale account details (closed accounts, changed routing numbers). Adding a pre-validation step cut our failure rate in half but you still can't eliminate mismatches entirely when sellers control the bank account input.
Interesting that they pushed the selling fee to 10% flat and folded in payment processing. From a treasury ops perspective that's cleaner to model than the old tiered structure, but the buyer-paid shipping inclusion is easy to miss if you're bulk-forecasting seller proceeds. Have you seen whether this actually reduced dispute volume around fee calculations?
Yeah, the buyer-paid shipping inclusion catches a lot of marketplace operators off guard. We run settlement reports for a couple of resale platforms and had to add a separate shipping-fee column after the first reconciliation blew up. The flat 10% makes the per-transaction calc straightforward but you really need to parse the shipping field or your revenue share estimate will be wrong by double digits on heavy items.
We ran into that exact shipping wrinkle when auditing seller proceeds for a marketplace client. Their reporting had been treating buyer-paid shipping as pass-through, so their net revenue model was off by the commission delta. Once you scale to thousands of transactions the reconciliation gap gets messy fast.
The $2 failed ACH charge is a nice detail that most payment flow explainers skip. We apply similar logic in AR automation—penalizing retry spam instead of letting customers hammer invalid bank routes—but it's rare to see a consumer marketplace surface that publicly.
We considered adding a failed-transfer fee when we rebuilt our vendor payout queue but decided against it because support couldn't handle the volume of disputes from typos. Ended up doing free retries with escalating delay windows instead.
We considered adding a failed-transfer fee when we rebuilt our vendor payout queue but decided to just kill the route after two bounces and force re-verification. The fee model only works if your user base understands the retry cost isn't punitive, which is a hard sell in support tickets.
The two-step timing model here (release versus withdrawal) is exactly why we tell clients in the gig economy space to track both event dates separately in their reconciliation logic. Too many platforms conflate 'sale complete' with 'funds available,' and Mercari at least makes the distinction explicit, even if sellers don't always read it that way.
Agreed. We built separate ledger tables for transaction state vs payout state after reconciliation broke during a similar integration. One captures the release timestamp, the other logs the actual withdrawal request and settlement. Prevents a ton of customer support noise when someone sees 'completed' but the ACH is still in flight.
We hit this exact issue migrating a contractor platform last year. Their payment provider merged both timestamps into a single 'payout_date' field, and variance reports were a disaster until we split out transaction completion from settlement. The ACH delay window alone added four days of unexplained float.