Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.getopenrails.com/llms.txt

Use this file to discover all available pages before exploring further.

Open Rails is designed as software, routing, and observability around payment processors. The platform should not pool customer funds, custody merchant balances, or promise fiat settlement from an Open Rails-controlled account.

​
Control plane

Open Rails owns the merchant dashboard, checkout session creation, route selection, provider metadata, webhook normalization, delivery logs, and agent-readable schemas.

​
Data plane

Approved provider accounts own the regulated payment activity. Depending on the route, this can include card authorization, buyer KYC, wallet transfer, stablecoin settlement, off-ramp, refunds, and provider-specific compliance holds.

​
Merchant setup

Merchants configure:
  • Store identity and checkout branding.
  • Settlement addresses by chain and token.
  • Sandbox and production webhook endpoints.
  • Provider credentials once production access is approved.
  • Route policy, such as best successful quote with fail-closed fallback.

​
Buyer flow

The buyer sees a branded checkout and a simple payment choice. Open Rails can show the route and provider estimate, but the payment activity is completed by the selected provider or the buyer’s wallet.

​
Compliance posture

Production activation should require provider account connection and merchant review. Open Rails should not bypass provider KYC or KYB controls. If a provider offers low-limit, no-KYC flows, Open Rails should expose those only as the provider documents them and should preserve the provider’s limits, geography, sanctions checks, and risk controls.