Security

A shul database is a list of who belongs to your community

Names, homes, phone numbers, what people can afford to give, and when they lost someone. That is not ordinary business data, and it is not treated as such here.

The short version

ðŸ’ģ

No card numbers

We could not leak a card number if we tried — we never receive one.

🔐

Two-factor for admins

Mandatory, enforced by the application regardless of any other setting.

ðŸ§ą

Congregations sealed off

Every request is authorised against one specific congregation.

📋

Everything signed

Who did it, when, in what role — kept even for cancelled records.

Getting in

Identity is not ours to invent

Logins are handled by a managed identity service, not by password code we wrote. Passwords are never stored by us in any form.

  • Signed tokens, verified on every single request
  • Forced password change on first login
  • Temporary invitation credentials expire in a day

Two-factor, actually enforced

Administrators and pledgers must enrol an authenticator app before they can reach anything. This is enforced in the application, so it cannot be switched off in a settings panel by mistake.

  • Standard time-based codes — any authenticator app
  • Labelled with your congregation's name, not a generic one

Checked twice, on purpose

Every request is verified at the gateway before it reaches our code, and verified again inside the application. The gateway rejects anything unauthenticated outright.

  • A mistake in one layer is caught by the other
  • An unauthenticated request never reaches your data at all

Least privilege by role

Roles are checked on the server for every operation, never assumed from what the screen offered.

  • A gabbai recording pledges cannot open anyone's financial record
  • The contact list a non-administrator receives carries no personal details
  • Members can only edit a specific whitelist of their own fields
Isolation

Your congregation cannot see another, and none can see yours

The platform serves several congregations. Keeping them apart is not a filter applied at the end of a query — it is the first thing checked and the last thing enforced.

How it is enforced

  • Which congregation a request is for is authorised on the server, against a membership record — never taken on trust from the browser
  • A request for a congregation you have no grant to is refused outright, not silently filtered to nothing
  • Access requires an explicit grant. Existing as a contact somewhere is not access
  • Every stored record is keyed by congregation, so a query cannot accidentally cross the line

Where one login serves several

A bookkeeper who works for two shuls, or a family who belong to one and give to another, can hold one login for both. What is shared is the login and nothing else.

  • Separate roles per congregation — an administrator here can be an ordinary member there
  • Separate records, separate history, separate balances
  • Switching congregations tears the session down and reloads from scratch
Payments & PCI

The safest way to hold a card number is not to

Card details are captured in fields that belong to the payment processor, inside the payer's own browser, and exchanged for a token there. The card number never travels to our servers, is never written to our database, and never appears in a log.

  • We store the last four digits and the brand. That is all, and it is what PCI permits
  • Saved cards are tokens, not numbers — useless to anyone who obtained them
  • Processor keys are held in encrypted secret storage, never in code or configuration files
  • Refunds go back to the original card through the processor; we never touch the number to do it

Charging safely

  • Amounts are always recalculated on the server. Whatever the browser says a ticket or sponsorship costs is ignored — the price comes from your settings.
  • Every charge carries an idempotency key, and one is mandatory. A double-click, a flaky connection or a retried request cannot take the money twice.
  • Slots are reserved before the card is charged, with a write that fails if someone else got there first — and a declined card releases the hold.
  • Card payments are locked from casual editing. To undo one you refund or re-allocate it, which both leave a trail.

At the edge, before anything reaches the application

A public donate page is a target. It is treated like one.

🌍

Geographic restriction

Sensitive public payment endpoints only accept traffic from the country your congregation is in. Card-testing farms abroad never reach the form.

ðŸĪ–

Silent bot challenge

Public payment submissions must carry a proof-of-browser token. Real visitors never see a puzzle; automated traffic cannot produce one.

⏱ïļ

Rate limiting

Per-address limits on both the portal and the public API, plus request throttling at the gateway, so no single source can flood or grind through it.

ðŸŠĪ

Honeypot fields

Public forms carry a field no human ever sees. Anything that fills it in is rejected before a card is charged.

🔒

Nothing publicly readable

Website files are served through a CDN from storage that is not reachable from the internet directly. Certificates renew themselves.

🚊

A deliberately tiny public surface

The anonymous public API can read only whitelisted content and write only payments. It has no code that can return a member record.

Guest payment links

Letting someone pay without an account, safely

The convenience members like most is also the easiest thing to get dangerously wrong. A link that shows a balance has to prove who it is for.

  • Cryptographically signed. Changing a single character invalidates it — it cannot be edited to point at another member
  • Expires after 30 days
  • Confirmed against their phone number before any balance is displayed, with attempts rate-limited
  • Shows only what is needed to pay — never the full record
Audit

You can always answer "who did this?"

In a volunteer-run office with changing staff, being able to reconstruct what happened matters more than in most businesses.

  • Every record carries who created it, who last changed it, and in what role
  • Cancellations record who cancelled, when, and why
  • Nothing is hard-deleted. Contacts, pledges and transactions are cancelled or hidden, never destroyed
  • Payments split across pledges stay linked, so a payment can always be traced to what it settled
Continuity

If something goes wrong

Point-in-time recovery

Your data can be restored to any moment in the recent past, not just to last night's backup.

A copy in another region

Everything is mirrored to a second geographic region, so a regional outage is not an existential event.

Backed up before we touch it

Any bulk operation — an import, a correction, a migration — is dry-run first and backed up before a single row is written.

Encrypted at rest and in transit, throughout

Everything stored is encrypted on disk. Everything moving is encrypted in transit. Secrets — processor keys, signing keys — live in managed encrypted storage with their own access controls, never in code, never in a configuration file, never in the repository.

What we do not claim

Security pages that claim everything are worth nothing. Here is where the honest edges are.

An administrator can see everything
By design. The office needs full records to do its job, so a compromised administrator account is the most serious realistic risk. That is exactly why two-factor is mandatory for administrators and cannot be turned off, and why every action they take is attributed to them. Field-level masking is available if your board wants it, but it is not on by default.
Receipts contain an amount and the last four digits
Emailed receipts include the amount paid and the last four digits of the card, protected in transit but readable in the recipient's mailbox. Last-four is permitted under PCI, so we consider this an accepted trade-off for a useful receipt — not a defect. Members can opt out of transaction emails entirely.
We are not formally certified
We do not hold a SOC 2 report or an ISO certificate, and we will not imply otherwise. What we can give you is a written description of the posture, an honest answer to any question your board asks, and a walkthrough with whoever advises you on this. Card data is handled by a PCI-compliant processor, which is the part that matters most.
Member two-factor is optional
Required for administrators and pledgers; available but not forced for ordinary members, because mandating it would lock out the people least likely to complete it and push them back onto the office. If your congregation wants it required for everyone, that is a setting we can turn on for you.

Reviewing this for a board or a security-minded congregant? Ask us anything — we would rather answer the hard question now than after you have signed.

Bring your toughest question

We will happily get on a call with whoever in your community worries about this properly.