ProjectCollab Payment Terms

Version 2026-09-15. Effective September 15, 2026.

These Payment Terms apply to every payment, allocation, transfer, refund, cancellation, attendance adjustment, chargeback, and payment dispute processed through ProjectCollab. They supplement the Terms of Service and the applicable Creator or Client Supplemental Terms.

1. Important definitions

1.1 Accepted quote means the amount the client agrees will be allocated among the lead and crew for the job.

1.2 Processing fee means the payment-provider cost shown as a separate line and added to the client's charge. It is not deducted from the accepted quote or any creator allocation.

1.3 Gross charge means the accepted quote plus the processing fee and any other amount the client separately approves.

1.4 Allocation means the frozen amount assigned to one lead or crew participant.

1.5 Platform balance means the payment amount captured through Stripe and recorded by ProjectCollab as held for the booking until release, refund, or another permitted movement. It is not escrow.

1.6 Wrap means the booking action that records final attendance, freezes the displayed allocation split, creates review windows, and makes eligible allocations payable.

1.7 For the administrative dispute process, a working day is Monday through Friday excluding U.S. federal holidays as observed, measured in America/Los_Angeles time. A deadline expires at 11:59 p.m. in that zone, with its equivalent displayed in the user's recorded local time. Three- and seven-day response/appeal periods mean calendar days.

2. ProjectCollab is not an escrow provider or bank

2.1 Payment is captured at acceptance and held as a Platform balance. ProjectCollab does not describe or market this service as escrow.

2.2 A Platform balance is not a bank account, deposit account, stored-value account, trust account, or escrow account; does not earn interest for a user; and is not represented as FDIC-insured for the user.

2.3 Stripe provides payment processing and connected-account services under its own agreements. ProjectCollab maintains an internal double-entry ledger and transaction records, but those records do not themselves move money at the provider.

2.4 The parties authorize ProjectCollab to direct Stripe to hold, transfer, refund, or otherwise process amounts only as these Payment Terms and the accepted transaction permit.

3. Acceptance and capture

3.1 The client authorizes capture of the gross charge when the recipient accepts the offer.

3.2 An offer is not accepted into a live booking unless the payment path reaches the state required below. No creator should block a date for a live booking without the required payment state behind it.

3.3 For cards:

1. Stripe attempts capture at acceptance;
2. if capture is declined, no booking becomes live, the offer remains pending until its original expiration, and both sides receive a visible failure;
3. the client may retry while the offer remains valid;
4. if Stripe's result is unknown, the transaction remains non-live while ProjectCollab reconciles it; and
5. if capture succeeds but booking creation fails, ProjectCollab retries the same finalization idempotently and then issues an idempotent refund if it cannot safely finalize.

3.4 A booking never becomes live merely because an asynchronous retry later finds a payment that both parties reasonably treated as failed. The acceptance must be explicitly retried when the Platform says so.

3.5 A payment-provider authorization may be changed, delayed, rejected, reversed, or subject to network rules. ProjectCollab does not guarantee a provider result or settlement time.

4. ACH and delayed settlement

4.1 ACH may be offered only when the shoot is far enough away for the expected clearing date under the Platform's U.S. banking-calendar rule. The current threshold is seven days, but eligibility is checked against the estimated clearing date—not raw calendar distance alone.

4.2 When ACH is initiated:

1. the booking is conditionally held in payment-pending status;
2. it is not live while funds clear;
3. the creator may plan a roster and prepare crew offers but cannot send them;
4. the client and creator see that payment is clearing and the expected local date;
5. a successful clearing event activates the booking atomically; and
6. a failure or return before activation prevents activation and requires an explicit retry.

4.3 A later provider success after a pre-activation failure does not silently activate the booking.

4.4 If ACH returns after activation, the booking remains live, crew commitments remain valid, and ProjectCollab handles the returned amount as a Platform loss/recovery event under Section 14. Crew already paid are not clawed back.

4.5 Estimated clearing dates are estimates, not guarantees.

5. Fees and currency

