Crypto Payroll: How to Pay Your Team in Crypto

Yes, you can run crypto payroll and pay your team in crypto on Payora, and the honest version is more useful than the hype: you build a batch of recipients, the total is reserved on your internal balance, and the batch then follows the approval, signing or release flow configured for your account. Salaries and contractor invoices can go out as a single mass payout of up to 500 people, priced in a stablecoin on a cheap network so the fees are cents, not dollars. Batch creation is not payroll completion; status and transaction evidence are what close the loop.

Why teams pay in crypto at all

Crypto payroll is not about speculation. It solves boring, real problems that a bank cannot:

• Cross-border contractors. A designer in Lagos, a developer in Buenos Aires, and a writer in Manila should not each cost you a $40 SWIFT wire and a five-day wait. A stablecoin transfer settles in minutes for a few cents.
• Unbanked or under-banked people. Plenty of skilled contractors have a phone and a wallet but no account that accepts USD. A wallet address is all they need.
• Places where cards and banks fail. Sanctions confusion, frozen correspondent banking, local currency that loses 30% a quarter. A USDT/USDC salary is a dollar that actually arrives.
• Speed and predictability. You know the exact amount that lands. No intermediary bank shaves a fee off the middle.

The trade-offs are just as real. Crypto payments are final, so a wrong address is money gone. Price volatility is why serious payroll runs on stablecoins, not on BTC or ETH. And payroll tax and compliance are entirely your responsibility — Payora moves the money, it does not withhold, report, or classify anyone as an employee. More on that below.

What crypto payroll on Payora actually is

Payora is a hosted gateway with an internal balance. When you submit a payroll batch, the funds are reserved, the batch is created, and later status/webhook evidence tells you what happened. The release itself should follow the approval, signing or release flow configured for your account. Do not treat a submitted batch as completed payroll until the payout status and transaction evidence show that each item has been released.

Call that a limitation if you like, but flip it around. Fully automatic payroll release can be convenient, but it also increases the blast radius of account or server compromise if release controls are weak. For a company holding a month of salaries as a balance, the practical trade is deliberate review and release controls in exchange for fewer accidental or duplicate payroll runs. The mass payout architecture article gives security context, but current Payora steps should be checked in the product docs and account settings.

Running a pay period as one batch

You have two ways to run crypto payroll, and both should end with the same discipline: verify release status and transaction evidence before payroll is marked complete.

From the cabinet. Paste up to 500 recipients, one address amount [tag/memo] per line. The batch total plus the per-item fee is held on your internal balance when you submit, so a payroll run cannot overspend the account. Review, then complete the configured approval or release steps.

From the API. For teams that generate payroll from an HR sheet or accounting system, POST /v1/payout takes the same batch as JSON. The one header that matters most for payroll is Idempotency-Key: set it to something stable per pay period, like payroll-2026-07, and a retried or double-fired request will return the existing batch instead of paying everyone twice.

curl -X POST https://api.payora.money/v1/payout \
  -H "X-Payora-Key: pk_live_..." \
  -H "X-Payora-Timestamp: 1721736000" \
  -H "X-Payora-Signature: <hmac-sha256 of timestamp.rawbody>" \
  -H "Idempotency-Key: payroll-2026-07" \
  -H "Content-Type: application/json" \
  -d '{
    "currency": "USDT",
    "note": "July 2026 salaries",
    "items": [
      {"address": "TSaLa...9fQ", "amount": "3200.00"},
      {"address": "TPay...k2R",  "amount": "2750.00"},
      {"address": "TDev...7mX",  "amount": "4100.00"}
    ]
  }'

Auth is the same HMAC-SHA256 scheme as the rest of the API — X-Payora-Signature is hex(HMAC-SHA256(secret, timestamp . "." . body)), with a ±120s skew window. The full request and webhook contract is in the API docs. If any address is invalid, or any amount has more decimal places than the coin allows, the whole batch is rejected with HTTP 422 and the offending item indexes. A payroll run never silently drops or truncates someone — you fix the two bad rows and resubmit. A successful call returns 201 with a batch_id, status: "pending", the item count, total, and fee.

Pick a stablecoin on a cheap network

The single biggest lever on payroll cost is which asset and network you choose. Pay in a USDT or USDC stablecoin so nobody's salary drifts overnight, and pick a network where the on-chain fee is trivial:

For a 200-person run, the difference between Tron and Ethereum can be the price of a laptop. Any currency enabled on your merchant account works, and the optional third field per item carries an XRP destination tag or an XLM memo when the recipient needs one.

Reconciliation: closing the books after payday

Payroll is not done when the batch is created — it is done when you can prove every person was paid. Payora gives you two matching sources of truth after the configured release flow completes. A signed payout.sent webhook is verified with the same HMAC-SHA256 signature as invoice.paid. And GET /v1/payout/{id} returns each item with its individual tx_hash when transaction evidence is available, so every salary maps to a real, auditable on-chain transaction you can hand to accounting or paste into a block explorer.

If you need to pull a batch before release — someone left, an amount was wrong — POST /v1/payout/{id}/cancel cancels a still-pending batch and releases the held balance back to spendable. No completed on-chain payout exists yet, so there is nothing to claw back.

Fees, finality, and getting addresses right

Two fees exist and they are not the same thing. Accepting money into Payora is 0%. Moving money out — which is what payroll is — carries a configurable move fee, 1.5% on the Free plan, plus the coin’s network fee, and it is held per item alongside the batch. Separately, the network charges its own on-chain fee, which is exactly why the stablecoin-on-a-cheap-network choice above matters so much. The full breakdown is on the pricing page.

Because crypto payments are final, address accuracy is not a nicety. Payora validates every address against the target network before it will hold the batch, and rejects malformed ones up front — but it cannot know that a valid address belongs to the wrong person. Collect wallet addresses the same careful way you collect bank details, and have contractors confirm them the way you would for freelancer invoicing.

Tax and compliance are on you

This is the honest boundary. Payora is a payment rail. It does not withhold income tax, does not file anything with any authority, does not run KYC/AML screening, and does not decide whether someone is a contractor or an employee. Paying salaries in crypto does not change your obligations under local labor and tax law — it only changes the rail the money travels on. Talk to an accountant who knows your jurisdictions. That part is out of scope, and any tool that tells you otherwise is selling you a risk.

If your team already lives in wallets, crypto payroll turns a slow, expensive, multi-bank chore into one reviewed batch you can release and reconcile each cycle. Create a free account to get API keys, or read how the mass payout product handles batches of up to 500 recipients.