Security & custody
Gladpaid reads. It never moves money, and it is built so that it cannot.
Written for the owner, the bookkeeper, and whoever reviews vendors for them.
Rule
We never hold your funds
Payments go from your customer straight to a wallet you control. Gladpaid observes them. There is no escrow, no routing, and no moment where your money sits with us. We could not move it if we wanted to.
Rule
We never ask for a key
We watch public addresses, nothing more. Paste a recovery phrase, private key or keystore file into any field or upload, and it is refused in the browser and again on the server, never stored, scrubbed from logs, analytics and error reports, and you are told why.
Rule
No token, ever
Gladpaid does not issue a token, points that convert, or any other tradable instrument.
Ledger permissions
- QuickBooks Online: the accounting permission only, used to read invoices and post payments and journals. QuickBooks offers no read-only accounting permission, so we enforce an allow-list in code of the records we may create, and every write is audited.
- Xero: granular accounting permissions for contacts, invoices, payments, manual journals, attachments and settings. Never the payment-services or bank-feed permissions.
- Disconnect at any time, from the app or from QuickBooks or Xero. We never change your lock dates or delete anything we did not create.
Encryption
- TLS for every connection, and encrypted storage at rest.
- Ledger tokens and ledger organisation ids are sealed field by field with AES-256-GCM. Each value has its own data key, wrapped by a versioned master key in Google Cloud KMS. Two-factor secrets are encrypted separately by our authentication library.
- The application reaches KMS with a short-lived workload identity, so no long-lived cloud credential exists to leak. Keys rotate without downtime.
- Each ciphertext is bound to its business and connection, so a value copied to another record will not decrypt.
Isolation between businesses
- Every table holding customer data is protected by PostgreSQL row-level security, checked by the database on every query rather than by application code alone. A query that forgets its scope returns nothing.
- Firm staff see only the client businesses they are assigned to.
Sign-in
- Two-factor authentication is required for every user, not offered as an option: an authenticator app, or a passkey (Face ID, Touch ID, a phone's screen lock or a security key), which a fake site can't phish.
- Sign in with email, a passkey, Intuit or Xero. Resetting your password or removing a passkey ends every other session.
- Sessions can be reviewed and ended from your account's security page, which also lists your recent sign-ins and security changes.
- Rate limits on sign-in and on every public endpoint.
An audit trail that cannot be quietly edited
- Every match, correction, policy change, posting, reversal, sign-off, reopen, sign-in, member change and export is written to an append-only log.
- Each entry carries the hash of the one before it, and the database refuses updates and deletes, so a changed history is detectable rather than plausible.
- A business's trail is kept for at least 7 years and exportable by the business. Sign-ins, failed sign-ins and changes to how you sign in go to a separate security log built the same way, kept for one year.
Data handling
- From the ledger we mirror only what matching needs. No bank feeds, payroll or employee data.
- Matching is rule-based and per business. Nothing is pooled across customers, and no model is trained on your data.
- Uploaded documents are treated as hostile: type-checked, size-limited, parsed in isolation and scanned for key material. Xero data is never sent to a language model without your business's consent.
- Every inbound webhook is signature-verified, with a replay window and de-duplication.
- Logs are scrubbed and kept for no longer than 30 days.
Operations
- Controls follow the FTC Safeguards Rule as a baseline: a written information security programme, risk assessment, access reviews, monitoring, an incident response plan, vendor oversight and an annual review.
- An automated check in our build refuses any wallet-signing library or payment permission, and every permission we request is checked at runtime against a fixed allow-list.
- The providers we rely on are listed, with purpose and location, on the subprocessors page.
Documents for your reviewer
Report a security issue
Write to support@gladpaid.com with “Security” in the subject. We acknowledge reports promptly and will not pursue good-faith research that avoids customer data and service disruption. Security questionnaires go to the same address.