5.1 The processing fee is shown to the client as a separate line and added to the charge. It is never subtracted from a lead or crew allocation.

5.2 The processing fee is calculated on the grossed-up amount needed to preserve the accepted quote after provider fees, not simply as a percentage of the quote.

5.3 ProjectCollab currently charges clients and creators a 0% Platform fee for job bookings. Provider processing costs remain separately payable by the client. This does not waive separately disclosed rental, coverage, AI-credit or other product-specific charges. A future Platform fee applies only after disclosure and required acceptance and must be reflected in the transaction snapshot; it cannot rewrite an existing commitment.

5.4 The accepted offer states the transaction currency. Currency conversion, cross-border costs, and recipient-bank fees are the user's responsibility unless the checkout expressly says otherwise. Cross-border support is not currently approved for the pilot.

5.5 Where applicable law requires an all-in advertised or offered price, mandatory fees are included in that total even when also itemized. Showing a processing-fee line does not excuse a misleading headline price.

6. Allocations and privacy

6.1 Every paid booking has separate allocations for the lead and each crew recipient. The accepted total is separated from downstream booking snapshots so crew cannot infer another participant's pay through the booking record.

6.2 Each participant can see their own allocation. The lead can see allocations needed to staff and release the booking because the lead sent those offers. The client can see the roster and accepted job total, but not individual crew offer revisions or crew allocation amounts.

6.3 An original applicant may retain the immutable exact posting snapshot and compare it with their own rate. That access is intentional even if the same person later becomes crew.

6.4 Free text must not be used to publish another participant's pay, exact private location, bank details, tax details, or other protected information.

7. Changes before wrap

7.1 An accepted crew rate cannot be reduced unilaterally by the lead, client, ProjectCollab, or anyone else.

7.2 A lead may increase a crew allocation unilaterally when the additional amount can be funded from the lead's own allocation. The Platform consumes the lead's allocation first and refuses the change rather than silently charging the client.

7.3 An increase above the client's original captured commitment requires a separate request stating the amount, reason, and allocations covered. The client may approve or decline. Approval triggers an additional capture before the allocation increases. Decline changes nothing and is not a dispute.

7.4 A top-up cannot be requested after wrap.

7.5 Unfunded increases are refused.

7.6 A participant who did not attend may be marked no-show based on attendance facts. An allocation for partial work or a mutually agreed lower amount may be changed only through a reduction offer the participant accepts. If the participant declines, the question goes to a participant-scoped dispute; unrelated allocations stay unaffected.

8. Wrap and release

8.1 At wrap, the lead sees the proposed split. Confirming wrap atomically:

1. records the wrap decision and attendance state;
2. freezes each displayed allocation so later edits cannot change what the participant saw;
3. makes eligible allocations payable; and
4. creates double-blind review windows for lead/client and lead/each crew member.

Wrap opens only after the last scheduled shoot day ends. Eligible crew allocations release at wrap. The lead's own share becomes eligible when the client confirms that the shoot happened, or seven days after wrap if the client takes no action, subject to applicable disputes, funding and recipient-readiness safeguards. Crew do not wait for the lead's confirmation window.

8.2 Wrap does not itself make one combined payout. ProjectCollab initiates a separate Stripe transfer for each eligible allocation. Recipients are released directly in one Platform action, but transfers may complete, fail, or retry at different times.

8.3 A failed transfer does not undo successful transfers. The affected recipient and lead see the failure state and reason appropriate to them. Provider or transient failures retry automatically; the lead cannot manually redirect or reissue a participant's allocation to someone else.

8.4 Payout execution currently runs as reviewed manual runs rather than on an automatic schedule.

9. Transfer safeguards and order

9.1 The executor uses persistent transfer-attempt identifiers and provider idempotency safeguards so retrying a run does not intentionally pay twice. An unknown outcome must be reconciled before another transfer is attempted. A fresh attempt is permitted only under the verified retry rules after a definite failure, not merely a timeout.

9.2 Transfers are ordered:

