Security

What we don’t claim

As of the last-updated date above, Pleezpay holds no independent certification. That means no PCI DSS, no SOC 2, no ISO 27001 and nothing else of the kind, and no sentence here should be read as claiming one.

The providers cover card processing themselves. Every connected provider that handles card payments is validated under PCI DSS in its own right, as a service provider, and that validation is what we rely on for the work each one does. Those certificates belong to the providers. We won’t present one as ours, here or anywhere else.

We are building a vault that isn’t tied to any one provider, with a cardholder data environment that will be formally assessed. It isn’t available yet and we don’t describe it as if it were. Until that assessment is done, we make no PCI DSS certification claim. When we do publish a certification, it will be current, scoped accurately and backed by evidence.

The path a card number takes

1. The shopper types it into a page of its own. The card fields are a separate document, on a separate origin, framed by the checkout. Its Content Security Policy lets exactly one script run, a single file pinned with Subresource Integrity. Inline script is blocked, and so are inline styles: on a page holding a card number, either one would be a route for lifting what the shopper types.
2. It travels once, to one place. Over TLS, bound to that one attempt, the number goes straight to the one connected provider processing the payment. Nothing else receives it. We keep the masked card plus the provider’s own reference; the card number itself isn’t kept.
3. The shopper can see who is taking the payment. The card scheme disclosures — your business’s identity, the amount and your support details — sit above the card frame, on the checkout page that holds it, in view the whole time.

Which part does what

Pleezpay sits between two things: your checkout on one side and your connected payment providers on the other. Inside, the work is split into separate jobs — hosted payment pages, card entry, talking to providers, translating their statuses into one vocabulary, sending webhooks, reconciling, and keeping the ledger — and each job runs as its own service, holding its own credentials.

What that means for your integration: a payment counts once our server confirms it, in an API response or a webhook. A shopper arriving back on your return page is not evidence that anyone paid.

Checkout and API safeguards

• In transit and in the browser. We serve everything public over TLS. Every response sends a Content Security Policy, HSTS with the preload directive, protection against clickjacking and MIME sniffing, a strict referrer policy and limits on browser permissions. Before we serve a checkout on a domain, we check that the domain is yours.
• Test data never meets live. Credentials, keys, provider adapters and workflows exist twice, once for test and once for live, with no crossover at any point. A provider that only exists for testing cannot be picked by a live route.
• A retry returns the same payment. Any request that creates a payment session must carry an idempotency key. Send it twice and the first payment comes back, not a second one.
• Webhooks you can verify. Each payment event we send is signed and timestamped, and can’t be replayed. A delivery that fails is retried with backoff, behind a circuit breaker, and we log every delivery attempt.
• Statuses checked with the provider. Any payment whose outcome is still open is reconciled with its provider on a schedule. No browser redirect ever counts as proof that a payment went through.
• Limits per caller. Each caller is rate limited on the public endpoints, the checkout and the merchant API.
• A ledger that is only ever added to. Money moves as double-entry ledger lines. Lines are appended and never edited, and the itemised reports you get are built from those lines.
• No marketing tags near payments. Marketing analytics from third parties loads on this website’s marketing pages alone, and only once a visitor consents. It never loads in the card entry document, nor on the hosted payment page.

Who can sign in, and to what

• How people sign in. The dashboard, the documentation and our internal tools all use an email address and a password, checked by Pleezpay’s own identity service. We store passwords hashed. Nobody can create an account for themselves: every account starts with an invitation.
• What each person can reach. Merchant, broker and internal users each get role-based permissions. Integration API keys are scoped, and merchants are kept apart from one another at the data access layer.
• What gets written down. We keep a durable record of sign-in attempts, privileged actions, impersonation sessions and configuration changes.
• How sessions end. Session cookies are signed and secure, they expire, and we can revoke them.

How keys are kept

• Your provider credentials are stored with envelope encryption, under a root key kept as a restricted deployment secret. Only the services that need to decrypt credentials have that secret, and a credential is opened only within the one service that speaks to its provider.
• Your Pleezpay API keys are hashed before they are stored, shown to you a single time when you create them, limited to one environment, and yours to revoke whenever you like.
• Browsers get no secrets. Client-side code carries none. We pin the card entry script as well, so if that file were ever changed, it would not load.

Where it runs

Pleezpay runs on managed cloud infrastructure. In front of it, an edge network terminates TLS, serves DNS and filters traffic. The database can’t be reached from the public internet. Every schema change is a versioned migration that has been reviewed and is applied from within the private network. Every release names the exact commit it ships, and we check it once it is out. For the vendors behind it, see Subprocessors.

Providers and vendors

We depend on vendors for infrastructure and communication, and we connect to payment providers that are independent and regulated. Security inside a provider’s own systems, and any regulated service it runs there, are that provider’s responsibility. When this website names a provider, it is telling you that we work with it, or that it is being rolled out. It does not mean the provider guarantees, endorses or certifies Pleezpay.

When something breaks

Failures show up in what our application and our operations record, and in reconciliation and configuration alerts; we use the same signals to work out the state of a payment.

In an incident, the order of work is fixed. First we contain it. Next we make sure payment records stay intact. Then we recover, and we tell the contractual contacts who are affected. How fast we notify you, the service levels and the support channels are whatever we have agreed with you in writing, a signed Data Processing Agreement included.

Tell us about a security problem

Email [email protected] and put “Security report” in the subject line. That address takes suspected vulnerabilities and security incidents alike. To help us act quickly, tell us:

• which URL or component is affected;
• how to reproduce it, step by step;
• what an attacker could do with it;
• how we can reach you safely.

While you look, leave other users’ data alone, keep the service running and run nothing destructive. Good-faith reporting that does no damage is the only testing we authorise. There is no paid bug bounty at the moment.