Payments
- Stripe is the system of record for every transaction. We do not store card numbers, CVVs, or full PANs in our database. Card data goes directly from the customer's browser to Stripe via Stripe Elements.
- Per-entity Stripe keys are stored in a key vault encrypted with AWS KMS. Each district, church, or ministry has its own keys; the system routes each event's revenue to the correct treasury without ever exposing one entity's keys to another.
- Webhook receivers verify Stripe signatures before processing any event, with idempotent handling so a replayed webhook cannot double-charge or double-refund.
- Refunds (full or partial) are first-class operations with full audit trail.
Waivers and PHI
Waivers and the medical information they collect are protected health information in spirit even if not always in legal definition. We treat them as such.
- Storage on AWS S3 with Object Lock in compliance mode. Once written, a waiver PDF cannot be modified or deleted before its retention date — not by a district admin, not by us, not by AWS root.
- Server-side encryption with AWS KMS on every object.
- Three-year minimum retention on signed waivers in S3 Standard, then automatic transition to Glacier Deep Archive for long-term retention.
- Separate AWS account boundaries for waiver storage versus operational backups; separate IAM users with least-privilege policies for each role.
- Presigned URLs for secure upload and download — no signed waiver PDFs are ever served by the WordPress application directly.
Minors and COPPA
- Households can register children without giving each child a separate login or email address.
- Under-13 records have admin views designed to avoid surfacing children's email addresses where they aren't needed.
- Waiver workflows put the parent or guardian on the signature line, not the child.
Audit trail
Every booking has an append-only event log: created, paid, waiver signed, checked in, checked out, refunded, cancelled. The log cannot be edited from the admin UI. If a question ever comes up about who did what when, the log answers it.
Role-based access
Permissions are composable, not all-or-nothing. A district administrator can grant a volunteer the ability to run kiosk check-in for one camp without giving them access to financial records, member data, or anything else. Today's role set includes:
- District administrator
- Event admin (per-event)
- Kiosk operator
- Waiver admin
- Payee / treasurer (per-entity)
- Member self-service
Your data is yours
- Full export at any time. Bookings, payments, waivers, members — yours, downloadable.
- GDPR personal-data exporter integrated with WordPress core.
- If you ever leave, we hand you everything and walk away. No hostage-taking.
ECFA-aligned audit posture
For district treasurers familiar with the Evangelical Council for Financial Accountability's Seven Standards of Responsible Stewardship, here is how the platform's controls map to the standards that matter most for the operational work it touches:
- Standard 3 — Financial Oversight. Every payment, registration, refund, and waiver creates a timestamped, immutable record. Stripe transaction-level detail flows directly into the platform's audit log; downloadable reports tie line items back to specific bank deposits.
- Standard 4 — Use of Resources & Compliance. Role-based access controls, append-only audit trails, automated reconciliation, and webhook-driven event records give an auditor verifiable evidence that funds were handled in line with policy. Manual reconciliation is replaced by tagged, queryable transaction records.
- Standard 7 — Stewardship of Charitable Gifts. Every donation, registration fee, and UMF allocation is tagged to its purpose at the moment of transaction. Camp registration fees are recorded as camp; NMI allocations as NMI; UMF as UMF. Representations to donors and member churches about how a gift will be used are backed by a record showing exactly that.
This is the language a CPA or audit committee will recognize. The platform doesn't grant ECFA membership — that's a separate organizational process — but it produces the kind of records ECFA-accredited stewardship practices require.
What we don't yet have (as of beta)
Honesty matters more than marketing here:
- We do not yet have a SOC 2 report. We are too small. The controls described above are designed in preparation for one.
- We do not yet have a signed BAA with a covered entity. If your use case requires HIPAA covered-entity status, talk to us — the storage layer is built for it but the legal wrapper isn't yet in place.
- Two-factor authentication is on the roadmap, not yet shipped. WordPress plugin-based 2FA is supported in the meantime.