1. crew before lead;
2. within crew, smallest allocation first; and
3. lead last, only after every crew allocation for that booking is paid, permanently refused, or falls under the completed-onboarding grace rule in Section 10.

9.3 Database-enforced limits apply per allocation, per execution run, and across a rolling 24-hour period. Reaching a limit delays payment; it does not reduce or erase the allocation. The safety limits may change prospectively as risk and legitimate volume change without rewriting an existing allocation; they are operational safeguards, not financial terms.

9.4 A transfer is refused at claim time and rechecked before the provider call if the booking is not live, is cancelled without an approved settlement, the allocation is disputed, the source payment is not safely funded, payout setup is incomplete, a cap would be exceeded, or reconciliation is pending.

10. Incomplete payout onboarding

10.1 A crew member's payable allocation never expires because Stripe onboarding is incomplete.

10.2 For seven days after the allocation becomes payable, incomplete onboarding blocks the lead allocation and triggers reminders. After seven days, the lead may be paid, while the crew allocation remains payable indefinitely.

10.3 When the crew member later becomes Payment Ready—even after the lead was paid—the allocation automatically becomes eligible for the next payout run without manual intervention.

10.4 Notices are sent at wrap, day 3, day 6, and monthly after day 7 until onboarding is completed or the money is lawfully claimed. The day 3 and day 6 notices may explain that the lead's payment is waiting. They must never imply that the crew member's money is expiring or at risk.

10.5 User-facing dates and deadlines render in the recipient's recorded local time zone. UTC remains the stored instant, not the presentation rule.

11. Cancellation

11.1 Rescheduling by mutual agreement between the client and the hired creator is the first priority. Neither party must accept a replacement date. If the client cancels without an agreed reschedule within 24 hours before the scheduled work, the cancellation amount is 50% of the accepted service amount, calculated as set out in Section 11.2. Cancellations should first be addressed between those parties and recorded, not decided by ProjectCollab as a matter of creative quality.

11.2 For a single-day service booking canceled before work begins, the 50% is calculated on the accepted service amount for the canceled work, excluding processing fees, taxes and separately priced rentals or expenses. The window includes exactly 24 hours before the recorded start time, using the shoot's time zone. Notice is effective when delivered through the booking conversation or another agreed written channel, not when later read; retain evidence of delivery. A reschedule becomes effective only when both parties record acceptance of the new date and any price change. A request alone does not postpone effective cancellation notice. An affected crew member must separately agree to changes in their own commitment; lead/client agreement cannot waive crew rights.

The parties may agree a lawful lower amount or waive their own claim. Multi-day/partial cancellations, recipient allocation of a cancellation payment, expenses, provider cancellations, weather, illness, unsafe or unlawful work and force majeure require an express recorded settlement or reviewed booking-specific terms; do not automatically apply 50% of an entire multi-day quote. No settlement may double-count work, take protected attended-crew amounts or waive another participant's rights. Non-waivable rights control.

11.3 Each accepted booking stores the source, version, timing basis, and applied cancellation-rule snapshot. A later policy change must not silently rewrite an existing booking.

11.4 A cancellation issued before the shoot uses its snapshotted cancellation rule and is not reclassified as a no-show. If the client never cancels, fails to attend or provide required access, and the creator attends ready to work, the current product rule owes the accepted amount.

11.5 The cancellation amount is applied through a recorded settlement, not an automatic deduction. Existing bookings keep their original terms.

12. Refunds

12.1 A client's refund is net of crew allocations for people who attended. A lead/client dispute cannot take back or delay those attended crew amounts.

12.2 A participant-specific attendance dispute may hold only that participant's allocation. Unrelated crew remain payable.

12.3 ProjectCollab does not absorb payment-processing costs actually incurred and not returned by the provider. To the extent lawful and permitted by provider rules, those costs remain the client's responsibility and are shown in the refund breakdown. A processing cost that was not incurred or was returned by the provider must not be retained as a non-refundable cost. This policy does not override mandatory refund rights or shift ProjectCollab's own legally non-transferable liability to a client. No such cost is deducted from protected creator or crew allocations.

