Security, privacy and downstream use
How the platform holds participant information, who is allowed to see it, and how it reaches the operations, finance, merchandise and vendor teams.
Storing personal and payment information
Participant records live in a managed Postgres database with encryption at rest and TLS in transit. Every table has row-level security enabled, so a query returns nothing unless a policy explicitly permits it.
Payment rows store only the gateway reference, amount, currency, status and timestamp — enough for finance reconciliation and receipts.
Never storing card or banking details
Card capture happens entirely inside the payment gateway (Razorpay for India, Stripe for international cards). The app receives a payment identifier and a signed success callback; no card number, CVV, UPI handle or bank account is ever transmitted to or stored by this system.
Refunds and captures are performed through the gateway using that identifier, which keeps PCI scope with the gateway.
Restricting access by role
Roles are stored in a dedicated user_roles table (never on the profile row) and checked through a security-definer has_role() function, which prevents privilege escalation through a self-editable field.
Participants can read and write only rows belonging to their own booking. Operations staff see arrival, accommodation and merchandise data. Finance sees payment and balance data. Administrators see everything and are the only role able to authorise a repeated award.
Recording administrative changes
Every consequential admin action — milestone edits, award issuance, re-issue authorisation, reminder dispatch, refunds — writes an append-only audit_log entry with the actor, action, entity and a JSON diff.
The log is visible in the admin console under Log and can be exported for review.
Preventing duplicate participant records
Participants are unique per retreat on a normalised name plus contact key, and returning attendees are matched on email or phone across retreats so their profile, milestones and issued-item history carry forward.
Because history carries forward, a returning participant cannot be handed the same shield, medal or certificate twice unless an administrator records an explicit re-issue with a reason.
Supporting participants from many countries
Retreats carry their own currency and locale, phone numbers are stored in full international form, and country of residence is captured per participant so visa letters, arrival logistics and tax treatment can differ by nationality.
Dates and times are stored with the retreat's timezone context to keep arrival lists unambiguous.
Exporting and connecting downstream systems
The admin console exports a flat participant CSV covering booking, accommodation, payment, travel, dietary, merchandise and milestone columns — the shape the finance, vendor and merchandise teams already work in.
The same data is reachable over an authenticated API, so a future finance ledger or vendor portal can read it without a second data-entry pass.
Consent, privacy and deletion
Consent for additional activities, photography and health-data handling is captured per participant with a timestamp, and can be withdrawn from the participant hub.
A deletion request anonymises the participant record while retaining the financial rows required by statute, and the deletion itself is recorded in the audit log.