Security

Security gates are part of the product contract. A deployment is not production-ready merely because it can settle a test payment.

Required controls

• Prove payTo ownership during merchant registration.
• Store API key verifiers, never raw API keys.
• Store notify HMAC secrets in KMS, a secrets service, or envelope-encrypted storage.
• Configure an independent SERVER_SIGNING_KEY and publish its DID metadata.
• Use at least 32 bytes of secret pepper outside local development.
• Enforce SSRF-safe HTTPS webhook validation at registration and send time.
• Ship strict CSP, frame-ancestors 'none', no-referrer policy, and MIME sniffing protection.
• Bound and rate-limit transaction history and RPC queries.
• Redact authorization headers, payment signatures, private material, and replayable payloads from logs.

Verify the whole context

Payment validation binds payTo, amount, asset, network, chain id, resource URL, validity window, and payment identifier. Never verify only the wallet signature or only the receipt text.

Worker gates

Public Worker deployments must explicitly configure abuse protection and consistency modes. D1-backed payment claims and reconciliation outbox entries are required for atomic recovery-sensitive paths. Missing production gates must make the affected route unavailable, not silently downgrade to local memory or eventually consistent storage.

Merchant operations

Webhooks are not finality. Verify the receipt and chain state, keep credentials backend-only, support key rotation, and reconcile missed settlement events. Order mode additionally requires tenant isolation, compare-and-swap transitions, random refund intents, and cumulative refund limits.