Staged Payouts

What it is

A staged payout pays in parts instead of all at once. The brand pays Zooly as it always does, the money stays put, and the talent is paid out through Stripe in the shares the two sides agreed: for example half when the brand pays, and half once the post is live.

The parts are not a new way to charge anyone. How the brand pays does not change. This only decides when the money goes out. The money sits in Zooly's Stripe balance until a part is due, and a part only goes out of money the brand has actually paid in.

One offer can carry up to six parts, and they must add up to the whole. A part never goes out before the one in front of it.

The moments a part can go

Each part is tied to one moment a person would recognise:

A common schedule uses two of them, such as half when the brand pays and half on proof.

The proof a part can wait for

A part that waits for proof names the proof it needs. The choices are:

• Delivery — the work was handed over
• A link — the post, video, or page, by its address
• A screenshot — a picture of the result
• An aircheck — the audio or video as it went out
• A report — the numbers afterwards

When the talent marks the work delivered, that delivery becomes the proof of the first part that is waiting for one. A proof is not enough on its own: it also has to be approved. That happens when the brand accepts delivery, or when someone on the team approves it.

How the split is read from the deal's words

The schedule starts from the payment line the offer already carries: the words the two sides agreed. On the Payouts page, that wording sits in a box. Preview shows the parts it reads from it, and Save schedule keeps them.

It understands the way people actually write a split:

• "50% upfront, 50% on proof (link)"
• "half on signing and half once the post is live"
• "$1,000 deposit, rest on completion"
• "30/70 on signing and on delivery"

When the words do not say when a part is due, it ties that part to completion, the latest moment, rather than guessing earlier. Waiting longer is the safe side with money. When the parts do not add up to the whole, or a split like "30/70" does not say when each part is paid, it refuses and says so instead of inventing the rest.

An offer with no schedule

An offer with no schedule behaves exactly as it does today. It pays once, when the brand accepts delivery, and no parts are created for it. Nothing about that offer changes unless someone sets a schedule on it.

A schedule cannot be added once the brand's payment has already been booked for the old way, and cannot be changed after a payment attempt has been made against it. It also cannot be set on a deal that is completed, cancelled, rejected, expired or disputed.

If the old way still ends up booking payouts for the same payment, the parts stop as blocked instead of paying a second time.

If someone cannot receive money yet

Payouts go to a talent's own Stripe account, and to an agent's if the agent earns a share. Someone who has not finished setting that up cannot be paid yet.

• They are asked once, after the deal is agreed, the first time the parts are checked (when the brand pays, when the schedule is saved, or at the daily check): a notice says to connect Stripe in Settings › Payouts & verification, and that the money waits safely until they do.
• The part that is due sits in a waiting for Connect state. It goes out by itself as soon as verification completes, even if that news arrives from Stripe rather than from the person.
• A daily check re-reads the status of anyone still waiting, so a missed notice does not strand money.
• One ask covers every part of that deal. Nobody is reminded part by part.

What the brand sees

• The deal is not held up. The brand accepts delivery and completes a staged deal as usual. There is no "the talent must finish setup first" wall on a scheduled offer.
• Accepting delivery approves the proof. That is what lets a proof part go.
• Nothing new to watch. The brand is not asked to look at stages, states, or transfers. That is the team's screen.

What the talent sees

• The split, in the deal's own words. The payment line on the offer says how the money is shared, in the words both sides agreed.
• Different wording when the deal completes. When the brand accepts delivery, the notice says the payout is released in the stages the deal sets, instead of saying the payment was released.
• A notice per part. Each release sends a notice saying how much is on its way and which part it is, for example "50% on proof". The notice is sent once, even if two checks run at the same moment.
• One ask to get set up, if their account is not ready, and then the money moves without them chasing it.

There is no separate screen yet where the talent can watch each part's state.

On the deal timeline

Every release is written on the deal timeline with its amount and the name of the part. So is every failure, every proof attached and approved, the ask to connect, the schedule itself, and any release a person forced by hand.

Each release and each failure is written once, even if two checks run at the same moment.

Writing the failure down matters as much as writing the release: a transfer Stripe refused shows on the timeline instead of disappearing. The daily check tries again, and after five refusals the part stops and waits for a person. See Deal Record.

When Stripe's answer is unclear (a timeout or a server error), the transfer is not counted as refused. It stays in flight, and the next check asks Stripe again for that same transfer, so it can never go out twice.

The Payouts page

Payouts in the admin sidebar is where the team watches and steers this.

On the left is everything that needs someone: parts waiting for Connect, for proof, for the brand's money, or for a moment that has not come, plus anything failed, blocked, or in flight. Picking one opens that deal:

• the brand and the deal's status, the talent's amount, and what the brand paid
• the payment wording and the proof the deal names
• each payee, with what they are owed, what has gone out, their Connect state, and whether they owe Zooly an advance
• every part, in order, with its share, its moment, its state and reason, its proof, and its transfers
• Check rules now, which runs the same checks the automatic ones use and releases anything now due
• the schedule box, to read the deal's wording and save the parts

If releases are paused, a red note at the top says so and nothing goes out.

Release now

Release now appears next to a part only when the money rules would allow it, and the button names the exact amount. Where it cannot go, the page says what is missing instead.

The dialog is deliberately plain: it says the amount leaves Zooly's Stripe balance for the payee's account now, and that it skips only the moment and the proof check. It asks for a reason (at least five characters) and for the word RELEASE typed in. The amount and the reason are written down before the money moves, and a double click sends once. If the amount has changed since the page loaded, it refuses and asks for a reload.

Skipping the moment and the proof is all it does, apart from one thing: it can also release a part that stopped after five refusals. It still refuses if the brand has not paid, if it would pay more than was paid, if the payee cannot receive money, if they owe an advance, if an earlier part has not gone out yet, if the deal is disputed or dead, if the payment was already booked the old way, or if releases are paused.

Money Zooly never fronts

• Nothing goes out before the brand's payment has gone through.
• A payee is never paid more than their share of what the brand actually paid in.
• Each transfer comes out of the brand's own payment, so Stripe holds the same limit at its end.
• If the brand pays in more than one go, a part waits until enough of the money has arrived.
• Each transfer goes out in the currency the brand paid in. A payment in a different currency from the deal stops the part as blocked.
• The cents add up: the last part pays exactly the rest, so the parts total the talent's share.

What it does not do yet

• A schedule is not set automatically for every new deal. Someone on the team sets it from the deal's wording on the Payouts page.
• There is no talent screen for the parts. The talent sees the split in the deal's words and gets a notice at each release.
• A refund is handled the way it is today. A refunded payment no longer funds any part, so later parts stop. Money that already went out is treated as an advance to recover, not pulled back.
• A partial refund is not subtracted yet. The later parts still count the full payment, as if nothing was refunded.
• An outstanding advance stops a part for a person to settle. The page shows it; nothing releases past it on its own.

Related Documentation

• Stripe Connect — how a talent gets set up to receive money
• Offer approval and brand payment — when the brand pays, and what the talent sees
• Deal Record — the timeline every release and failure is written on
• Done Deal — where the money fits in the whole path