12.4 Refunds return to the original payment method where possible. Provider timing controls when the client's bank posts the credit.

12.5 ProjectCollab does not release a refund that would make the ledger inconsistent with protected attended-crew obligations. Any residual amount waits for an approved settlement.

12.6 Before release, the contracting parties may record a proposed full or partial settlement identifying the amount and affected work. Only participants whose own rights are affected may agree to compromise those rights. The Platform must validate available funds, previous credits and protected allocations before execution. A pending provider dispute may require reconciliation before a separate refund is issued to avoid duplicate reimbursement; mandatory rights and provider deadlines remain controlling. After release, the Platform administrative process remains closed; any voluntary agreement between users does not authorize ProjectCollab to debit a recipient or claw back attended-crew pay.

13. Platform payment disputes

13.1 The Platform process decides whether agreed work happened and how held funds should move under these Payment Terms. It never judges whether creative work was good.

13.2 Disputes are scoped narrowly:

1. a client/lead dispute can hold the lead's allocation but not attended crew allocations;
2. a dispute about one crew participant can hold only that participant's allocation; and
3. unrelated bookings and allocations are not frozen solely because the same user is involved.

13.3 Evidence is evaluated in this order, with context. Contemporaneous evidence generally carries more weight than a statement written after a dispute begins:

1. a signed Service Contract that directly answers the question;
2. the accepted offer terms, including scope, dates, call, and wrap;
3. contemporaneous structured Platform records, including acceptance, call-sheet delivery, job state, attendance, change approvals, and payment events;
4. third-party accounts from people such as crew who were present;
5. the job conversation and contemporaneous files; and
6. each party's account written after the dispute began.

13.4 The following rules do not require a judgment about creative quality:

1. a recorded pre-shoot cancellation uses the snapshotted cancellation rule and is not a no-show dispute;
2. a client no-show claim contradicted by credible crew attendance evidence proceeds as a scope question, not a no-show;
3. when neither contracting party can evidence attendance, the client receives the available refund, net of crew independently shown to have attended;
4. when both sides agree on facts and differ only on amount, the process moves directly to a proposed settlement; and
5. when a complaint concerns only quality and does not contest attendance or delivery, the accepted amount is released and quality may be addressed in a review.

13.5 The responding party has three calendar days after notice to respond. No response is not an automatic win, but may be weighed with the record. ProjectCollab may propose a settlement and will issue a decision no later than the end of the fifth working day after receiving the dispute; the next working day is day one. A request for more evidence does not restart that clock. One appeal may be filed within seven calendar days after decision notice and must identify material new evidence not reasonably available before; disagreement alone is insufficient. Section 1.7 defines the administrative calendar. Mandatory legal process controls where it prevents action; explain that restriction and preserve unrelated allocations.

13.6 Disputes are recorded with their participants, evidence, proposals, responses, and decisions. A declined allocation reduction creates a three-day response deadline.

13.7 A dispute may be opened at any time before release and not afterward. The wrap confirmation identifies release as final before the user confirms. The other party receives the wrap/release outcome through the Platform's transaction notice.

13.8 Once release occurs, ProjectCollab does not reopen the Platform dispute process, reverse a participant's transfer, or claw back attended crew pay. Any unresolved claim is between the Service Contract parties. ProjectCollab will provide the available agreement, job conversation, and audit trail to an authorized party, subject to the Privacy Policy and lawful process.

13.9 A client may still invoke a payment-provider chargeback after release. A chargeback is not a reopened Platform dispute. Section 14 applies: crew keep released money and ProjectCollab bears and records the provider loss while any client recovery remains separate.

13.10 ProjectCollab will use a more-likely-than-not standard for administrative payment decisions.

13.11 The primary decision-maker is Jake Larson, ProjectCollab operator. He must disclose a personal or financial conflict and must not decide his own transaction; ProjectCollab will arrange an unconflicted reviewer for such cases and for an appeal before deciding them. Unrelated attended-crew payments remain unaffected.

