Claude Pay

Security at Claude Pay

Claude Pay is built on a different security premise to most payment processors. Money never sits in our accounts. Every payment moves directly from the buyer's wallet, card, or bank into yours. That single architectural choice removes the most attractive target an attacker could go after — a hot wallet or pooled merchant float — and shapes every other security control on this page.

We treat security as a product feature, not a compliance checkbox. The sections below explain what we do, in concrete terms, so you can verify it yourself.

Non-custodial by design

Crypto payments land directly in your wallet address. Card and bank payments settle directly to your processor account (Razorpay, Stripe, YooKassa, Wise, bKash, etc.). Claude Pay holds the merchant's API keys for the routing decision and reads the on-chain or provider state to mark invoices paid — we never custody funds, even briefly.

Why it matters: if Claude Pay ever suffered a total infrastructure compromise, the attacker still couldn't move a single rupee, satoshi, or dollar of your customer payments. The worst-case blast radius is bounded by what your own processor's API key allows on its own.

Account security

  • Mandatory TOTP two-factor authentication for every account — admins, merchants, and staff users. Login is a two-step challenge: password first, then a six-digit TOTP code from your authenticator app (Google Authenticator, Aegis, 1Password, Authy). There is no "remember this device" bypass.
  • Argon2id password hashing with per-user salts and modern memory-hard parameters. Plain passwords are never written to disk or logs at any layer.
  • Per-account login lockout triggers before password verification — failed-login bursts against any single email are refused for a cooldown window, even if the attacker rotates IPs.
  • Geographic anomaly detection on every successful login. A login from a country, ASN, or device fingerprint we haven't seen before pings the account owner over Telegram with full request context (IP, UA, time) before the session is trusted.
  • Token rotation on 2FA confirmation: the access token issued during sign-up is invalidated and replaced the moment 2FA is enrolled, so a stolen pre-2FA token cannot survive the upgrade.
  • httpOnly session cookies (Secure, SameSite=Strict). Tokens are invisible to JavaScript — even a hypothetical XSS bug in our frontend cannot exfiltrate the session.
  • Active session management: every active token is visible in the merchant dashboard with IP, user agent, and last-used timestamp, and revocable with one click.

Network and edge

  • TLS 1.3 enforced on the API, dashboard, and hosted checkout. HSTS preload + automatic HTTP→HTTPS upgrade. No mixed content tolerated.
  • Cloudflare WAF and DDoS mitigation in front of every public endpoint. Layer-3/4 attacks are absorbed at the edge before they reach our origin.
  • Rate limiting at multiple tiers: a global 300-requests-per-minute ceiling per IP, tighter limits (5–10 per minute) on auth, password-reset, 2FA verification, and webhook-ingest endpoints. Distinct buckets prevent one noisy endpoint from starving another.
  • DNS-rebinding defence on every outbound webhook delivery. We re-resolve the destination hostname on every attempt and refuse to send if any A/AAAA record points to a private, loopback, link-local, or cloud-metadata IP range — even if the host was public-only at registration time.

Application security

  • Encrypted gateway credentials at rest: API keys, webhook secrets, Gmail app passwords and any other provider credential are stored with Laravel's authenticated-encryption cast (AES-256-CBC + HMAC). Database backups carry ciphertext, not secrets.
  • Strict request validation on every API surface, with per-route schemas. Untrusted input never reaches an eval, shell_exec, raw SQL, or unsafe deserialiser.
  • Parameterised queries everywhere. The ORM (Eloquent) and query builder are used for all database access — SQL injection is not in our threat surface.
  • CSRF protection via SameSite=Strict cookies plus dedicated CSRF token checks on state-changing endpoints originating from the dashboard.
  • Content Security Policy on the dashboard and checkout, disallowing inline scripts and restricting external origins to the small whitelist we actually call.
  • Input scanners ahead of the application stack detect and log common attack patterns (SQLi probes, path traversal, RFI). Repeat offenders are throttled and surfaced in our security log.

Payment integrity

  • Database-level uniqueness on (merchant_id, network, transaction_id) for every confirmed payment. The same on-chain transaction or provider order ID cannot credit the same merchant twice, even if both the webhook and a backup scanner race to confirm it.
  • Amount-equality enforcement: confirmation requires the incoming amount to exactly equal the invoice amount at six decimal places. A buyer who underpays by a cent does not auto-confirm; the merchant decides whether to credit manually.
  • Unique-amount matching (optional, per-merchant): turns the cents portion of every invoice into a low-entropy disambiguator so two same-price invoices can never collide on incoming-payment matching.
  • Slot-locking for crypto rails: a public deposit address is held against a single open invoice during its lifetime. Concurrent invoices on the same asset are queued or routed to alternate addresses — no chance of crediting the wrong invoice when two customers pay the same address by coincidence.
  • Independent verification on the destination side: our Dhru and Magento callbacks re-fetch the authoritative state from our API before crediting an invoice, so a spoofed webhook POST cannot credit a buyer's order even if the attacker had the merchant's IP.

