How Neo protects people and private data

Phone-bound authentication

flowchart TB
  WhatsApp[Verified phone identity] --> Challenge[One-time challenge]
  Challenge --> Buyer[Order-scoped buyer session]
  Challenge --> Seller[Merchant-bound seller session]
  Challenge --> Creator[Creator-bound session]
  Challenge --> Admin[Role-revalidated admin session]
  Buyer --> Ownership[Resource ownership checks]
  Seller --> Ownership
  Creator --> Ownership
  Admin --> Role[Role and step-up checks]
  Ownership --> CSRF[CSRF on state-changing forms]
  Role --> CSRF

Challenges are hashed, expiring, and one-time. Session cookies are signed and HTTP-only; production cookies are secure. Verification revalidates the expected phone, user, role, merchant, creator, or order binding.

Authorization and ownership

Buyer pages are order scoped. Seller pages resolve the owner and merchant from the server session. Creator pages resolve the creator record. Administrative pages require support, operations, or super-admin roles depending on the action. State-changing forms require a session-bound CSRF token.

Provider callbacks do not use user sessions; they require their provider signature or verification token and then pass through durable idempotent receipt.

Defence in depth

• Shared request-body and stricter upload limits.
• Database-backed rate limits for authentication and callbacks.
• Hosted payment pages; no raw card storage.
• Private object storage and protected readback.
• Encryption or masking for sensitive provider recipient references.
• Redaction for identity-number text, beta invite secrets, logs, audits, and evidence.
• PostgreSQL constraints, advisory locks, and immutable financial triggers.
• Production environment validation rejects mocks and unsafe delivery combinations.

Privacy boundary

Ordinary WhatsApp chat must not request or store BVN/NIN. Neo does not collect BVN. Seller NIN enters only through the signed, expiring seller-identity Flow; it is encrypted while the Dojah request is queued, matched on legal name and the NIN-registered phone, then purged with the submitted legal name after every terminal attempt. Live identity verification remains unavailable until the exact Dojah account and deployment target are certified.

Privacy intake creates one open audited request per canonical phone and supports controlled review transitions. A default-on terminal-state guard records redacted category outcomes and returns fulfilment_blocked instead of completed while any postcondition is missing. Automated field-level deletion/anonymization, legal holds, and provider fulfilment are not complete. Public documentation therefore describes request intake and guarded review, not completed erasure.

• src/nin-verification.ts
• src/whatsapp-flow-contracts.ts
• assets/whatsapp-flows/seller-verification.json
• src/privacy.ts
• db/migrations/069_privacy_fulfilment_guard.sql
• test/nin-verification.test.ts
• test/phase2-postgres-runtime.test.ts

Evidence and tests

• src/buyer-auth.ts
• src/seller-auth.ts
• src/creator-auth.ts
• src/admin-auth.ts
• src/rate-limit.ts
• src/uploads.ts
• src/privacy.ts
• src/env.ts
• test/security.test.ts