How to Pay Many Crypto Wallets at Once

Yes — you can pay many crypto wallets at once instead of firing off transfers one at a time. On Payora you drop up to 500 recipient lines into a single batch, where each line is an address amount pair with an optional tag or memo, or you send that same list to the payout API. The instant the batch is accepted, the total plus fees is reserved on your internal balance so it can never be overspent, and the whole run then reconciles as one object instead of five hundred loose transactions.

That is the short answer. The rest of this page is the practical detail: how the paste flow works, when to reach for the API instead, what it costs, and the one honest caveat about how the coins actually leave.

Why send crypto to multiple wallets as a batch?

Paying people one transaction at a time works right up until you have thirty of them. Then it stops being a task and becomes a source of errors. Batching fixes three specific problems:

• Fewer mistakes. You prepare the full list once, review it once, and submit it once. No pasting an address into a wallet forty times at 11pm, which is exactly when a digit gets transposed.
• One reserved total. The batch total and its fees are held together, up front. You either have the funds for the whole run or you find out immediately — not halfway through, with fifteen people paid and fifteen waiting.
• One reconciliation. The batch is a single record with a single id. Accounting sees one outgoing total and a per-recipient breakdown, not a haystack of individual withdrawals to match up by hand.

If you are paying a team, affiliates or a marketplace's sellers on a schedule, this is the difference between a five-minute job and a lost afternoon. The mass payouts feature is built for exactly that.

Paste the batch in the cabinet

The simplest way to pay many crypto wallets at once is the cabinet. Open the payouts screen, pick the currency, and paste your list — one recipient per line, address then amount, separated by whitespace:

TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t   250.00
TW2v8xVEXAMPLE2recipientTronaddr     99.50
TJRabPrEXAMPLE3recipientTronaddrxx   1000.00

Each line is validated before anything is reserved: the address has to be well-formed for that coin, and the amount cannot carry more decimal places than the asset actually supports. If any single line is wrong, the whole batch is rejected and told you which line indexes to fix. A payroll run never silently drops or truncates a recipient — you get all of it or none of it. Once it validates, the total plus the per-item fee is reserved, the batch goes to pending, and you are ready to sign.

A batch is one currency at a time, because each coin settles on its own network. Here is what a few lines look like across different assets, including the optional third field:

You would run each of those as its own batch — a USDT-on-Tron batch, an XRP batch, an XLM batch — because the currency is chosen once for the whole list.

Prefer code? Call the payout API

If payouts are triggered by your own system — a payroll cron, an affiliate dashboard, a game's cashout queue — skip the paste and POST the same list to the API. The body is a currency and an array of items:

curl -X POST https://api.payora.money/v1/payout \
  -H "X-Payora-Key: $KEY" \
  -H "X-Payora-Timestamp: 1721736000" \
  -H "X-Payora-Signature: $SIG" \
  -H "Idempotency-Key: payroll-2026-07-23" \
  -H "Content-Type: application/json" \
  -d '{"currency":"USDT","items":[{"address":"TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t","amount":"250.00"},{"address":"TW2v8xVEXAMPLE2recipientTronaddr","amount":"99.50"}],"note":"July contractors"}'

Authentication is the same signed-request scheme as the rest of the Payora API: an X-Payora-Key, an X-Payora-Timestamp within ±120 seconds, and an X-Payora-Signature that is an HMAC-SHA256 of the raw body. Add an Idempotency-Key and a retried request will never create a second batch — a dropped connection during a payroll run is safe to repeat. A successful call returns 201 with a batch_id, the item count, the total and the fee; GET /v1/payout/{id} returns per-item status and tx hashes, and a signed payout.sent webhook fires once every item has gone out. The full reference lives in the docs, and there is a dedicated walkthrough of automating payouts with the API.

The honest part: how the coins actually leave

Here is the caveat, stated plainly, because it is also the whole point. Submitting a batch, from the cabinet or the API, reserves the funds on your Payora balance and creates a batch you can track. It does not by itself prove that recipients have been paid. The batch then follows the approval, signing or release flow configured for your account, and you reconcile the result from status, webhook and transaction evidence.

So the API automates submission, validation, status tracking and the webhook, while release remains an operational control. Anyone promising "API call in, coins instantly out, no review" is describing a more automated and riskier model. Fully automatic hot-wallet-style payout products can be convenient, but they also increase the blast radius of an account or server compromise. For a deeper look at security trade-offs, the mass payout architecture piece gives useful context; always confirm the current Payora flow in product docs and account settings.

What a batch costs

Two fees apply, and they are separate:

1. The Payora move fee — 0% to accept payments, and a small configurable fee to move money out (1.5% on the Free plan, plus the coin’s network fee). It is charged per item and held with the batch, so the reserved total already includes it. See pricing for the current numbers.
2. The network fee — the on-chain cost of each transaction, paid to the network, not to Payora. This depends entirely on the coin and how busy its network is: cents on Tron, TON or Solana; more on Bitcoin or Ethereum at peak.

Both come out of the sending balance, which you top up by accepting payments or transferring in. You can watch the hold and the release on your balance page.

Tags and memos for XRP and XLM

Some networks need a second identifier to route a payment to the right account behind a shared address. XRP uses a destination tag; XLM uses a memo. On Payora that value is the optional third field on each line (or the tag property per item in the API), as shown in the table above. If you are paying anyone onto an exchange or custodial service on those chains, the tag or memo is not optional in practice — leave it off and the funds land at the right address but the wrong sub-account. Payora validates the field before reserving, so a malformed tag is caught with the rest of the batch.

Changed your mind? Cancel the hold

A batch you have submitted but not yet released is still pending, and a pending batch can be cancelled. Cancelling releases the reserved balance straight back to your available funds — nothing is stuck, because no completed on-chain payout exists yet. Whether you cancel in the cabinet or POST /v1/payout/{id}/cancel through the API, the result is the same: the hold is undone and you can rebuild the list. This is exactly why reserve-then-release matters — the money is accounted for while you review the batch, but recipients are not treated as paid until status and transaction evidence confirm release.

Get started

Paying many crypto wallets at once comes down to three moves: fund your sending balance, paste or POST a batch of up to 500 lines, and complete the configured approval or release flow before marking recipients paid. Create a free account, try a two-line batch on a cheap network to feel the whole flow, then scale up. The mass payouts page has the details, and the docs have the API reference for when you are ready to automate the submission side.