Card data never touches your server or ours.
How card data is handled, what is encrypted, who can see what, and how to report a vulnerability.
The card boundary.
Everything else on this page follows from one rule: card numbers are entered into hosted fields and go straight to the vault.
- Hosted fields
- The card number, expiry and security code are typed into iframes served by the vault provider. Your page’s code and ours see only a token, the last four digits and the brand.
- Vault
- Cards are tokenized in a PCI DSS Level 1 vault. Saved cards, subscriptions and invoices all charge the token, never a stored card number.
- Your PCI scope
- Because card data never passes through your page’s code, your own PCI paperwork stays at the shortest questionnaire, SAQ A.
- No card numbers in logs
- Logs, error tracking and support tools never receive a card number. Automated checks fail a deployment that would print one.
Data handling.
- In transit
- TLS 1.2 or newer on every connection, including webhooks to your server.
- At rest
- Tax IDs, government ID numbers, dates of birth and bank details are encrypted with AES-256-GCM, with keys held separately from the data.
- Access
- Staff access is role-based and logged. Support can see what is needed to answer a ticket, not card data or ID documents.
- Audit log
- Every admin action, pricing change, hold, payout and tier change is written to an append-only log whose entries are hash-chained, so a change after the fact is detectable.
- Retention
- Transaction and verification records are kept for as long as card-network rules and the law require, then deleted.
- Backups
- Encrypted, taken daily, and restored on a schedule to prove they work.
Fraud and account security.
- Before the charge
- Every order is scored against velocity rules, device and IP signals, and a list of cards and emails seen in prior disputes. High-risk orders are challenged or declined before the card is charged.
- After the charge
- Card-network alerts can refund a disputed charge before it becomes a chargeback, within a limit the business sets.
- Sign-in
- Magic links or passwords with two-factor authentication for every dashboard user. Admin accounts require a second factor.
- Webhooks
- Signed with a per-account secret you can rotate. Outbound requests are blocked from reaching private networks.
Reporting a vulnerability.
If you find a security problem on this site or the platform, tell us before you tell anyone else and give us a reasonable time to fix it. We will acknowledge within two business days, keep you informed, and credit you if you want. Email contact@trustfac.com with “security” in the subject.
Please don’t access other people’s data, run denial-of-service tests, or use social engineering. Testing against your own test-mode account is fine.
Questions about security?
Ask before you apply. We’ll walk through the card boundary, the vault and what review looks at.