Security

Last updated: July 28, 2026

Effective: July 28, 2026.

1. Our Security Posture

PD Cash is a payment orchestration platform. It routes transactions to licensed channel partners and does not custody merchant funds. This page describes the technical and organisational measures we apply to the parts of the system we control, and it says plainly where responsibility sits with a licensed partner instead. It is a description of our practices, not a warranty, and not a certification.

2. Data Minimisation

The most reliable control is not holding the data at all. On the PD Cash Platform:

• We do not store full payment card numbers (PANs)
• We do not store card verification values (CVV/CVC) or any sensitive authentication data
• We do not store bank account credentials or online banking logins
• We do not hold cryptocurrency private keys or seed phrases for merchant or customer wallets
• We do not request identity documents, government identifiers, or financial credentials through public forms
• Payment provider API keys supplied under BYOK are stored encrypted and are never displayed back to anyone in full

3. Card Data & PCI Scope

PD Cash does not offer direct credit or debit card acquiring, and is not a card acquirer or a merchant of record. Cardholder data is not entered into, transmitted by, or stored on PD Cash systems.

Where a card-funded method is reached through a licensed partner or wallet, the cardholder data environment sits with that partner. The substantive PCI DSS obligations for storing, processing, and transmitting cardholder data therefore sit with the licensed partners and their acquirers, not with PD Cash.

Our own scope position is that of an entity that fully outsources payment acceptance — the profile addressed by SAQ A, which is available where an entity does not store, process, or transmit cardholder data on its own systems and outsources all such functions to PCI DSS validated third parties. This is a statement of scope, not a claim of certification. PD Cash does not represent itself as PCI DSS certified and does not hold itself out as having a validated Attestation of Compliance. Merchants who need compliance evidence for card transactions should obtain it from the licensed partner that handles those transactions.

4. Encryption

• TLS 1.2 or higher on all traffic to the website, dashboard, and API, with weak ciphers and older protocol versions disabled
• HTTP Strict Transport Security (HSTS) enforced across pd.cash and its subdomains
• AES-256 encryption for data at rest, including database storage and backups
• Secrets and payment provider API keys held in a dedicated encrypted store, with per-tenant key separation and support for merchant-supplied keys (BYOK)
• Passwords stored using a salted, memory-hard hashing function; never stored or logged in plaintext, and not recoverable by us
• Outbound webhooks signed so the receiving system can verify origin and payload integrity

5. Access Control

• Least privilege: staff access is limited to what the role requires, reviewed when a role changes, and revoked on departure
• Multi-factor authentication required for all administrative access
• Administrative actions written to an append-only audit trail recording actor, action, target, and timestamp
• Separation of duties between development, deployment, and production support
• Production data is not copied into development or test environments
• Access to an individual merchant's records is logged, and a summary is available to that merchant on request

6. Merchant Account Security

• Two-factor authentication and one-time codes are available on merchant accounts and required for sensitive actions
• Sessions are bound to the originating browser and platform, with automatic expiry and forced re-authentication
• Rate limiting on sign-in, one-time code entry, password reset, and API endpoints
• Email notification on password change, email change, two-factor changes, withdrawal method changes, and sign-in from a new device
• API keys are scoped to the permissions they need, rotatable by the merchant at any time, and revocable immediately

7. Fraud & Velocity Monitoring

We run automated fraud, velocity, and risk rules across transactions and account activity — unusual volume or ticket size, rapid repeated attempts, geographic anomalies, structuring patterns, and known bad indicators. A rule may decline a transaction, hold a withdrawal, or restrict an account.

Material automated decisions are subject to human review. Where an automated rule declines, holds, or restricts your account, you may request review through the contact form, and a person who was not part of the automated decision will look at it. Section 10 of the Privacy Policy sets out your rights in relation to automated decision-making.

8. Infrastructure & Resilience

• A web application firewall in front of public endpoints, with rules tuned for the Platform
• Denial-of-service mitigation at the network and CDN layer
• Separation of production, staging, and development environments, with no shared credentials between them
• Encrypted backups on a 90-day rolling cycle, with restores tested on a scheduled basis rather than assumed to work
• Automated dependency and vulnerability scanning, with prioritised patching
• Continuous monitoring and alerting on errors, latency, authentication failures, and anomalous traffic
• A documented rollback path so a bad release can be reverted quickly

9. Incident Response

We maintain an incident response process covering detection, triage, containment, eradication, recovery, and post-incident review. Every incident is assigned a severity that determines escalation, who is involved, and how we communicate.

Where an incident involves personal data, the notification timelines and the contents of the notice are set out in Section 8 (Breach Notification) of our Privacy Policy. An incident originating at a licensed channel partner or payment provider is that entity's to assess and report under its own obligations; we pass on what we are told, cooperate with their process, and tell affected merchants what we know.

10. Responsible Disclosure

If you believe you have found a security vulnerability affecting PD Cash, please tell us before you tell anyone else.

• Report it through the contact form at pd.cash/contact#contact-form using the subject "Security disclosure"
• Include the affected URL or endpoint, a clear description of the issue and its impact, and the steps needed to reproduce it
• We acknowledge your report within 2 business days
• We provide an initial assessment within 10 business days
• We ask that you allow up to 90 days before any public disclosure, and we will agree timing with you if a fix legitimately takes longer

10.1 In scope

• pd.cash and its subdomains
• The merchant dashboard
• The public API
• The official PD Cash WordPress plugin

10.2 Out of scope

• Denial-of-service testing and volumetric or stress testing of any kind
• Social engineering of our staff, our merchants, or our partners
• Physical attacks against offices, people, or hardware
• Missing rate limits reported without a demonstrated impact
• Findings that only affect unsupported or outdated browsers
• Raw automated scanner output with no verified, demonstrated impact
• Issues in third-party services we do not control — report those to the operator concerned

10.3 Rules of engagement

• Do not access, modify, download, or retain data belonging to anyone else — use your own test account
• Stop as soon as you have confirmed the issue, and report it rather than exploring further
• Do not degrade, interrupt, or otherwise affect service for other users
• Do not use a finding as leverage for payment or any other demand

We do not operate a paid bug bounty and do not offer a monetary reward. We will credit researchers who report in good faith and follow these rules, where they wish to be named, and we will not pursue action against research conducted within them.

11. Availability

We do not offer a contractual service level agreement or an uptime guarantee. We aim for continuous availability and monitor for outages, but the Platform depends on hosting, network, and licensed channel-partner services that we do not control. An outage or degradation at a channel partner, a payment network, or a blockchain is outside our control and is not a PD Cash outage. Section 13 of the Terms of Service and the Disclaimer set out the applicable limitation of liability.

12. Merchant Responsibilities

Security of your account depends on you as well as on us. You should:

• Enable two-factor authentication on your PD Cash account and on the email address that controls it
• Keep API keys server-side — never embed them in browser code, mobile apps, or public repositories
• Verify the signature on every webhook you receive before acting on it, and reject unsigned or mismatched payloads
• Restrict dashboard access to the people who need it, and remove access promptly when someone leaves
• Use unique, strong passwords, held in a password manager rather than reused across services
• Report a suspected compromise immediately through the contact form so we can rotate keys and lock the account

13. Contact Us

For security questions, or to report a vulnerability using the subject "Security disclosure", contact us:

• Contact form: pd.cash/contact#contact-form
• Website: pd.cash