Payouts in the dashboard

Set up payouts and follow each one without calling the API.

Owners and managers see the Payouts page and the Settings → Payouts tab. Cashiers don't. For creating payouts from your backend, see the Payouts API.

The customer's checkout uses your Settings → Checkout colors and your business name and logo, read each time the customer opens the page, so changes reach open payouts too. If Peer has removed Peer branding for you, it also hides the "Powered by Peer" footer; nothing else changes.

Payout currencies

Players can receive catalog currencies on PayPal and Revolut; you still fund and see USD. Currencies come from the rail catalog, with no admin or merchant currency setting. Each rail stays one payout app; Venmo, Cash App, Zelle and Chime remain USD-only, and crypto is unchanged.

The customer chooses their currency at checkout. Non-USD amounts start with “≈” at the market rate with 0% spread; each buyer's rate becomes exact when they start paying. An unavailable estimate does not remove a currency or prevent a withdrawal. Paid parts retain their own currency when the customer changes the method for the rest.

The method line includes a non-USD code, for example Revolut @alice · EUR. Settlement shows Paid by buyers 100.00 USDC (€89.31) when fiat is known; mixed currencies can show 100.00 USDC (€44.65 + £39.10). Partial-payment rows show their own fiat. Unknown or USD-only fiat leaves the USDC display unchanged. These figures are informational; fees, limits and refunds remain USDC.

CSV exports add Payout currency (empty without a fiat method) and Fiat paid, such as EUR 44.65; GBP 39.10. Fiat paid is empty before settlement or when unknown.

Settings → Payouts

Edit any row, then save once from the bar at the bottom. Changes to payout apps, the fee and the payout step apply to new payouts only; each payout keeps the ones it was created with. Customer support applies at once, to open payouts too.

Row	What it sets
Payout apps	Where customers can take their payout: Venmo, Cash App, PayPal, Zelle, Revolut, Chime and Crypto, all on by default. Edit opens the list.
Payout fee	Shown only for enabled Master Merchant Accounts. Your markup is paid to your merchant wallet: 0–10% in 0.01% steps, 0% by default, as a share of the amount you fund. Other merchants cannot add payout fees.
Payout step	Payouts must be whole multiples of this amount, from 10 to 1,000 USDC (100 by default). A test environment may allow a smaller step; the row shows the range.
Customer support	Optional: an https:// link or an email where customers get help. Every help link opens it: "Contact {your business name}", shortened to "Help" in the header on phones. Without it the customer's page shows no contact line and never Peer support. Applies at once, to open payouts too.

How customers connect

App	How the customer connects	Continue without verifying
Venmo	The email that gets their Venmo receipts (Gmail, Outlook or iCloud), in a Peer pop-up at app.peer.xyz/connect/venmo	Yes, on every device
Cash App, PayPal	The Peer App Clip: "Open the Peer App Clip" on iPhone/iPad, a QR code to scan with an iPhone elsewhere	No on iPhone/iPad; yes on Android and desktop
Zelle, Revolut, Chime	No connect step; each buyer proves their payment	n/a
Crypto	No connect step	n/a

A customer who chooses "Continue without verifying" can list the payout without a connection; each buyer then proves their payment. The listed page offers a Verify button and a hint, for example: "Verify your Venmo to get paid faster. Some payments only go to verified accounts."

PayPal works only for an account already set up in Peer.

Crypto is one switch for every network: on adds every network Peer offers, off removes them all. Peer can turn one network off for new and open payouts; customers then pick another network. A network Peer had off when you turned Crypto on stays off for you after Peer restores it, until you turn Crypto off and on again and save.

Payouts are off while every payout app is off; the API then answers 403 PAYOUTS_DISABLED.

