Last reviewed: 2026-10-30

Information security at PAI'D

This is the public edition of our information security policy. It says what is in place today and what is not, in plain terms. If something here stops being true, we change this page.

What PAI'D is, and what it is not

PAI'D is software that sits between a merchant and Stripe. A merchant connects a Stripe account through PAI'D, and card payments are charged on that merchant's own Stripe account. Stripe accepts the card, holds the money and pays it out to the merchant's bank. PAI'D holds no money-transmitter licence, and our card route is built so that PAI'D never holds, pools or moves a customer's money.

That shapes what we have to protect. We do not keep card numbers or customer funds. We do keep merchant account details, sign-in credentials, records of payments that Stripe reports back to us, and our own audit log.

Who runs it

One person operates PAI'D today. That means there is no separation of duties: the same person writes code, releases it and operates the service. We say this up front because most security frameworks assume at least two people, and we do not meet that yet.

Card data

Card details are typed into Stripe's own payment fields, which send them straight to Stripe. Card numbers never reach our servers. We keep only what Stripe returns about a payment, such as the card brand and last four digits.

Encryption

In transit. The service answers over HTTPS only and sends a Strict-Transport-Security header with a one-year lifetime. In production, the service refuses to start unless its database connection requires TLS, and unless its cache connection uses TLS or a password.
Stored credentials. Payment-provider credentials and bank-link tokens are encrypted by the application with AES-256-GCM before they are stored. Production refuses to start without the key this needs.
Not yet encrypted by the application. Other stored fields, including business tax identifiers, are not encrypted at the application layer today. They are protected by access to the database itself, not by field encryption.

Secrets and configuration

Keys and credentials are never kept in the code. On start-up in production, the service checks its own configuration and refuses to run when a required secret is missing or a safety setting is off. These checks cover database and cache encryption, the encryption key, second-factor sign-in for merchants, webhook signing secrets for each connected provider, and the sanctions list feed.

Webhooks

From Stripe. Every incoming Stripe event is checked against its signature, and events older than five minutes are rejected. Production will not start if a connected provider has no webhook secret.
To merchants. Events we send to merchants are signed with HMAC-SHA256 over a timestamp and the body, so a merchant can verify that they came from us. We refuse to deliver to private or internal network addresses.

Audit log

Security and payment events are written to an append-only log. Each entry includes the SHA-256 hash of the entry before it, so any later edit breaks the chain and shows up. The database itself refuses to update, delete or truncate the financial event log.

One limit: writing to the audit log is best effort. If a write fails, the request still completes, and the failure is logged and counted, not blocked.

Changes to the software

Every change must pass our release gate before it can be pushed. The gate builds the service and runs the test suites and our own code checks. Dependency vulnerability scanners (for Go modules, the container image and npm packages) are part of an extended gate, but they are not yet required on every release. We do not use hosted CI today.

Not in place yet

No external audit or certification (for example SOC 2). We rely on Stripe's own certifications for card data.
No second person, so there is no independent review of changes or operator actions.
No regular, documented test of restoring the database from backup.
No encryption at the application layer for business tax identifiers and other personal fields beyond credentials and bank-link tokens.

The list of companies that process data for us is on our sub-processors page. How we handle and keep data is in our Data Governance summary, and how people and systems get access is in our Access Control summary.

Security questions or a suspected vulnerability: security@trustfabric.ai