Security

How the platform is built, and how to report a security problem.

Architecture in brief

• Non-custodial. Only account-level extended public keys or receiving addresses are accepted; anything that looks like a private key is rejected at the API boundary. There is no hot wallet.
• Separate trust zones. The public API, the merchant portal and the hosted checkout are distinct Workers. The portal reaches the payment core only through a private service binding with a shared secret; the public API strips those internal headers unconditionally, so a request from the internet cannot be treated as internal.
• Authentication. Merchant API keys are stored as SHA-256 hashes and scoped. Portal accounts use memory-hard scrypt (N = 2¹⁵, r = 8) password hashes with breach-list checks, TOTP or passkey second factors, short-lived step-up for sensitive changes, HttpOnly SameSite=Strict session cookies and origin checks on every mutation.
• Data protection. Payer PII, webhook secrets, RPC credentials and TOTP secrets are encrypted with AES-256-GCM using record-bound authenticated data. Blind indexes allow lookups without plaintext. Retention is enforced by a daily purge.
• Abuse controls. Per-IP, per-key and per-account rate limits backed by Durable Objects, Turnstile on account creation and sign-in, idempotency keys, 64 KB body limits, strict URL scheme validation and an HMAC-signed webhook envelope with timestamp tolerance.
• Tamper evidence. Every administrative action is appended to a hash-chained audit ledger that is verified daily and on demand.
• Transport and browser hardening. HSTS with preload, strict Content-Security-Policy (the marketing site ships no JavaScript at all), frame-ancestors 'none', no referrer leakage from checkout pages that carry capability tokens.

Responsible disclosure

We welcome reports from security researchers. Email security@skullpay.co with enough detail to reproduce the issue. We will acknowledge within two business days, keep you informed, and credit you if you wish once a fix ships. Machine-readable contact details live at /.well-known/security.txt.

Please: test only against accounts you own (staging environments are ideal), never against merchants' live stores or real payers; do not access, modify or exfiltrate data that is not yours; avoid denial-of-service testing; give us a reasonable time to fix before public disclosure.

In scope: skullpay.co, portal.skullpay.co, pay.skullpay.co, api.skullpay.co, the WordPress plugin and the SDK. Out of scope: third-party providers, social engineering, physical attacks, and findings that require a compromised device or browser.