NEWPockyt × Circle: native USDC settlement now live →
VisionNews
Solution — Global Payouts
Disburse at scale.
To any rail.
In any currency.
For marketplaces, platforms, and treasury teams sending money out at volume: a single API across every destination rail, with cross-currency support, batched processing, and rule-driven scheduling on top.
The Shift
Same payout volume. Two very different operations.
A marketplace settling weekly payouts to 10,000 sellers across 30 countries can run that operation as the full-time job of a treasury team, or it can run it as a recurring rule on Pockyt. The difference shows up in vendor count, in working capital, and in how many people the operation requires.

The vendor-chain payout flow

  1. Treasury team aggregates seller balances across multiple ledgers
  2. Splits the file: international wires here, mobile-wallet payouts there, push-to-card elsewhere, on-chain via a fourth vendor
  3. Each vendor has its own funding model: pre-fund this one, post-fund that one, settle T+2 with the third
  4. Each vendor returns a different settlement file with different identifiers
  5. Reconciliation happens in a spreadsheet, by hand, every week
  6. Failed payouts trigger separate retry workflows per vendor
Result: a full-time job that scales with vendor count, not with payout count.

The Pockyt flow

  1. Define payout policy as a rule in Programmable Logic
  2. Rule fires on schedule, pulls eligible sellers from Pockyt ledger
  3. One batched API call disburses to every destination rail
  4. Reconciliation rolls up in the same Pockyt ledger as collections
Result: the operation scales with payout count, not vendor management.
The Pattern
How a Global Payouts deployment actually works.
Four ingredients, regardless of payout shape: a Pockyt treasury balance to fund from, a payee directory (yours, ours, or both), a set of rules describing the policy, and a webhook listener for completion events.

01

Fund the treasury source

Pre-fund a Pockyt treasury in the currencies and amounts you'll need. Or let Pockyt fund payouts directly from collections (closed-loop model: revenue lands, payout fires, no pre-funding required).

02

Stand up the payee directory

Either upload payees to Pockyt (we KYC, store, and tokenize them), or keep them in your own system and pass full bank/wallet details with each payout call. Both patterns work; the former scales better at high volume.

03

Encode the policy

Express payout policy as a rule: when to fire, who's eligible, which rail to prefer, what thresholds to enforce, what holds to respect. The rule becomes the operation.

04

Listen to webhooks

Subscribe to payout-completed and payout-failed webhooks. Use these to update your own application state. Pockyt handles retries and reconciliation against the source ledger.

What changes
What the operating layer actually delivers.
The right way to measure a payments layer isn't its uptime page. It's how much working capital, FX margin, and engineering time it frees up in the businesses that depend on it.
5+ → 1
Payout vendors
International wires, mobile wallets, card-push, and on-chain disbursements consolidated onto one API.
days → min
Settlement time on USDC corridors
Cross-border payouts that previously took 2-5 business days settle in minutes when both legs are stablecoin-native.
80%+
Manual reconciliation reduced
One ledger, one settlement file, one source of truth. Treasury operations stop scaling linearly with payout volume.

When this fits
Who gets the most out of Global Payouts.

Marketplaces with seller settlement at scale

If you're paying out to 1,000+ sellers in 5+ countries, every dimension of the operation compounds. The vendor consolidation alone usually justifies the migration.

Platforms with affiliate, partner, or creator payouts

Recurring, batched, cross-currency payouts where the operational overhead has historically dominated the actual cost of moving the money.

Treasury teams replacing operational bank accounts

Companies where treasury was traditionally a multi-bank, multi-vendor operation can consolidate the outbound side onto Pockyt while keeping their existing banking for non-payout use cases.

Where this isn't the right fit

If you make fewer than ~50 payouts a month, the vendor-consolidation savings won't justify the integration work. If your payouts are dominantly to a single market on a single rail (e.g. only ACH to US accounts), a specialized vendor in that lane may be sharper-edged.

Payouts at scale. One ledger.

Talk to our team about consolidating your global payout operation.