Security & Trust

Enterprise grade controls, stated specifically

This page describes the controls built into the Pleezpay application and architecture as they exist today. It is not a certification report, an audit opinion, a penetration test report or a contractual security schedule. Where a control is designed for a standard rather than audited against it, we say so. Customer specific obligations are defined in signed agreements.

1. Security model

Pleezpay is the orchestration layer between a merchant checkout and connected payment providers. Hosted payment flows, card entry, provider communication, status normalization, webhook delivery, reconciliation and ledger records are separated into defined responsibilities with their own services and credentials. Merchants should treat server confirmed API or webhook states, never a browser return page, as payment evidence.

2. Card data boundary

• Isolated card entry: card details are typed into a dedicated card document served on its own origin, separate from the checkout page that frames it. That document carries a Content Security Policy whose script allowlist contains exactly one file, pinned by subresource integrity, with no inline script and no inline styles, because either would be an exfiltration path 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 orchestration platform keeps the masked form and the provider’s reference, not the card number.
• Provider validation: the connected providers that process card payments maintain their own PCI DSS validation as service providers. Pleezpay relies on that validation for the processing they perform and does not present their certificates as its own.
• Vault programme: a provider neutral vault with a formally assessed cardholder data environment is in development and is not represented as currently available. Until it is assessed, Pleezpay does not claim PCI DSS certification. See section 9.
• Scheme disclosures: merchant identity, amount and support details are shown on the parent checkout page, above the card frame, so the payer always sees who is charging them.

3. 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 permissions restrictions. Checkout domains are ownership verified before they are served.
• Environment separation: sandbox and live credentials, keys, adapters and workflows are kept distinct end to end, and sandbox only providers can never be routed in live.
• Write safety: payment session writes enforce an idempotency key, so a retried request returns the original payment rather than creating a second one.
• Webhook integrity: payment event webhooks are signed, timestamped, replay protected, retried with backoff, subject to a circuit breaker and fully logged.
• Status integrity: open payment outcomes are reconciled against provider information on a schedule; browser redirects are never treated as payment proof.
• Rate limiting: public, checkout and merchant API surfaces are rate limited per caller.
• Accounting traceability: every payment movement is represented as appended, never edited, double entry ledger lines used for itemized reporting.
• Tracker separation: third party marketing analytics runs only on this website’s marketing pages, stays consent gated there, and is never loaded on the hosted payment page or the card entry document.

4. Identity and access

• Authentication: dashboard, documentation and internal tools sign in with an email address and password through Pleezpay’s own identity service. Passwords are stored hashed. Accounts are created only by invitation; there is no public sign up.
• Authorization: role based access for merchant, broker and internal users, tenant 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 with expiry and revocation.

5. Keys and secrets

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

6. Infrastructure

Services run on managed cloud infrastructure behind an edge network that provides 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. Deployments are pinned to an exact commit and verified after release. Third party vendors involved are listed on the Subprocessors page.

7. Availability, monitoring and incidents

We use application and operational records, reconciliation alerts and configuration alerts to identify failures and investigate payment state. Incident handling prioritizes containment, integrity of payment records, recovery and communication to affected contractual contacts. Contractual notification timing, service levels and support channels apply where agreed in writing, including in a signed Data Processing Agreement.

8. 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 the security and the regulated services within its own systems. A provider name on this website indicates compatibility or rollout status, not a guarantee, an endorsement or a certification of Pleezpay by that provider.

9. Independent assurance status

As of the date above, Pleezpay does not hold a PCI DSS, SOC 2, ISO 27001 or other independent certification, and this page does not claim one. Card processing is performed by connected providers 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 supported by evidence, and we will never describe a provider’s certificate as our own.

10. 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, steps to reproduce, impact and a safe way to contact you. Do not access other users’ data, disrupt service or perform destructive testing. We do not currently publish a monetary bug bounty programme or authorize testing beyond good faith, non destructive reporting.