Every client payment, tracked to the cent. Paid out in USDC, on your terms.
Your flat-percentage cut on every Stripe payment from your clients. Pending balances are settled in monthly payout batches. This page covers how that commission accrues, what every ledger row and status actually means, and how to add a payout wallet without losing funds to a single mistyped character.
Five steps happen between a client’s invoice and money in your wallet. Nothing here is manual on your side.
Client paysA client’s plan renews and Stripe processes that invoice on their workspace’s billing.
Ledger entry createdActionist writes a new row to your ledger for that payment. Nothing is aggregated or batched at this step.
Commission snapshotted at 25%The programme’s current rate is captured onto the row itself, not looked up again later.
Balance goes PendingYour cut sits in Pending until the next payout batch runs.
Settles in a monthly batchPending rows move to Paid together, once a month, in USDC.
Flat, not tiered. 25% is a hardcoded literal in the client contract. There is no ladder that changes with volume, and the ledger’s own column header spells it out: “Your cut (25%)”.
Snapshotted, not recalculated. Each row keeps the rate that applied when it was created. If the programme rate ever changes, your historical rows are unaffected.
Reversals, never edits. A refunded or disputed client payment adds a new row pointing back at the original entry. The original row is never rewritten or deleted.
Worked example. A client on the Pro plan renews for $122.00 through Stripe. Actionist writes one ledger row for that invoice, snapshots the current 25% rate onto it, and calculates $122.00 × 25% = $30.50. That $30.50 is your cut. It sits in Pending until the next monthly batch runs, then moves to Paid, untouched by anything that happens to the programme rate afterward.
Stretched over a full cycle, that one row looks like this.
Point in time
What’s true of that $30.50 row
The day the invoice is paid
Ledger row created, Status: Pending.
Every day after, until the next batch
Still Pending. Counted in your Pending balance tile.
The day the monthly batch runs
Status flips to Paid, and it’s included in that batch’s USDC transfer.
After the batch
Counted in Paid to date. No longer part of your Pending balance.
Multiply that one row by every client you onboard, and the four tiles in the next section are just this table, summed.
A row marked Pending (not payable) has been accrued correctly, but Actionist has blocked it from moving into a payout batch. The row does not show why. There is no toggle, no form, and no setting on your side that changes this.
Don’t spend time re-checking your payout wallet or your client’s plan looking for the cause. This is an Actionist Support case. Contact [email protected] and include:
The client name shown in the Client column.
The invoice month shown in the row’s Description column.
The amount shown in Your cut (25%), so support can find the exact row.
Support can see the reason behind the block even though you can’t. There’s no form on this page that will surface it for you, so don’t go looking for one.
A block applies to that one row, tied to one client and one invoice. It doesn’t touch commission from your other clients, and it doesn’t affect your ability to add clients, run delegated sessions, or use anything else on your dashboard.
When a client’s payment is refunded or disputed after your commission has already accrued, the ledger does not touch the original row.
A new row, not an edit. The refund or dispute produces a separate reversal row that points back at the original ledger entry. The original stays exactly as it was, with the same client, description, and amount it always had.
Rates stay put. Because commission is snapshotted per row, a reversal that appears after a programme rate change still nets out against the rate the original row actually used, not today’s rate.
Nothing is deleted. Your ledger is a complete history. A reversed payment leaves a visible trail of two rows rather than one row that quietly disappears.
If a reversal lands after the original row has already been paid out, that’s a support conversation. Reach out the same way you would for a blocked commission: [email protected].
Worked example. The Pro plan row from the earlier example earned you $30.50 in commission on a $122.00 client payment. Two weeks later, the client disputes that charge with their card issuer and Stripe refunds it. Actionist doesn’t delete or edit your original $30.50 row. It adds a second row that points back at the original, netting your commission on that invoice back to zero. Your ledger still shows both rows, so the history stays complete.
Pending balances settle in monthly payout batches. Everything sitting in Pending on the day a batch runs moves to Paid together, in USDC, to the wallet you have configured.
For the specific timing of your next batch, look at the Next payout tile on the Revenue page rather than assuming a fixed day. It counts down in days and names the payout network, for example “in 12 days · USDC on Base.”
The date behind the Next payout tile is an estimate, not a guarantee. Treat it as a planning signal, and don’t commit to a client on a specific payout date based on it. If the tile shows ”—”, no next-payout date has been computed yet, check back later rather than assuming something is wrong.
If a client asks when you’re getting paid on their account, point to the fact that payouts run monthly rather than quoting a day from the Next payout tile. The tile is there for your own planning, not as a commitment you pass along.
Omar · Agency owner
Checks the Next payout tile once a week rather than daily. The countdown only matters once it’s down to a handful of days, so a weekly glance is enough to plan around.
one habit, once a week
June · Solo consultant
Skims the ledger for any Pending (not payable) row right after each client’s invoice date, since that’s the earliest point a block would show up, and emails support the same day if one appears.
checked right after invoicing
Your ledger and a client’s own billing history are two different views of the same underlying payment. Yours shows commission, theirs shows their invoice. See Billing for what a client sees on their side.
Payouts move on-chain, in USDC, and on-chain transfers cannot be undone. The flow is two separate steps on purpose: submit an address, then retype and confirm it before it goes live.
1
Open the payout method card
On the Revenue page, the payout method card shows your current state. Click Add wallet if none is configured, or Change wallet to replace an active one. If support has disabled payouts on your account, this becomes a non-interactive Disabled button and the flow below does not apply, contact support instead.
2
Read the warning before you touch anything
The modal opens with an eyebrow reading “Irreversible · Add wallet” or “Irreversible · Change wallet” (or “Verify · Confirm wallet” if you’re returning to confirm one already submitted), and a title to match: “Add your payout wallet”, “Change your payout wallet”, or “Confirm your payout wallet”. The intro line is direct: “Crypto payouts are final and on-chain. Once a payout transaction is broadcast, Actionist cannot reverse it, recall it, or recover funds.” Below that: “If the address is wrong by a single character, your funds are lost forever.”
3
Pick the network
Choose from Base (USDC), Ethereum (USDC), Polygon (USDC), or Arbitrum (USDC). Base is the default, and it’s the network Actionist recommends unless you have a specific reason to use another. The Token symbol field is read-only, it always reads USDC, and no control on the modal changes it.
4
Paste the address
Paste your full receiving address: 42 characters, starting with 0x, followed by 40 hexadecimal characters. Help text tracks it as you go: “Paste your full receiving address (42 characters, starts with 0x).” before you start, “Format looks valid. Confirm below by retyping or pasting again.” once it matches the pattern, or “That doesn’t look like a valid Base address. Expected 0x followed by 40 hex characters.” if it doesn’t. The modal only checks the format, so a hardware wallet address or a multisig address works exactly like any other, as long as it’s a valid address on the network you picked.
5
Check all three acknowledgements
You must check all three before submitting: that you verified this is a USDC address on the Base network and not another chain, that an incorrect address cannot be recovered and Actionist is not liable, and that you control this wallet and it is not a shared or guessed exchange address.
6
Submit the address
Click Save wallet address (or Replace wallet address if you’re changing an existing one). A toast confirms “Wallet submitted. Awaiting confirmation.” The payout method card now shows “Pending: {{addr}} (awaiting confirmation)” instead of an active wallet.
7
Retype it to confirm
Submitting doesn’t finish the flow, it only stages the address. A second step asks you to retype the pending address exactly. This field doesn’t give you live mismatch feedback as you type, it holds at “Re-paste to confirm, we compare character-by-character.” and the Confirm wallet button stays disabled until what you typed matches character for character, at which point it resolves to “Addresses match.” (or “Addresses do not match.” if it doesn’t).
8
Confirm
Click Confirm wallet. A toast confirms “Payout wallet confirmed.” and the card switches to its active state: the first six characters of the address, an ellipsis, the last four characters, and ”· receiving address on file” underneath, with “Confirmed {{date}}” as the secondary line.
Changing an existing wallet runs through the exact same eight steps, with “Change wallet” and “Change your payout wallet” in place of “Add wallet” and “Add your payout wallet”. A confirmed wallet stays active until you complete both the submit step and the retype-and-confirm step for a replacement, there’s no state where an old and new address are both live at once.
Add your payout wallet
Irreversible · Add wallet
Crypto payouts are final and on-chain. Once a payout transaction is broadcast, Actionist cannot reverse it, recall it, or recover funds.
Only use a USDC-compatible address on the Base network. Sending to the wrong chain destroys the payout.
Do not use a centralized exchange deposit address unless it explicitly supports USDC on Base.
Triple-check the first 6 and last 4 characters. Clipboard hijackers swap addresses silently.
Actionist staff will never ask for your seed phrase or for a test payment.
Network
Base (USDC)
Token symbol
USDC
Receiving address
0x7a3Fb92c…pasting
Format looks valid. Confirm below by retyping or pasting again.
I verified this is a USDC address on the Base network, not another chain.
I understand an incorrect address cannot be recovered and Actionist is not liable.
I control this wallet. It is not a shared or guessed exchange address.
Save wallet address
Once you click Confirm wallet, the address is live and the next payout batch will send USDC to it on Base by default. Actionist cannot reverse a broadcast payout, recall it, or recover funds sent to the wrong address or the wrong chain. Retype it carefully, and check the first six and last four characters before you confirm.
Actionist staff will never ask for your seed phrase, your private key, or a “test payment” to verify a wallet. Treat any message asking for one as a scam, and report it to [email protected] without following its instructions.
A payout confirmed is a payout sent. There’s no undo button on-chain.
why the flow makes you retype the address before it goes live
The payout method card only ever shows one of these at a time. The button next to it changes with the state.
What the card shows
What it means
What to do
”No wallet on file. Add an address to receive payouts”
You haven’t configured a payout method yet. Your commission still accrues normally.
Click Add wallet and complete the two-step flow above.
”Pending: {{addr}} (awaiting confirmation)“
You submitted an address but haven’t completed the retype-and-confirm step.
Click Confirm wallet, retype the address exactly, and confirm.
”{{head}}…{{tail}} · receiving address on file”
An address is confirmed and active. Payouts will go here.
Nothing, unless you’re replacing it. Click Change wallet to do that.
”Payouts disabled by support.”
Actionist support has disabled payouts on your account.
Contact [email protected]. The button reads a non-interactive Disabled.
”Could not load your payout method.”
The card failed to load.
Click Retry.
”Payout details are temporarily unavailable. {{reason}}”
A backend condition is temporarily blocking your payout details, with a short reason attached.
Read the reason shown. If it’s unclear or persists, contact support.
The address itself always renders the same way: the first six characters, an ellipsis, then the last four. A secondary line underneath reads “Confirmed {{date}}” once active, or “Updated {{date}}” after a change. The network line above it reads “{{token}} on {{network}}”, which defaults to “USDC on Base”.
No wallet configured
Commission still accrues normally, moving through Pending and eventually Paid.
The card reads “No wallet on file. Add an address to receive payouts”.
Nothing moves in the next payout batch. There’s nowhere for it to go yet.
Wallet confirmed
The card shows the first six and last four characters of your address.
”· receiving address on file” and “Confirmed {{date}}” sit underneath it.
The next monthly batch pays your Pending balance to that address, in USDC.
None of this changes how commission accrues. Whether or not you’ve configured a wallet, every client payment still writes its own row, still gets its 25% snapshotted, and still moves through Pending toward Paid. A wallet only determines where the money goes once it’s ready to move.
The Revenue page has three independent panels: your KPI tiles, your payout method, and your ledger. Each fails and empties separately.
Message
Where it appears
Next step
”Could not load revenue totals.”
The four KPI tiles at the top of the page.
Click Retry. Your underlying commission data is unaffected, this is only a load failure.
”Could not load your payout method.”
The payout method card.
Click Retry. Your wallet configuration, if any, is unaffected.
”Could not load the transaction ledger.”
The ledger table.
Click Retry.
”No transactions yet.”
The ledger table, when it loads successfully but is empty.
Nothing to do. This is the normal state before your first client payment.
Each of these is a genuine load failure, not a sign that your commission or your wallet has been reset. Work through it in order before contacting support:
Click Retry on the panel that failed.
If it fails again, reload the whole page.
If it still fails, treat it the same way as a blocked commission and reach out to Actionist Support.
A failed load on one panel doesn’t tell you anything about the other two. It’s normal for your KPI tiles to load fine while the ledger is still spinning, or the other way around.
25% flat commission, snapshotted per row, never recalculated after the fact.
Reversals are new rows, not edits · payouts settle monthly in USDC · nobody at Actionist will ever ask for your seed phrase.
