Merchant exam packet

This page is the public index for partner and regulator due diligence. It links to policies, public legal pages, and the merchant onboarding path PAID operates today — Stripe Connect merchant KYB, Plaid payout-bank verification, sanctions screening, and gated go-live.

Last updated: 2026-07-09  ·  Document ID: PAID-OPS-010

1. Company overview

PAID (PAI'D Payments Intelligence) is a multi-rail universal-acceptance payment orchestration platform. PAID coordinates and routes payments between buyers, merchants, and licensed sub-processors; the acceptance, holding, and settlement of funds is performed by those licensed providers, not by PAID. PAID does not custody consumer funds and does not hold money-transmission or banking licenses. Regulated activities — card acceptance, merchant identity verification, ACH settlement — are performed by licensed sub-processors (Stripe Connect, Dwolla, Circle, and others) under their own authorizations.

2. Policy documents

• Information Security Policy (PAID-POL-001) — public summary · full text (GitHub)
• AML/CFT Policy (PAID-POL-003) — full text (GitHub)
• Data governance — retention matrix (GitHub)
• Access control — PAID-POL-002 (GitHub)
• Financial crime compliance (PAID-POL-004) — control framework (GitHub)
  Money laundering, financial sanctions and fraud controls, each labelled with its current enforcement state rather than as an undifferentiated list.
• UK payment schemes — Bacs, CHAPS and Faster Payments (GitHub)
  Scheme rules, participation models and the regulatory perimeter position, for counterparties assessing UK scheme compliance.

3. Public legal surfaces

• Privacy policy — collection, lawful bases, retention, rights
• Merchant terms of service — version 2026-07-09
• Sub-processor appendix — 30-day change notice
• Security model — encryption, webhooks, ledger integrity

4. Merchant onboarding flow (payments_only)

1. Signup — business profile, mandatory 2FA, terms acceptance recorded via POST /v1/tos/accept.
2. Business profile — legal entity selection and beneficial-owner disclosure (POST /v1/platform/kyb/owners).
3. Card-rail KYB — Stripe Connect custom connected account provisioned by PAID on the merchant's behalf under the signed agency appointment (POST /v1/connect/accounts, PUT /v1/connect/accounts/:id/onboarding). Representative and beneficial-owner identity is submitted through Stripe's Persons API and identity documents through Stripe's Files API from PAID's own onboarding UI — there is no Stripe-hosted page. PAID stores verification results and last-four fragments only; full SSNs, ID numbers and documents are not retained.
4. Sanctions screening — PAID's own screening engine against the OFAC SDN and consolidated lists (additional government feeds as configured), fail-closed on every charge path and re-run before go-live. No third-party sanctions or PEP vendor is in the path.
5. Payout bank — Plaid Link for Auth + Identity + Balance; the account is tokenized to the settlement rail (Stripe bank-account token or Dwolla processor token). Account and routing numbers never enter PAID.
6. Go live — POST /v1/accounts/me/go-live when verification gate clears and onboarding state is onboarding_complete.
7. First charge — checkout gate enforces verification + live mode + provider health.

Operator runbook: AXIS_MERCHANT_GO_LIVE.md

5. KYB / CDD summary

Per AML policy §4.1, merchant admission collects:

• Legal entity name and jurisdiction (merchant-declared + sanctions/geo checks)
• Beneficial ownership ≥ 25% (declared by the merchant in PAID and synced to Stripe Persons with an explicit, merchant-made owners_provided attestation; representative KYC via Stripe verification, submitted from PAID's UI)
• Government business identifier (EIN / company number — submitted to Stripe Connect for verification)
• Sanctions screening (PAID's internal screener against OFAC and configured government lists; fail-closed). Optional fraud-risk signals from Sardine when configured — not a sanctions or PEP source.
• Payout bank verification (Plaid — merchant-side only)

Enhanced due diligence is triggered for high-risk industries, FATF grey-list jurisdictions, or PEP hits. Operator evidence upload is admin-only in production.

6. Technical controls (audit hooks)

• Immutable hash-chained ledger — GET /v1/audit/verify
• Webhook signatures — Stripe-compatible HMAC on outbound; vendor-specific inbound verification
• Tenant isolation — scoped auth middleware on every merchant resource
• CI security gates — CodeQL, govulncheck, Trivy, npm audit (documented in security policy §7)

7. Contacts

Full internal index with artifact cross-references: docs/MERCHANT_EXAM_PACKET.md