Skip to main content

Security and trust

In one sentence

Your provider credentials are encrypted under a key the web application cannot reach, every money-moving action needs a person with a fresh second factor, several need two people, and the record of all of it is append-only and hash-chained.

Written for CTOs, security reviewers and heads of risk.

Credentials​

You connect a provider by pasting a credential: a Stripe restricted test key, a HitPay sandbox key, or an Airwallex client id and key.

  • Validated before stored. The credential is checked with the provider first. A live-shaped key in a test connection, a Stripe secret key instead of a restricted one, a key the provider rejects, or a key without the needed permissions is refused, with the reason named, and nothing is written.
  • Encrypted with two identities. Credentials are envelope-encrypted and the keys are held in a separate key-management service. The API process that serves the dashboard holds one identity; the worker processes that talk to providers hold another. Only the worker identity can decrypt a credential. The API can store one; it cannot read one back. This split is enforced by the key service's access rules, not by application code, and it was verified by negative test.
  • Never shown. The dashboard shows an eight-character fingerprint of a credential, never the credential.
  • Rotated with overlap. Rotating a credential keeps the old one valid for 24 hours so in-flight work completes.

Who can move money​

Three layers decide whether an action happens, and all three are visible on Roles and guards:

  1. Role. Six roles from owner to viewer, each a fixed set of permissions.
  2. Step-up. Eight actions refuse unless the person verified a second factor within the last five minutes: connecting or rotating a credential, minting an API key, changing the team, publishing rules, approving a payout, releasing a payout, approving a beneficiary change, requesting the Live environment. The dashboard asks for the code inline, every time.
  3. Dual control. Publishing rules, approving a beneficiary change, approving a payout above the threshold, creating a live connection and granting live entitlement each need a second, different person. The approval is bound to the exact content reviewed, expires in 24 hours, and goes stale if anything changes.

What an API key can never do​

A key is a server's identity. It carries a subset of fourteen permissions chosen when it is minted. None of the eight step-up permissions can be granted to a key. A key cannot approve, release, publish, mint keys, manage the team or request Live, and a key that tries is told so. A key is bound to one environment and can only be revoked from that environment. A stolen key can create test payments; it cannot move money.

Signing​

Two things are signed with Ed25519 keys held only by the worker processes:

  • Outbound webhooks to your systems, so you can verify every event against a public key published at a well-known URL. There is no shared secret to store or leak.
  • Verified Commerce Envelopes and beneficiary bindings, so the record of what a payout was for, and where it was allowed to go, cannot be altered after the fact by anything with database access alone.

The audit trail​

Every action that matters is written to an append-only log in which each entry carries a hash of the previous one. Editing or removing an entry breaks the chain. Evidence attached to a case is stored with its SHA-256 hash and provenance, and is tombstoned rather than deleted; reading it is itself audited.

Test and Live never touch​

Test and Live are two sets of objects: separate credentials, separate webhook secrets, separate encryption contexts, separate audit trails, separate policies, separate API keys. There is no promote-to-live switch. Going live means creating new connections with live credentials, each dual-approved, after an entitlement that itself needs two platform administrators and evidence matched against deployed anchors. Today no workspace holds it. A deployment-wide kill switch sits above all of that; it is off.

What nobody at Pehmen can do​

  • Read your provider credentials through the dashboard or the API.
  • Approve or release a payout in your workspace without being a member with the role and a fresh second factor.
  • Change a published policy without the lifecycle: a new version, validation, replay, a second approver, a fresh second factor.
  • Quietly edit the audit trail.
  • Move money. Pehmen holds no funds at any phase and is not a merchant of record.

Platform administrators exist as a separate axis. They can read a platform screen, resolve payouts stuck in manual review, record operator attestations, and grant or revoke live entitlement under dual control. Those are not dashboard buttons, and each is audited.

Verification you can ask for​

The engineering evidence behind this page: three provider integrations verified against real sandboxes, a 133-attack adversarial test suite, a chaos suite, the hash-chained audit, worker-only Ed25519 signing, and a unit, integration and API test suite in the thousands. Formal certifications, data-residency guarantees and a written SLA are not published today; see Boundaries.