Organizer Agreement

DRAFT — placeholder written by engineering on 2026-09-18. Not reviewed by counsel. Not for publication.

The terms that apply to an organization and to whoever accepts on its behalf, in addition to the Terms of Service. Drawn only from what the platform already implements: docs/architecture/fee-architecture.md, settlement-architecture.md, refund-architecture.md, event-ticketing-architecture.md and docs/architecture/authorization.md. Not reviewed, not publishable, and every commercial term is subject to the payment-provider decision that is still open (CLAUDE.md "Still open").

1. Who accepts, and on whose behalf

An organization is created by its owner, who accepts this agreement at creation. The acceptance and its version are recorded against the organization. Whoever accepts warrants that they may bind the organization — the exact warranty wording is counsel's. The owner may delegate roles (Event Admin, Event Manager, Event Staff, Scanner) to team members; delegation does not transfer this agreement, and the organization remains responsible for what its team does.

2. Your event

You are responsible for the event itself: that you may run it, that the description, date, place, age restriction and what a ticket includes are accurate, and that it happens as described. Sotillion provides the platform; it does not run your event.

3. Verification and payouts

• Verification is identity: staff confirm the organization is who it says it is. It is what gates publishing a job listing and what shows the verified badge.
• KYC is money, and it belongs to the payment provider. Payout onboarding happens on the provider's hosted flow; Sotillion never receives or stores a KYC document, only the provider's account id and the status it reports.
• A paid event cannot be published until the payout account is cleared.

4. Fees

Sotillion's service fee is added to the buyer's total, not deducted from your ticket price:

The gateway's own cost is inside that fee. A ₹0 ticket carries no fee and no payment at all. Fees are computed on the server from versioned configuration and snapshotted onto the order line at purchase; they are never recomputed afterwards. You settle the ticket amount. (docs/architecture/fee-architecture.md.)

5. Settlement

Money for a paid order is held and released to your linked account on a schedule:

release_at = max(event end, refund window end) + buffer (default 2 days)

The hold is what makes a cancellation refundable without recovering money from you afterwards. Transfers are reconciled against the provider; anything that does not reconcile goes to a finance exception queue and is worked by hand. (docs/architecture/settlement-architecture.md.)

6. Refunds and cancellation

• A buyer refunding inside your event's refund window gets the ticket amount back; the service fee and GST are kept unless your own policy says otherwise.
• A refund you initiate — cancellation, downgrade, goodwill — returns the ticket amount and the fee and GST to the buyer; the gateway cost is absorbed by the platform.
• If you cancel the event, every issued ticket is refunded in full, automatically, and the fee share is deducted from your settlement unless the event's policy assigns it to the platform.
• Refunds after your money has been transferred are recovered from you: the buyer is refunded first and the recovery is the platform's receivable, never the buyer's problem.
• The platform may force a refund in the cases listed in refund-policy.md.

(docs/architecture/refund-architecture.md.)

7. Attendee data

Attendee information is given to you to run your event and for nothing else. You are a processor of it: you may not sell it, share it or use it for unrelated marketing, and you must keep it secure and delete it when you no longer need it. The precise data-protection clauses, and whether a separate processing agreement is required, are counsel's.

8. Scanning and the door

Scanner operators are created and managed by you, and each one is scoped to a specific event. A ticket admits one person once; the first scan wins and any later scan of the same ticket is refused. Do not attempt to re-issue, duplicate or work around a ticket credential.

9. Conduct

Your event, your listings, your organization profile and your team's behaviour are subject to the Community Guidelines. Staff may suspend an account, take down a listing or decline verification.

10. Tax

Who the seller of record is, how GST applies to the ticket price and to the fee separately, and what an invoice must show are open questions for the accountant and must be settled before this section can be written (docs/architecture/payment-architecture.md, "Tax").

11. Term, suspension and termination

To be written by counsel, including what happens to events already on sale and to money already held when an agreement ends.

12. Liability

To be written by counsel.

13. Changes

This agreement carries a version string. When it changes, the organization's owner is asked to accept the new version before continuing to manage events, and the version and the moment of acceptance are recorded against the organization.

14. Contact

To be supplied. Grievance officer: to be appointed.