• Peer can switch a platform off for every merchant. One you had on stays saved, and the row says Peer has turned off {name} for now. Customers won’t see it. Its tile says "Not available right now". You can still save it; new payouts leave it out until Peer turns it back on. Once you turn it off and save, it disappears until Peer turns it back on; before you save, Discard brings it back. A switched-off platform that isn't saved as on doesn't appear in Payout apps. For the single Crypto tile, the switched-off notice appears only when every saved crypto network is unavailable.
• Peer can also turn your platforms on or off for you, and the row shows the change.
• If Peer has switched off every platform you turned on, new payouts fail with 422 PAYOUT_NO_RAILS_AVAILABLE.
• The settings request (GET /api/v1/merchants/me/payout-settings) needs a dashboard sign-in as an owner or manager, not an API key. It returns your settings plus availableRails (what Peer offers every merchant), availableFundingTokens (what Peer allows you) and payoutStepRange.

Crypto payouts

The customer sees one Crypto option over every network on the payout: Relay networks include Solana, Tron and Bitcoin; ZEC on Zcash uses NEAR Intents, on rail near_intents_133701. ZEC accepts only transparent t1… or t3… addresses, not shielded or unified addresses. Its arrival estimate is Within 30 minutes. ZEC is payout-only; you can't fund a payout with it. See crypto payouts for the coin list and details.

For a bridged payout, the customer sees an estimate marked "≈". Network and bridge fees come out of what arrives, so the amount can change a little. Direct USDC on Base shows the fixed amount. While bridging, the customer sees Sending to {Network} and your timeline's next step reads like "Sending SOL on Solana to the customer". Delivery settles the payout; the Base send alone does not.

A verified bridge refund returns the USDC to the customer's Peer wallet less the provider's refund fee. The payout is READY and the customer can try again or choose another payout method. The loss is settlement.refundFeeAmount, shown once the payout settles as Kept by the bridge on refunds when it is greater than zero. If Peer turns a network off, the customer sees {Network} isn’t available for this withdrawal. Choose another network.

In the API and webhooks, payoutTransfer.provider is NEAR_INTENTS for ZEC, RELAY for Relay payouts, and null for direct Base USDC.

The Payouts page

The list shows every payout you created, newest first:

