Your congregation's data — card numbers, bank accounts, personal details — never sits where it shouldn't. Freely Give runs on the same payment, banking, and database infrastructure trusted by Lyft, Shopify, and the IRS. Here's exactly where your data lives, who can touch it, and what we built to keep it safe.
Every gift travels through four systems. Card and bank entry happen on infrastructure run by Stripe — never ours. We see the result, not the credentials.
Card numbers go into a Stripe-served iframe. Bank logins go into Stripe's hosted Financial Connections UI. Neither ever touches our servers — we receive a single-use token.
Our Edge Function asks Stripe to charge the token. The actual charge happens on Stripe's PCI DSS Level 1 infrastructure — we just make an API call and wait.
Stripe notifies us when the gift succeeds. The notification is cryptographically signed — we verify the signature before writing anything. Forged or replayed events are rejected.
The gift lives in Postgres under your church's tenant id. Every read is gated by row-level security policies at the database itself — a church can only see its own data.
We deliberately built Freely Give to be a smaller target. The systems that hold card numbers, link bank accounts, and move funds are the world leaders in payment security — not us. Every claim below is verifiable on their own pages.
Stripe processes every card and ACH transaction on Freely Give. They handle the actual money movement, fraud screening, and card storage. We only make API calls — we never see or store a card number.
Stripe Financial Connections handles every bank-account link for ACH giving. Donors log into their bank inside Stripe's hosted flow — we never see their username, password, or one-time codes. It identifies and tokenizes the account so Stripe can debit it.
Donors enter card numbers into Stripe Payment Element — a hosted iframe served from Stripe's PCI-certified infrastructure. We receive a payment token. Our database has never seen a card number, and never will.
Members link their bank inside Stripe's hosted Financial Connections flow — we don't see their username, password, or MFA codes. The resulting bank token is stored server-side only and never sent to the browser.
Stripe is certified PCI DSS Level 1 (the highest service-provider tier, audited annually). Because card data never reaches us, Freely Give itself falls under PCI scope SAQ A — the lightest tier. That's the entire point: less surface to leak, less to misconfigure.
Stripe notifies us when something changes — a gift completes, a round-up posts, a bank reconnects. Every payload is verified against Stripe's signing secret (HMAC) before our database is touched. Replay attacks rejected on a 300-second freshness window.
Donor identities, transactions, fund balances — all gated by PostgreSQL row-level security policies at the database itself. A church admin can only query rows that belong to their church. Even if app code ever tried to leak across churches, the database would refuse.
Every payment, round-up, and ACH transfer is keyed on Stripe's unique id (PaymentIntent, Financial Connections transaction). If a webhook is redelivered — common in any payment system — the duplicate is detected and skipped. No double-charges. No double-recordings.
SECURITY DEFINER RPCs are the only RLS-bypassing write path — limited to gift recording and tenant provisioning.If you've discovered a vulnerability in Freely Give, we want to hear about it directly — before anyone else does. We respond within one business day and acknowledge every reporter who follows responsible disclosure.
help@freelygive.app