How do I configure splits?

Splits are configured via the API when creating a payment. Specify each recipient's wallet address and amount: the merchant amount plus the seller amounts must equal the payment total. See our API documentation at docs.pymstr.com for details.

Are splits percentages or fixed amounts?

Fixed amounts, set in fiat terms when the payment is created. A $100 payment might be $30 to the platform, $50 to the operator, and $20 to a partner. When the customer initiates payment, the amounts convert to the chosen stablecoin at a locked exchange rate, so every recipient knows exactly what they receive before the transaction is signed.

How does the 0.5% fee interact with splits?

PYMSTR's 0.5% fee is deducted proportionally from every recipient. On a $100 payment split $30 merchant / $50 seller / $20 partner, the fee is $0.50 and the recipients receive $29.85, $49.75, and $19.90. The merchant share absorbs any rounding dust so the totals always match exactly.

Do split recipients need a PYMSTR account?

No. Recipients are specified as plain wallet addresses. Sellers, affiliates, and partners receive their share on-chain without registering for anything. Only the merchant creating the payment needs a PYMSTR account.

What happens if one transfer in the split fails?

Nothing moves. The split executes as a single atomic on-chain transaction: either every recipient is paid in the same confirmed transaction, or the whole payment does not execute. There is no partial state where some recipients were paid and others were not, which is exactly the failure mode that makes multi-leg card and ACH payouts painful to reconcile.

Does the customer see the split?

No. The customer sees and pays a single amount. The split happens inside the same transaction after payment.

Is this different from sending multiple transactions?

Yes. It's a single on-chain transaction that distributes to multiple wallets. More gas-efficient, simpler accounting (one transaction hash covers every leg), and instant for all recipients.

Feature

Native Payment Splitting.

One customer payment, automatically split across multiple merchant wallets. Platform fees, payouts, commissions. Handled at the protocol level.

Launch app Book a call

The PYMSTR merchant dashboard: revenue, transactions, stablecoin and network volume

Why this exists

The problem

Marketplaces, platforms, and affiliate-driven operators move one customer payment to many parties: the platform fee to treasury, the operator payout to the merchant of record, commissions to affiliates or referral partners. On card rails this is a two-system problem. The processor batch-settles the gross amount to the platform on a T+2 to T+7 schedule, and the platform then redistributes through a second payout system: affiliate payouts on Net-30, operator payouts weekly by bank transfer, treasury sweeps monthly. Every leg adds its own reconciliation work (matching the payout ledger back to the original transactions), its own payout minimums and per-transfer fees, and its own failure modes when a bank rejects a transfer or an account changes. The error and dispute surface multiplies with every recipient. Generic crypto checkout does not fix this either: splitting a payment usually means sending multiple separate on-chain transfers, paying gas on each one, and trusting whoever runs the script to paste five wallet addresses correctly, every time.

The solution

PYMSTR splits a single payment across multiple wallets in one on-chain transaction. You set each recipient's amount when creating the payment through the API: the merchant amount plus the seller amounts must equal the total, and the amounts are locked in fiat terms at a fixed exchange rate the moment the customer initiates payment. The customer pays once. PYMSTR encodes every transfer into a single ERC-4337 smart-wallet transaction, so the split executes atomically: either every recipient is paid in the same confirmed transaction, or nothing moves. There is no batch to wait for, no second payout system to reconcile, and no partial state where the platform got paid but the affiliate did not. PYMSTR's 0.5% fee is deducted proportionally across all recipients, so a $100 payment split $30/$50/$20 settles as $29.85, $49.75, and $19.90, with the merchant share absorbing the rounding dust. Recipients are plain wallet addresses: sellers and partners do not need a PYMSTR account to get paid. Gas is abstracted through the smart-wallet flow, so nobody is juggling native gas tokens to receive their share.

Three steps, on-chain.

Configure splits via API

Set each recipient's wallet address and amount when creating the payment (e.g., $100 total: $30 merchant, $50 seller, $20 partner). Merchant amount plus seller amounts must equal the total.

Customer pays once

The customer makes a single payment. They see one amount, one transaction.

Funds split automatically

PYMSTR routes the stablecoins to each wallet according to your configured splits. All in one atomic transaction.

Splits settle on 5 networks

You choose which ones your checkout accepts.

Network	Gas	Settlement
Ethereum	~$2-10	~15 sec
Base	~$0.05	~2 sec
Polygon	~$0.01	~2 sec
Arbitrum	~$0.10	~2 sec
BNB Smart Chain	~$0.10	~3 sec

Payment splitting: split mechanics by rail

Rail	Split mechanics	Recipient payout timing	Reconciliation	Final by
Card platform payouts (processor + payout provider)	Processor settles gross to platform, platform redistributes via a second system	Net-7 to Net-30 per recipient	Manual ledger matching across two systems	Issuing-bank schedule + payout provider
ACH batch payouts	Separate ACH transfer per recipient, M-F NACHA windows	T+1 to T+3 per leg, no weekends	Per-transfer status tracking, returns possible for 60 days	NACHA windows + bank discretion
Custodial crypto PSP (CoinsPaid, B2BinPay)	Custodian splits on an internal ledger, then processes withdrawals	Hours to days at custodian discretion	Custodian ledger + withdrawal queue	Custodian operations
PYMSTR (non-custodial stablecoin)	One on-chain transaction pays every recipient atomically	Same confirmed transaction, 2-15 seconds, all recipients at once	One transaction hash is the ledger	Final once the network confirms

Integration: 3 paths

Three integration paths

The API

Time~5 min

Code1 POST with a sellers[] array

Formarketplaces + platforms

Read the API reference

Quickstart

Time~5 min

CodeCopy-paste first payment

Forfirst integration

Read the quickstart

Webhooks

Time~10 min

CodeHMAC-signed payment.completed

Forautomated payout accounting

See webhook events

What you get.

Single Transaction

One customer payment splits into multiple payouts. No batching, no manual redistribution, no separate transactions.

Instant Distribution

All recipients receive their share the moment the payment confirms. No waiting for batch settlement.

Up to 5 Recipients

Split a single payment across up to 5 wallet addresses by default. Need more? We can accommodate up to 1,000 recipients on request.

Gas Efficient

One transaction instead of multiple transfers saves on gas costs and simplifies accounting.

Short answers. No jargon.

Payment Splitting questions.

Up to 5 recipient wallets per payment by default. Need more? Contact us. We can accommodate up to 1,000 recipients for marketplace and platform use cases.

Payment splitting divides one inbound customer payment across recipient wallets in the same transaction, for example a marketplace sale split between the seller, the platform, and a referrer. PYMSTR Payouts is the outbound counterpart: you batch your own transfers to up to 100 recipients (affiliate commissions, player withdrawals, vendor settlements, payroll) into one signed on-chain transaction. Use splitting when money is coming in and needs dividing; use Payouts when you are sending money out.

0.5% flat · We never hold your money

Add stablecoin payments to your checkout.

0.5% flat. No chargebacks. Money lands in your own wallet in seconds.