Security

How the system is divided

Pleezpay is the orchestration layer between a merchant’s checkout and its connected payment providers. Hosted payment flows, card entry, provider communication, status normalisation, webhook delivery, reconciliation and ledger records each have a defined job, with their own services and credentials. Merchants should treat a state confirmed by our server, through the API or a webhook, as payment evidence — never a browser return page.

Where card data goes

• Isolated card entry. Shoppers type card details into a dedicated card document served from its own origin, separate from the checkout page that frames it. That document has a Content Security Policy whose script allowlist holds exactly one file, pinned by subresource integrity, with no inline script and no inline styles — either would be a way to steal data on a page that holds a card number.
• One destination. Card data leaves that document over TLS, for a single bound attempt, and reaches only the connected payment provider that processes the payment. The platform keeps the masked card and the provider’s reference, not the card number.
• Provider validation. The connected providers that process card payments hold their own PCI DSS validation as service providers. We rely on that validation for the processing they do, and we don’t present their certificates as ours.
• Vault programme. A provider-neutral vault with a formally assessed cardholder data environment is in development. We don’t present it as available today. Until it is assessed, we don’t claim PCI DSS certification. See “Independent assurance” below.
• Card scheme disclosures. The merchant’s identity, the amount and support details appear on the parent checkout page, above the card frame, so the payer always sees who is charging them.

Application controls

• Transport and browser controls. Public traffic is served over TLS. Responses carry HSTS with preload, a Content Security Policy, clickjacking protection, MIME-sniffing protection, a restrictive referrer policy and browser permission restrictions. We verify ownership of a checkout domain before we serve it.
• Test and live kept apart. Test and live credentials, keys, adapters and workflows are separate end to end, and a provider that exists only for testing can never be routed in live.
• Safe retries. Writes that create a payment session require an idempotency key, so a retried request returns the original payment instead of creating a second one.
• Webhook integrity. Payment event webhooks are signed, timestamped and protected against replay. Failed deliveries retry with backoff behind a circuit breaker, and every delivery is logged.
• Status integrity. Open payment outcomes are reconciled against the provider on a schedule. A browser redirect is never treated as proof of payment.
• Rate limits. The public, checkout and merchant API surfaces are rate limited per caller.
• Traceable accounting. Every movement of money is recorded as double-entry ledger lines that are appended, never edited, and itemised reports are built from them.
• Trackers kept out of payments. Third-party marketing analytics runs only on this website’s marketing pages, only with consent, and never on the hosted payment page or the card entry document.

Identity and access

• Signing in. The dashboard, documentation and internal tools use an email address and password through Pleezpay’s own identity service. Passwords are stored hashed. Accounts are created by invitation only; there is no public sign-up.
• Permissions. Role-based access for merchant, broker and internal users, isolation between merchants at the data access layer, and scoped API keys for merchant integrations.
• Audit. Privileged actions, configuration changes, sign-in attempts and impersonation sessions are recorded durably.
• Sessions. Signed, secure session cookies that expire and can be revoked.

Keys and secrets

• Provider credentials are envelope-encrypted at rest under a root key held as a restricted deployment secret. That secret is set only on the services that decrypt them, and credentials are decrypted only inside the service that talks to the provider.
• Merchant API keys are stored hashed, shown once when created, scoped to one environment and revocable at any time.
• Secrets never reach browsers. No secret is embedded in client-side code, and the card entry script is pinned, so a changed file cannot load.

Infrastructure

Our services run on managed cloud infrastructure behind an edge network that handles TLS termination, DNS and traffic filtering. The database is not exposed to the public internet. Schema changes are applied from inside the private network, from a reviewed, versioned migration. Each deployment is pinned to an exact commit and verified after release. The Subprocessors page lists the third-party vendors involved.

Availability, monitoring and incidents

We use application and operational records, reconciliation alerts and configuration alerts to spot failures and investigate payment state. When something goes wrong, we work in this order: contain it, protect the integrity of payment records, recover, and tell the affected contractual contacts. Notification timing, service levels and support channels apply where they are agreed in writing, including in a signed Data Processing Agreement.

Vendors and connected providers

The platform relies on infrastructure and communication vendors, and connects to independent, regulated payment providers. Each connected provider is responsible for security and for the regulated services inside its own systems. A provider’s name on this website shows compatibility or rollout status. It is not a guarantee, an endorsement, or a certification of Pleezpay by that provider.

Independent assurance

As of the date above, Pleezpay does not hold PCI DSS, SOC 2, ISO 27001 or any other independent certification, and this page does not claim one. Connected providers process card payments under their own PCI DSS validation. A formally assessed cardholder data environment is part of the vault programme in development. We will publish a certification claim only when it is current, accurately scoped and backed by evidence, and we will never describe a provider’s certificate as our own.

Report a security concern

Send suspected vulnerabilities or security incidents to [email protected] with “Security report” in the subject. Include the affected URL or component, the steps to reproduce, the impact and a safe way to reach you. Don’t access other users’ data, disrupt the service or run destructive tests. We don’t currently run a paid bug bounty programme, and we don’t authorise testing beyond good-faith, non-destructive reporting.