Webhook delivery

  • HMAC-SHA256 signing on every webhook body, with the timestamp folded into the signed input. Verify the X-Claude-Pay-Signature and X-Claude-Pay-Timestamp headers — payloads more than five minutes old should be rejected as stale.
  • Per-webhook signing secrets, generated server-side at creation and shown to the merchant exactly once.
  • Bounded retries with exponential backoff: four attempts over ~30 minutes, with permanent failure logged for merchant follow-up.
  • No retry on non-retryable client responses (4xx that signal "stop trying"): we don't hammer a 410'd endpoint.
  • Provider-side IP allowlisting on inbound webhooks: YooKassa, bKash, Razorpay and other supported gateways have their published source-IP ranges enforced, and YooKassa specifically gets a daily auto-refresh from the official documentation page.

Cryptocurrency-rail specifics

  • You hold the keys. Merchants paste their own receiving addresses (BEP-20, TRC-20, Binance Pay ID). Claude Pay never holds a private key or sees a seed phrase.
  • Address ownership protection: cross-merchant address reuse is blocked at write time, so one merchant cannot accidentally — or deliberately — claim another merchant's deposit address and start credits routing to themselves.
  • Two-track confirmation: a fast direct-network scanner (BSCScan / TronScan for on-chain, Binance Pay API for off-chain) plus an internal-deposit catcher that recognises Binance-to-Binance transfers that never touch a public block explorer. Both write through the same uniqueness constraint, so either path is safe in isolation.
  • Replay protection at the deposit-address level: once a transaction ID has credited an invoice for a merchant, no other invoice on that network can ever credit the same ID.

Manual peer-to-peer rails (bKash, Wise)

The manual rails are designed with the explicit assumption that the upstream provider has no merchant API a merchant-tier account could call.

  • bKash Personal: confirmation comes from the merchant's own Android phone forwarding the bKash "received" SMS via a per-merchant signed channel. Anti-spoofing layers include strict sender-ID filtering (bKash exact, no case bypass), per-merchant TrxID uniqueness, and a configurable SMSC fingerprint allowlist that distinguishes real Bangladesh-telco SMSes from grey-market spoofed deliveries.
  • Wise Personal: confirmation pulls the matching [email protected] notification from the merchant's Gmail over IMAP, but only on-demand (when a customer submits a Transfer Number on the checkout page) and only from that exact sender for the last seven days. The merchant's Gmail app password lives encrypted at rest and is never echoed back through any API or sent to the customer's browser.

Operational visibility

  • Append-only audit log records every privileged action: login, logout, gateway create/edit/disable, refund, merchant settings change, admin override, beta grant. Each entry pins the actor, IP, user agent, and request context.
  • Append-only security log for the events you actually need under incident response: blocked auth attempts, rate-limit hits, SSRF refusals, signature failures, suspicious input. Available to the merchant and the admin for the merchant's own scope.
  • Telegram-bridged alerts for the events that need an eyeball within minutes — new logins from unfamiliar geography, repeated failed 2FA attempts, large or anomalous payments, webhook destinations going dark.
  • Edge-triggered alerts (with hysteresis) so a phone hovering at 19% battery does not page the merchant every five minutes — alerts fire on the threshold crossing, reset above the safe band.

Data protection and privacy

  • Minimum-necessary collection: we keep what we need to run the rail and answer disputes. We do not sell, syndicate, or licence merchant or customer data to anyone.
  • Strict scope on third-party reads: when we read a merchant's Gmail (Wise rail), the IMAP search is hard-coded to the exact [email protected] sender for a seven-day window with a twenty-message cap. The protocol itself prevents us from seeing any other email in the inbox.
  • Encryption at rest for everything sensitive: gateway credentials, webhook signing secrets, Gmail app passwords, 2FA secrets, recovery codes.
  • PII minimisation on logs: we redact full card PANs, bank account numbers, and TOTP secrets from every log we emit; only the last four digits and a fingerprint survive.

Reporting a vulnerability

We respect responsible disclosure. If you've found a security issue, please email [email protected] with reproduction steps. Please do not file public issues, post to social media, or disclose to third parties before we've had a chance to investigate and ship a fix.

We aim to respond within two business days and to publish a fix within fourteen days for critical issues. We will credit researchers who report in good faith on our security page once the fix has shipped.

What's coming

This page reflects what we run today. We refresh it as we ship — every section above is implemented, not aspirational. Recent additions include SMSC-fingerprint anti-spoofing for bKash, scope-locked Gmail IMAP for Wise, and daily IP-allowlist refresh for YooKassa. Subscribe to our changelog or status page if you want to follow along.