• Payout ID (with a copy button), Customer (the customer's email), and your Reference.
• Method: the payout app the customer chose, or "Not chosen". Crypto shows the coin, network and shortened address, for example USDC on Arbitrum 0xAbCd…Ef01.
• Amount, Funded (USDC) as received / expected (while partly funded, with what you still have to send in your funding token), Paid to the customer, Status, and Created. Status reads Partly paid when a buyer has paid part and the rest is still listed, being paid, or being withdrawn.

A buyer may pay part of a payout; the rest is relisted. The customer can withdraw the rest to their Peer wallet, relist it, or send it to a crypto address. See partial payments and after a partial payment.

Filter by the customer's email and your reference (both exact matches) and the status, with 20, 50 or 100 rows per page. The filters stay in the page's URL, so a filtered view can be bookmarked or shared with your team. Export downloads the filtered rows as a CSV, up to the first 1,000.

Cancel and top up

Both actions are on the list's rows, not on the payout's page.

• Cancel shows only while a payout is awaiting funding and nothing has arrived yet. It asks you to confirm first. It follows the API's own cancel rule.
• Top up shows only while a payout is partly funded and its quote hasn't expired. It shows the deposit address with a QR code, the amount still to send and what you have sent so far, both in your funding token, and the quote expiry. Never send after the quote expires. Each on-time top-up that arrives extends the expiry to at least 24 hours later. If the rest never arrives, the customer withdraws what did after expiry, once any on-time funding has finished processing.

New payout

New payout creates one payout from the dashboard; to create them automatically, call the API from your backend.

• Fields: enter the customer's email, the payout (a whole multiple of your payout step, up to $1,000), the funding token and chain, and an optional reference. The form never limits payout methods, so the payout offers every app you have on that Peer makes available. To limit one payout, use rails in the API's create request.
• Refund address: for a token on an EVM chain, it is pre-filled with your Peer wallet. Leaving it empty refunds the wallet that sent the funding if Relay cannot convert it. Set it for exchange withdrawals because Relay does not automatically refund exchange wallets. For BTC on Bitcoin, Bitcoin refund address is required and starts empty; your Peer wallet holds no bitcoin. Enter a Bitcoin address you control (bc1…, 1… or 3…); Create payout stays disabled until it is valid.
• Funding tokens: the list defaults to USDC on Base when available, otherwise its first token. It shows only tokens Peer allows for your merchant. Solana, Tron and Zcash can't fund payouts. When no tokens are available, the form says "No funding tokens are available. Contact Peer support."
• The result: the deposit address, amount to send, quote expiry and customer's checkout link, each with a copy button. The quote lasts 24 hours. Funds Relay saw by the expiry count as on time even if they confirm later, including a Bitcoin transaction seen in the mempool. Never send after the quote expires. A double click or retry in the same open form creates one payout. If Relay says the payout is too small for the funding token, the form shows the PAYOUT_FUNDING_AMOUNT_TOO_LOW message: "This payout is too small to route from this funding token. Choose a larger payout or another funding token."
• Pay from your Peer wallet: if it holds enough of the funding token, the result and the payout's page offer a send until Pay sees funding sent or received, or a minute before the quote expires, only on chains the Peer wallet can send on. One click sends the exact amount with gas covered by Peer. Only the account that owns your Peer wallet sees the option; team members don't. A send is remembered in this browser. If it says "We couldn’t confirm whether it was sent. Check your Peer wallet’s activity before sending again.", check before sending again from any device. Native tokens (ETH, BNB, HYPE) and Bitcoin need a manual send. This option is not offered in Top up.

A payout's page

Open a payout from the list to see:

• Payout: Customer, Amount, Your fee and its rate, Customer receives, Paid so far, and Method (for example Venmo @alice, or a crypto address linked to that network's explorer).
• Funding: the route, the expected USDC (the payout plus the buffer), the amount to send, what you sent and, if less, what is still missing, both in your funding token, the deposit address, the quote expiry in UTC, the USDC that arrived, the deposit, and the funding status.
• For a Bitcoin payout awaiting funding, the page, the payout-created view and Top up also say: "A Bitcoin transfer can take up to an hour to show as sent. Don’t send it twice." Sent stays at 0 until Relay records the transfer, which waits for the network to confirm it.
• Webhooks: every payout webhook sent for it, with its response code or status and time. Choose the Customer payouts event group for your webhook endpoint under Settings → Developer; see payout events.
• Settlement, once the payout settles: Received at the customer’s address (with the address and a copy button; bridged payouts also show the delivered coin and network and View transaction), Returned to the customer’s wallet, Dust, and Kept by the bridge on refunds when the refund cost is greater than zero.
• Funding issues, only when there are some: extra or late funds ("Extra funds received. Peer support will contact you.") and payments the route refunded ("Refunded by the route"). Once Peer support settles one it shows Returned with the return transaction hash, or Claimed, and the date. See funding issues.
• Timeline: each moment, oldest first: created, partly funded or funded, funding expiring, the customer signing in, the payout method becoming ready, listing, a buyer starting to pay, paying part or dropping, relisting, reconnecting the payout app, withdrawing a listing to change the method, a crypto send and its delivery or refund, a funding issue, cancelling, and settling. Transaction links open on the network where they happened. The last line, faded, says what happens next, such as "Waiting for a buyer" or "Sending SOL on Solana to the customer".

Copy payout link copies the customer's link while the payout is still open.

The list, the payout's page and the CSV export show the customer's email as you sent it at create (lower-cased). The dashboard never shows the customer's Peer wallet address or Peer's fee. For a crypto payout it shows the address the customer chose.

Product guides

See the payouts overview, online casino payouts, wallet-free payouts, and payout API overview for integration use cases.