NorthRail home

Compliance posture

Prove the flow before touching regulated money.

NorthRail stays sandbox-only until Canadian payments counsel and a regulated provider confirm the operating model, funds flow, merchant risk controls, and consumer authorization semantics.

Live rail gate

No production debits, payouts, refunds, or Shopify installs until provider and legal clearance.

1

ready

3

review

1

blocked

WorkstreamStatusOwner

Regulatory model

Treat NorthRail as a checkout software layer and provider-orchestrated payment facilitator until counsel maps whether MSB, RPAA, privacy, and consumer protection obligations apply.

Required before live
  • Written counsel memo on RPAA/payment service provider classification.
  • MSB analysis for fund handling, merchant settlement, and refund flows.
  • Provider contract language showing who performs regulated payment functions.

MVP control: Fake adapter only; no production debit, credit, settlement, or merchant onboarding credentials.

Needs partner/counsel

Founder + Canadian payments counsel

Merchant KYB and risk

Start with Canadian Shopify merchants in low-risk retail categories and require provider-backed KYB before any real payment method is enabled.

Required before live
  • Merchant identity, beneficial ownership, sanctions, and business category checks.
  • Restricted merchant category policy and manual review queue.
  • Settlement holds, velocity limits, and refund/cancellation controls by risk tier.

MVP control: Domain model includes merchant status and risk tier; demo blocks restricted behavior from live rails by design.

Needs partner/counsel

Risk operations

Consumer authorization

The checkout cannot imply card-like protections or bank authorization coverage until provider consent screens, revocation handling, and dispute semantics are known.

Required before live
  • Provider-approved authorization copy for bank login and payment confirmation.
  • Clear refund, cancellation, NSF, and failed-debit states surfaced to merchants.
  • Record retention plan for consent, authorization result, IP/device metadata, and webhook evidence.

MVP control: Hosted checkout labels itself as sandbox and emits deterministic fake authorization events only.

Blocked before live

Product + provider integration

Privacy and security

Avoid storing bank credentials. Persist only operational metadata needed for checkout, reconciliation, support, and audit.

Required before live
  • PIPEDA-ready privacy notice and data retention schedule.
  • Webhook signing, idempotency, audit logs, and secrets management.
  • Data processing terms with bank connectivity/payment providers.

MVP control: Current fixtures use fake customer emails, fake webhook URLs, fake provider IDs, and no bank tokens.

Needs partner/counsel

Engineering

Settlement and reconciliation

The MVP can safely model merchant-facing reconciliation before live funds because it is representational, auditable, and isolated from real provider accounts.

Required before live
  • Provider settlement report mapping and exception handling process.
  • Merchant payout ledger with immutable adjustment entries.
  • Support playbooks for partial refunds, failed settlements, and delayed provider files.

MVP control: Typed settlement lines and CSV exports prove the merchant workflow without creating payable balances.

MVP-ready

Product + finance ops