Data and hosting
Pehmen stores decisions, references and evidence; it never stores card numbers, bank account numbers or provider credentials in readable form; and its data services are isolated from public integration endpoints.
Written for CTOs, DPOs and anyone filling in a vendor questionnaire.
What is stored
| Kind of record | What it holds | What it never holds |
|---|---|---|
| Orders and payments | Your references, amounts in minor units, currency, category, channel, status history, every decision and route trace | Card numbers, CVVs, the customer's payment details (those stay with the provider) |
| Sellers and beneficiaries | Your seller reference, verification level, attestations, a masked account, a tenant-keyed fingerprint, the provider's name-match result | The bank account number |
| Connections | Provider, display name, an encrypted credential, an eight-character fingerprint, validation and health state | The credential in readable form; the API cannot decrypt it |
| Policies | Every version, its definition, who validated, replayed, approved and published it | Nothing is deleted; superseded versions are retired |
| Decisions | The verdict, score, reason codes, the policy version, and the feature snapshot the rules saw | Free text |
| Cases | Evidence bytes with SHA-256 and provenance, actions and what they replaced, appeals | Deleted evidence; it is tombstoned |
| Audit log | Every consequential action, hash-chained, append-only | Edits |
| Webhooks | Outbound deliveries, inbound provider events (metadata; encrypted payloads in object storage) | Your endpoint's responses beyond the status code |
Identifiers are yours: your order reference, your payment reference, your seller reference. Pehmen adds its own ids alongside and never asks you to replace yours.
Where it runs
The integration architecture page shows the public boundaries. The dashboard and API sit in front of decision services, provider adapters and isolated data services. Durable records, encrypted webhook payloads and case evidence are not exposed as public integration endpoints. Key-management capabilities are separated by workload so the processes that accept API requests do not also hold every decryption and signing capability.
Public traffic enters through authenticated HTTPS interfaces. The database and evidence store are not directly reachable through those interfaces.
Environments and blast radius
Test and Live data never share objects: separate credentials, encryption contexts, webhook secrets, policies, keys and audit trails. Each workspace's records are scoped to that workspace; an object that belongs to another workspace answers as if it does not exist. Provider credentials are encrypted under a per-workspace master key.
Pehmen isolates its durable records from unrelated application data because it stores encrypted credentials, webhook secrets and money records.
Backups
Durable records are backed up on a schedule using a format that preserves database permissions. Restore is tested against real backups, including the least-privilege separation between schema changes and application access.
On the way in
Provider webhooks arrive at the API on a path that names the provider and your connection. The signature on the raw request body is the authentication; an unsigned or mis-signed body is refused with an empty response, then the event is stored and queued for the worker. Requests from your servers carry your API key, your workspace id and the environment. Every response carries a request id minted by the server, never adopted from the request.
On the way out
Outbound webhooks to your systems are signed with a platform Ed25519 key. Your endpoint must be HTTPS on port 443 and publicly routable; private addresses are refused at save time and re-checked at every delivery attempt. Redirects are never followed. Only your status code is kept.
Notifications to sellers (the cooling-off notices) go by email through the platform's own mail sender.
Retention, residency and certifications
Records are kept; evidence is tombstoned rather than deleted; the audit log is never edited. A formal retention schedule, a data-residency commitment and third-party certifications are not published today. Until they are, the honest answer to a questionnaire is not yet published, and the Boundaries page says so in the product's own words.