How deals work

Through a bid, which is an object with a state rather than an email with a number in it. A buyer opens one on a single file, on a pack of them, or, where the creator has opened themselves to commissions, on a brief for work that does not exist yet. It carries a price, the licence terms, an expiry, and a note of up to 500 characters, a limit the database itself refuses to exceed. Either side can counter, up to three rounds, and each counter sets a new price and note that become the live terms. The thread shows whose move it is, what changed in each round, and what the deal is worth to you, with the other side’s fee left to them. When both sides agree, the record of how they got there is already written.

No. A bid is a proposal and the composer says so on its face. Nothing is charged when you send one, nothing is charged when the creator accepts, and the deal binds only when the payment actually clears. That is also why a creator never sees an accepted bid with a declined card behind it: accepted here means the money arrived, not that someone clicked yes.

The bid tells you, in words, in the header: your move, or waiting on the other side. The accept, counter and reject controls are shown only to the side being waited on, so nobody has to re-read a thread to work out whether the ball is in their court. Withdrawing is the rule the database itself holds: a buyer can pull a bid only while the last recorded move on the thread was theirs, so once a creator has countered, the buyer has to act again before they can pull it.

Today a counter moves the price and the note. The rest of the deal, which files or briefs are in it, the licence terms and the deadline, is set when the bid is opened and travels unchanged through the rounds. Each counter is one atomic write: the new price and note become the live terms, so there is never a question of which version is on the table. The thread carries a short summary of every round, showing the fee before and after and whether the note changed, with the composition and the licence terms recorded as unchanged.

Yes, and it is the same machinery as a single frame. A pack holds up to twenty items from one creator, and the database enforces both the cap and the one-creator rule; the floor of one item is checked by the server when the bid is sent. It is negotiated as one total and accepted or rejected as a whole. The licence terms are uniform across a pack by construction, because rights are one field on the bid and there is no per-item rights field where a wider grant could be buried. Per-item list prices are shown as a reference; the only negotiated number is the total. Today a counter changes the price and the note, so re-cutting the composition of a pack mid-negotiation is not yet something the counter composer does.

Neither. The buyer picks the window when they send, from 24 hours up to 30 days, and it is stated in plain words rather than a timestamp you have to convert. A bid that neither side answers expires on its own within a minute of its deadline, and the expiry is written to the record, so it does not sit there as an open bid. A buyer can also grant more time explicitly rather than let a deal die on a clock. And a buyer can hold at most three open or countered bids with one creator at a time, so a creator’s desk cannot be flooded by somebody fishing for a yes.

No. While you type a counter, the number you care about updates next to it: a creator sees what would reach them after the platform fee, a buyer sees what they would pay on accept. Each side sees the figure that is true for them, and the platform never invents one. Where the platform fee rate is not configured, the panel says the fee is set at submit rather than printing a plausible number, and any figure it cannot compute is left out rather than guessed.

Acceptance is bound to the payment. The buyer’s card is charged first, and when Stripe confirms the charge one database transaction flips the bid to accepted, creates the assignment and writes both ledger entries, or none of it happens. The assignment holds no fee and no rate of its own: the money figures are read back from the bid by join, and the only term copied across is each piece’s revision cap, fixed at creation. One bid can produce only one assignment, so there is no second contract for one brief and no opportunity for the numbers to drift between what was agreed and what is executed. If a charge lands against a bid that has already expired or been withdrawn, no assignment is created, the case is flagged at critical severity, and the payment is refunded by hand.

Piece by piece, against the brief. A commissioned brief is broken into its individual pieces the moment the assignment is created, and the creator delivers each one on its own. Once every piece is in, the buyer reviews the delivery and can send any single piece back for revision. Each piece carries the revision budget written into the brief, counted in the open as used against cap, so both sides can see how many are left rather than arguing about it later. Asking for a revision pauses the acceptance clock; re-delivering restarts it. When a piece’s budget is spent the database refuses any further revision request on it, so the buyer accepts the work as it stands or opens a dispute, and cannot keep asking indefinitely. A deal for files that already exist has no pieces and no revision rounds: the creator confirms the handover in a single action.

A clock that runs in your favour. Once every piece is delivered, the buyer has fourteen days to confirm. If they confirm, the assignment is queued for payout on the next hourly run, with no further delivery hold. If they say nothing at all, the delivery accepts itself when the fourteen days close, and payout follows a further fourteen day hold that keeps the silent buyer’s dispute window open. Silence delays the money; it is never a way to hold the work for nothing. The buyer’s payment was taken when the deal bound, so acceptance releases money the platform is already holding rather than starting a collection. The transfer itself still needs your payout account set up and able to receive it, and the Portuguese withholding hold described in the Questions applies on top of all of this.

It enters a defined process, and either side can start it. Once the work has been delivered a buyer has named grounds: the work is incomplete, it is off brief, the rights do not match, the creator has gone quiet. If the agreed delivery deadline passes and the work has not been delivered, the buyer can open a dispute then too. A creator has their own, at any point in the assignment, including that they cannot deliver and that they suspect bad faith, which means a photographer who realises they cannot make a deadline has an honest exit rather than a vanishing act. Every ruling has to carry written reasons, and both parties read them in the dispute record alongside any amounts. A creator can appeal within fourteen days of the decision, and the account that made that decision cannot decide the appeal: the check runs in the database, against the ledger record of who decided, not in the browser.

No, and the separation is deliberate. A dispute about money, delivery or scope is written to the deal, to the dispute record and to the ledger. It is never written to the file’s provenance standing. A disagreement about an invoice is not evidence about a photograph, and the two records are kept apart so that a commercial argument cannot leave a mark on your work that outlives it.