Trust and security
What the platform does, in enough detail to check
Each section names the control, where it is enforced, and what happens when it fails. Unconfirmed facts are marked, not guessed.
Verification
Checked before a profile can be found, and again at renewal
A practitioner cannot appear in search until a person on the trust and safety team has checked their documents and approved them.
- 01The practitioner creates an account and completes a profile. At this point it is not searchable.
- 02They upload their professional registration and professional indemnity insurance, each with an issuer, a reference and an expiry date.
- 03A member of the trust and safety team reviews each document in the verification queue and approves or declines it with a recorded note. Every decision is written to an append-only audit trail with who made it and when.
- 04The team approves the practitioner. An approved profile enters search once it has a service to book, and the practitioner can hide it themselves.
- 05Ninety days before a credential expires, the practitioner and the team both see it in a countdown. When it expires, it comes off the public profile automatically until a renewal is approved.
- Registers checked against
- To be confirmed
- Registers a credential can be on, by country
- Australia AHPRA, PACFA, ACA, AASW
- New Zealand NZPB, PBANZ, NZAC, SWRB
- United States State board, NBCC, NPI
- Canada College, CRPO, CCPA
- United Kingdom HCPC, BACP, UKCP, BABCP
- Ireland CORU, PSI, IACP
- Singapore SAC, SRP
- India RCI, NMC
- Identity check
- Not part of the verified badge. The application records an identity document (its type, issuer, expiry and number, the number encrypted and shown to the reviewer as its last four characters), but no copy of the document is collected and it is not checked against whoever issued it. Separately, Stripe verifies a practitioner’s identity before it pays them; that is a condition of being paid, not of the badge.
- What a client sees
- A verified badge on the profile that opens to list each check, when it passed and when it renews, with a link back to this section.
Bookings
A slot is held by the database, not by good intentions
Two bookings for one practitioner cannot overlap: a database constraint refuses them, whatever the code path.
- Overlap prevention
- A PostgreSQL exclusion constraint on each practitioner’s booked time ranges. A second booking that overlaps an existing one is refused at write, and the client is told the time has gone rather than shown a false confirmation.
- Timezones
- Times are stored as UTC instants and shown in the reader’s timezone, with the zone printed beside them. Practitioners set their hours in their own zone.
- Cancellation
- Each practitioner sets a cancellation window in hours. It is shown on the profile and again before confirming. Cancelling before the window refunds in full, automatically; inside it, a confirmed session’s fee is kept.
- Notifications
- When you book, the practitioner is notified through a database function that takes no recipient: it can only notify the other party to a booking the caller is already in.
Payments
Card details go to Stripe and never reach our servers
The platform receives confirmation that a payment succeeded, never the card number.
- Card processing
- Stripe. Card data is entered into Stripe’s own fields and does not pass through Wellbeing4me™.
- Where the money sits
- A client’s payment is held by the platform. The platform’s fee is the only part treated as revenue; the rest is recorded as money owed to the practitioner, and the ledger must reconcile to zero before any payout is approved.
- Paying practitioners
- Practitioners are paid out after sessions, to a payout account that has been verified. A payout to an unverified account is refused. Every approval is audited.
- Booking fee for clients
- None. You pay the fee on the profile.
- PCI DSS scope
- To be confirmed
Your information
Who can read what, and what stops anyone else
Row-level security in the database enforces access, so an application bug cannot widen what a practitioner sees.
- Practitioner access
- A practitioner can read the bookings, messages and details of their own clients only. Every table holding personal data has row-level security enabled, and a request for another practitioner’s record returns not found, not the record.
- Encryption at rest
- Messages between you and a practitioner are encrypted in the database with AES-256-GCM, using a key held outside the database. A copy of the database is not a copy of the conversations.
- Encryption in transit
- TLS on every connection. The site sends HSTS, so browsers refuse a plain-HTTP connection.
- Uploaded documents
- To be confirmed
- Retention and deletion
- Anything a person created is soft-deleted, so records with a legal retention duty survive a deletion request. You can close your account at any time; records we are required to keep are kept for that period, then removed. Closing replaces your name on bookings, receipts and reviews with "Former client" or "Former practitioner".
- Retention periods
- To be confirmed
- Data residency
- To be confirmed
- Your requests
- Access, correction and deletion requests are handled as tracked cases with an append-only note trail. Start one at [email protected].
How the platform is built
Controls that fail the build when they are missing
Security rules run in continuous integration; a change that removes one cannot merge.
- Passwords
- Hashed with argon2id. Never logged, never returned by the API.
- Sign-in
- Rate limited by IP address and by account, with bot protection verified on the server.
- Sessions
- HttpOnly, Secure cookies on the web. Tokens are never stored in browser storage.
- Input
- Every request is validated against a whitelist of fields; a request with an unexpected field is rejected.
- Queries
- Parameterised only. The unsafe raw-query functions fail the linter.
- Secrets
- Read from the environment at start-up; a secret committed to the repository fails the build.
- Dependencies
- Scanned for known vulnerabilities on every push; a high-severity advisory blocks the merge.
- Headers
- Content Security Policy with no third-party scripts, frame-ancestors none, HSTS, nosniff and a strict referrer policy on every page.
- Independent testing
- To be confirmed
Subprocessors
Who else handles data, and for what
Only the services the platform is known to use. The rest are marked until verified.
- Stripe
- Card payments and practitioner payouts.
- Cloudflare
- Hosting and delivery of the public website, and bot protection on sign-in forms.
- Database hosting
- To be confirmed
- Email delivery
- To be confirmed
- File storage
- To be confirmed
Compliance posture
Mapped to SOC 2 and ISO 27001, not certified against them
Each technical control is mapped to the SOC 2 criteria and ISO/IEC 27001:2022 Annex A, with the automated check that fails without it. Evidence for a future audit, not a certification.
- Certifications held
- To be confirmed
- Privacy law
- To be confirmed
- Data processing agreement
- To be confirmed
Reporting a concern
Tell a person, and say which kind of concern it is
Concerns about a practitioner, a session or someone’s safety are handled first. Mark the subject line “Safety”.
- Safety or conduct
- [email protected], subject “Safety”
- Security vulnerability
- To be confirmed
- Breach notification
- To be confirmed
Free to search and book.
Find a practitioner