Security
Operational security boundaries
Kobbopay is payment infrastructure with procedural controls: verification before mutation, scoped environments, and explicit ownership between engineering and finance. This page describes practices and boundaries — not a substitute for your security program, vendor review, or legal advice.
Never share secrets with anyone
Kobbopay and legitimate vendors will never ask for your seed phrase, private keys, raw API secrets in email or chat, or remote control of your wallets. If someone does, it is a scam — stop and contact your security team.
Webhook verification boundary
The signature proves integrity and authenticity of the webhook body to your verifier. Parse JSON only after verification succeeds; reject forgeries with 401 without echoing secrets in logs.
- Delivery / transport · Merchant engineering
TLS, DNS, timeouts, and HTTP errors on your webhook endpoint. Fix ingress and consumer availability first.
- Authentication / signature · Merchant engineering
Secret mismatch, raw-body handling, or rotation drift. Fail closed; never parse untrusted payloads.
- Lifecycle mapping · Engineering + product ops
Paid vs Confirmed semantics misaligned with entitlements or UI. Update state machines and documented mapping.
- Reconciliation exception · Finance + engineering
Books diverge from authoritative payment states. Hold automated settlement until the exception queue is cleared per policy.
- Ownership boundaries. Engineering owns webhook verification, consumers, and deployment configuration. Finance owns recognition rules and period close. Product semantics define external states — your mapping is explicit and versioned.
- Escalation routing. Classify issues by signal: delivery failures, signature errors, lifecycle mapping drift, reconciliation exceptions, or treasury controls. Route with payment_id and state history — not ad-hoc wallet access.
- Reconciliation responsibility. Detection on the rail does not replace your books. Scheduled reconciliation compares authoritative API or event exports to internal orders — exceptions are reviewed, not assumed away.
- Operational review cycles. Merchant access, rail enablement, and sensitive controls follow intake and review — not anonymous self-serve production keys. Changes to scope or rails are deliberate configuration events.
- 2FA for sensitive merchant actions where enabled in your deployment.
- Signed webhooks before internal state mutation.
- API key material as secrets — server-side only, encrypted at rest in product architecture.
- Operational controls: merchant approval, selected rails, operator-mediated steps where your model requires them.
- We do not claim a specific license, regulator status, or audit outcome on this site.
- We do not claim “bank-grade” security as a marketing label.
- We do not promise universal instant payouts or guaranteed finality across all chains.
- We do not publish open-ended multi-asset inventory claims on this marketing site.
- Merchant approval — Gates production access and configuration so integrations match risk, geography, and rails you can support.
- Selected rails — Enables only agreed networks and assets — failures at creation are preferable to silent partial support.
- Confirmation depth — Separates detection from finality so finance and engineering do not share one overloaded “paid” boolean.
- Operational controls — Withdrawal and sensitive actions follow policy — discipline that reduces unbounded automated movement.
- Signed webhooks — Forces server-side verification before internal mutation — a boundary, not a convenience feature.
For security reviewers
This site does not display certifications we cannot substantiate in public. For control-level questions, start with Security practices, the webhook verification notes in /docs#webhook-verification, and Request access for review-specific questions.