Security & Vulnerability Disclosure

1. Security Posture

The Service handles two sensitive things: OAuth credentials for a customer’s Stripe account, and personal data about that customer’s end-users. The controls below are organised around keeping those two out of the wrong hands.

We describe what is actually implemented. Where something is a roadmap item rather than a control in force, this page says so — Section 8 in particular.

2. Payment Card Data & PCI Scope

We never receive, transmit, or store a full card number. Card entry on the hosted card-update page happens inside Stripe Elements, an iframe served by Stripe; the card details go from the browser to Stripe directly and are exchanged for a token. Our servers see only the token and non-sensitive metadata (brand, last four digits, expiry month and year).

That architecture places the Service in PCI DSS SAQ A scope — the narrowest merchant validation category, available only where all cardholder data functions are fully outsourced to a validated third party. Stripe is a PCI DSS Level 1 Service Provider.

3D Secure / SCA challenges are handled inline by Stripe. We do not intercept or proxy the authentication flow.

3. Encryption

• In transit: TLS 1.2 or higher on every connection — browser to application, application to database, application to every sub-processor API. HSTS is enforced on the public domain.
• At rest: managed-database volume encryption, plus application-layer encryption for the two highest-value secrets — Stripe Connect access tokens and customer-configured SMTP credentials are encrypted with AES-256-GCM under a key held outside the database, so a database compromise alone does not yield usable credentials.
• Passwords: hashed with bcrypt. Plaintext passwords are never stored or logged, and cannot be recovered — only reset.
• Webhook verification: inbound Stripe webhooks are verified against the signing secret before any state change.

4. Access Control & Tenancy

• Role-based access within an account — owner, full_access, read_only — enforced server-side, not in the UI layer;
• Every data query is scoped to the authenticated account. There is no cross-tenant read path in the application;
• Session cookies are HTTP-only, Secure, SameSite-scoped, and CSRF-protected;
• The platform admin panel is a separate authentication domain with its own session, and its actions are written to an append-only audit log;
• Internal access to production data is least-privilege, logged, and revoked on role change or departure.

5. Infrastructure & Availability

• Managed PostgreSQL with automated daily backups and point-in-time recovery;
• Backups are encrypted and retained on a rolling window not exceeding 35 days;
• Restoration is tested rather than assumed;
• Scheduled jobs (retry processing, email sending, expiry scanning) are idempotent, so a re-run after failure cannot double-charge or double-send;
• Application health checks and error monitoring are in place.

Availability commitments, credits, and the definition of downtime are in the Service Level Agreement.

6. Development & Dependencies

• Dependencies are scanned for known vulnerabilities and patched promptly on advisory;
• Secrets are held in environment configuration, never committed to source control;
• Input is validated at the schema layer before it reaches business logic;
• Database access goes through a query builder that parameterises input, closing off injection by construction;
• Changes are reviewed before reaching production.

7. Incident Response

On confirming a security incident affecting customer data we:

1. Contain — revoke affected credentials and isolate the affected component;
2. Assess — determine what data, and whose, was involved;
3. Notify — affected customers within 48 hours of becoming aware, as committed in Section 10 of the DPA;
4. Remediate — fix the root cause and verify the fix;
5. Report — provide a written post-incident summary on request.

Where a breach affects Florida residents, the Florida Information Protection Act, Fla. Stat. § 501.171, requires notice within 30 days of determination, and notice to the Florida Department of Legal Affairs where 500 or more Florida residents are affected. Other states’ breach statutes and Articles 33–34 GDPR apply in parallel where relevant.

8. Certifications — Plainly Stated

Trust pages tend to imply more than they hold. To be unambiguous about what Payment Recovery System does and does not have:

Our sub-processors hold their own certifications — Stripe is PCI DSS Level 1, and our infrastructure providers publish their own audit reports. Those are their certifications, not ours, and we do not present them as ours.

9. Vulnerability Disclosure

We welcome reports from security researchers. Email security@paymentrecoverysystem.com with:

• A description of the vulnerability and its impact;
• Clear reproduction steps or a proof of concept;
• The affected URL, endpoint, or parameter;
• Your name or handle if you would like credit.

Our commitments to you:

• Acknowledgement within 2 business days;
• An initial assessment within 5 business days;
• Progress updates at least every 10 business days until resolution;
• Target remediation of 7 days for critical severity, 30 days for high, and 90 days for medium and low;
• Public credit on request, once the issue is fixed.

We do not currently operate a paid bug bounty. Please allow 90 days before public disclosure, or less by agreement where a fix ships sooner.

10. Safe Harbour

If you make a good-faith effort to comply with this policy during your research, we will:

• Consider your research authorised under the Computer Fraud and Abuse Act and Florida’s computer-crimes statutes;
• Consider it exempt from the anti-circumvention provisions of the DMCA;
• Waive any claim against you under our Terms of Service for the research activity;
• Not pursue or support civil or criminal action against you.

If legal action is initiated by a third party against you for activity conducted in accordance with this policy, we will make this authorisation known.

Safe harbour is conditional on good faith. It does not extend to accessing, modifying, or exfiltrating data that is not yours, to degrading the Service for others, or to extortion.

11. Out of Scope

Please do not perform, and we will not reward or authorise:

• Denial-of-service, volumetric, or stress testing;
• Social engineering of our staff, customers, or vendors; physical attacks;
• Automated scanning that generates significant load;
• Testing against a customer’s live Stripe account or real end-user data — use test mode;
• Accessing or modifying data belonging to anyone other than an account you control;
• Vulnerabilities in third-party services (report those to Stripe, Google, or the relevant vendor directly).

Reports of missing best-practice headers, weak TLS ciphers with no demonstrated exploit, self-XSS, missing rate limits with no security consequence, or output from an automated scanner with no proof of impact will be acknowledged but generally closed without action.

12. Contact