13.12 A terminal decision becomes final for the held balance when its resulting release occurs, absent provider reversal, legal process, or manifest clerical error. The Service Contract parties retain whatever legal claims they have against one another; any arbitration or small-claims case between them is not against ProjectCollab merely because ProjectCollab administered the Platform balance.

14. Chargebacks, ACH returns, and provider reversals

14.1 If a chargeback or late ACH return occurs after crew have been paid:

1. crew transfers are not clawed back;
2. the booking stays live if it was already activated;
3. ProjectCollab records the provider event once using the underlying balance-transaction identifier, even if duplicate webhook events arrive;
4. the Platform's reserve/loss ledger records the shortfall; and
5. recovery from the client is manual unless and until an approved recovery flow is built.

14.2 Client-funded proceeds held through Stripe fund the corresponding eligible participant transfers. They are not discretionary operating revenue and must remain available for their recorded obligations. This does not require creators to provide a reserve or authorize an additional client charge. With the current separate-charges-and-transfers design, Stripe may debit ProjectCollab for refunds, disputes and related fees even after a participant transfer. ProjectCollab remains responsible for obligations assigned to it by law and its Stripe agreement; using Stripe does not eliminate a possible shortfall. No fixed reserve amount is promised in these Terms.

14.3 The client remains responsible for valid charges, return fees, and lawful collection costs despite a chargeback or return. ProjectCollab may suspend paid activity and use legal recovery methods, but may not misrepresent a disputed debt.

14.4 If Stripe reverses a transfer or reports an unknown outcome, ProjectCollab may pause the affected allocation while reconciling the stable transfer group and provider balance transaction. It will not intentionally issue a replacement merely because a request timed out.

15. Taxes and reporting

15.1 Each user is responsible for their own tax obligations except amounts another party is legally required to collect, withhold, report, or remit.

15.2 ProjectCollab intends to use Stripe's supported tax-information collection and form-delivery services. Users must provide accurate information through the designated secure flow and update it when required. Electronic delivery is subject to applicable consent requirements; other delivery methods must remain available when legally required. Stripe tools do not determine worker status or transfer every filing or withholding obligation to Stripe. ProjectCollab and any other legally responsible party remain responsible for their applicable reporting and withholding duties. Earnings dashboards alone do not satisfy those duties.

15.3 Being described as an independent contractor, receiving a tax form or using Stripe does not by itself determine employment status. Each hiring relationship must comply with applicable classification, wage, payroll and other mandatory rules. These Terms do not waive worker rights or make all production roles eligible for contractor treatment.

16. Errors, prohibited activity, and legal process

16.1 Tell ProjectCollab promptly about an incorrect, duplicate, unauthorized, or missing transaction.

16.2 ProjectCollab may delay or refuse a transaction to comply with law, sanctions, provider rules, fraud controls, court orders, or these Terms. It may correct a clerical or technical error but cannot use an error correction to reduce an accepted crew rate without the process in Section 7.

16.3 Funds do not become a user's property merely because an interface displays a mistaken amount.

17. Payment records and notices

17.1 ProjectCollab keeps provider references, payment states, immutable event records, ledger postings, allocation and transfer records, audit events, and notices. It does not store raw card or bank credentials, Stripe identity documents, or complete tax forms in the application database.

17.2 Provider webhooks may be duplicated or arrive out of order. ProjectCollab processes them idempotently and records reconciliation state when order is uncertain.

17.3 Both sides receive visible notice of payment failure. Payout recipients receive notices of transfer failure or incomplete setup. The lead sees that a named crew member's setup is delaying lead payment and the date that grace ends, but not that crew member's private allocation amount.

18. Changes to these Payment Terms

18.1 A material change applies prospectively after required notice and acceptance. Existing offers, cancellation rules, posting budgets, accepted terms, allocations, and payment commitments retain their immutable snapshots unless law requires otherwise.

18.2 No operational change to a provider configuration may silently change these promises.