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-11-01  ·  Document ID: PAID-OPS-010

1. Company overview

PAID (PAI'D Payments Intelligence) is a payment orchestration platform. A merchant connects a Stripe account through PAID, and card payments are charged on that merchant's own Stripe account; Stripe accepts the card, holds the funds and pays them out to the merchant's bank under its own licences, not PAID. PAID does not custody consumer funds and does not hold money-transmission or banking licenses. Card payments through Stripe Connect are the only payment method PAID offers today. Card acceptance and merchant identity verification are performed by Stripe under its own authorizations.

2. Policy documents

The public editions of PAID's policies say what the code does today, including what is not built yet:

• Information Security Policy (PAID-POL-001) — Information security (public edition) · security model
• AML/CFT Policy (PAID-POL-003) — Anti-money-laundering summary (public summary)
• Data governance — Data governance (public edition, with the retention rules the code enforces)
• Access control (PAID-POL-002) — Access control (public edition)

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 confirms the account and its holder. PAID keeps the Plaid access token, encrypted, and the last four digits of the account; the Plaid link path stores no full account or routing number.
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.

5. KYB / CDD summary

Merchant admission collects (see the anti-money-laundering summary):

• 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 not enforced by the software: there is no coded list of high-risk industries or countries that forces extra checks before a merchant goes live. 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; Stripe's signature checked on every inbound Stripe event
• Tenant isolation — scoped auth middleware on every merchant resource
• Release gate — every change is built and tested before it can be pushed; the dependency scanners (govulncheck, Trivy, npm audit) run in an extended gate that is not yet required on every release, and there is no hosted CI

7. Contacts