Trust & security
Architecture statements, not badges.
This page is written for the person who has to sign off. Everything below describes how the platform is actually built. Where we hold no certification, we claim none.
Tenant isolation
Every tenant's data lives in its own PostgreSQL schema. Isolation is enforced at the query layer on every request, not by application convention — a query cannot reach another tenant's schema by accident or by malformed input.
Schema-per-tenant
Each tenant has its own PostgreSQL schema. There is no shared table with a tenant column to filter correctly.
Enforced per request
The query layer scopes every request to its tenant. Isolation does not depend on a developer remembering a WHERE clause.
Legal hold
Legal-hold protections block destructive tenant operations, so a retention obligation cannot be deleted away.
Encryption & financial detail
Encrypted at rest with AES-256-GCM
Remittance and banking details are encrypted at rest. Keys are held in AWS Secrets Manager and injected at runtime — never in code, never in logs.
Stored numbers never leave the server
The platform does not return stored account numbers to any browser. Last-four display only, everywhere — including for vendor staff reviewing a claim.
A hard gate on payment
A claim can be approved without complete remittance details. It cannot be marked paid. The gate is enforced by the platform, not by process discipline.
Access control & audit
Layered roles
Platform super-admin, vendor admin, member and viewer, partner admin and member. Roles are scoped to the tenant and the surface.
Server-side checks
Permission checks run server-side on every route. UI affordances are never the control — hiding a button is not access control.
Immutable audit trail
Significant actions write immutable audit rows: who, what, when, and on-behalf-of where relevant.
Masquerade is audited
View-as-partner sessions are time-boxed to 30 minutes, announced by a persistent banner, recorded under the admin’s real name, and refused for identity-bound actions.
How white-label domains work
Each vendor's partner portal is served from a hostname the vendor controls. The steps are short and they are the same for every tenant.
You choose the hostname
A subdomain of your own domain, for example partners.yourbrand.com.
You point DNS at the platform
One DNS record. The hostname is registered to your tenant, and collision protection means it can never serve another.
Certificates are automatic
TLS certificates for tenant custom domains are issued and renewed automatically. TLS is in force everywhere.
Partners see only you
Your wordmark, display name and legal URLs render throughout the portal. The platform’s own name does not appear.
Platform & operations
AWS infrastructure
ECS Fargate, RDS PostgreSQL, Redis, S3 and CloudWatch alarms, with TLS everywhere including automated certificates for tenant custom domains.
Forward-only migrations
Schema migrations are forward-only and backwards-compatible, and deploys are gated on schema currency — a mismatched deploy physically cannot proceed.
Reviewed change, verified deploys
Every change is independently reviewed and every deploy is verified, with required checks in continuous integration.
Uploads are scanned
Files uploaded as collateral or terms documents pass a virus-scanning pipeline. An infected or unscanned file never becomes the current version.
Security review questions we have not answered here? Send them and we will answer specifically.
Contact usRun your partner program like a product.
Tell us how your channel works today and we'll show you the console and the portal side by side. Pricing is tailored to your program.