Security center
Security you can verify, not just trust.
Paysealed protects the moment money is approved. Here is exactly how it works, what we store, and what’s next.
Last updated: October 4, 2026
Approvals with passkeys
- Approvals use FIDO2 / WebAuthn passkeys created on the approver’s own phone.
- Every approval requires Face ID, fingerprint or the phone’s screen lock. Biometrics never leave the phone, and we never receive them.
- Passkeys can’t be phished. They only work on Paysealed’s own domain.
- Admins can require approvals to come from a phone, so a link opened on a shared computer shows a QR code instead.
Each approval is bound to the payment
- Before the approver confirms, Paysealed builds a statement with the request, amount, currency, payee, account digits and decision.
- A SHA-256 hash of that statement becomes the passkey challenge, so the signature covers exactly that payment.
- Challenges are single-use and expire after five minutes. A signature can’t be replayed for another request.
Proof you can check yourself
- Every decision stores the signed passkey response alongside the statement.
- You can download the proof for any request and verify it independently: the statement hash, the challenge, the domain, the user-verification flag and the signature.
- With two-person approval, each approver’s signature is stored and checked separately.
Tamper-evident audit log
- Requests, approvals, declines, invitations, phone changes and rule changes are written to an append-only log.
- Each entry includes a SHA-256 hash of the entry before it, per company. Changing or removing an entry breaks the chain.
- Writes are serialized so the chain can’t fork, and the log can be exported for auditors.
Controls you set
- Roles for admins, approvers, requesters and viewers.
- Separation of duties: the person who asks for a payment can’t approve it.
- Two-person approval for every payment or above an amount you choose.
- Reminders, backup approvers and requests that expire with a clear “do not pay”.
Data protection
- HTTPS everywhere, with HSTS. Data is encrypted at rest by our database provider.
- Slack access tokens are encrypted again with AES-256-GCM before they’re stored.
- We store only what approvals need: the last 4 digits of a bank account, never the full number. Emails checked by our add-ons aren’t stored.
- App data is stored in Sydney, Australia. Our privacy policy lists every provider and where it runs.
Application security
- Every company’s data is kept separate, and database row-level security is enabled on every table.
- Rate limits on sign-in, approvals, invitations and integrations.
- Strict security headers, including HSTS, a content security policy and frame protection.
- Slack requests are verified with Slack’s signing secret. Scheduled jobs require a secret token.
- Dependencies are monitored and updated automatically.
Compliance and enterprise
We’re clear about what’s ready today and what’s planned.
- Data processing agreement (DPA)On request
- Security questionnaire answersOn request
- Independent penetration testPlanned
- SSO with SAML / OIDCPlanned
- SCIM user provisioningPlanned
- SOC 2 Type I, then Type IIPlanned
Providers
Every provider we use, what it does and where it runs is listed in our privacy policy.
Report a vulnerability
Found a security issue? Email hello@paysealed.com. Please don’t test against other customers’ data. We reply within two business days.