Configure Payment Rails

Plaidly calls a specific chain/network/token combination a "rail." A checkout can only offer a rail that survives the intersection of: merchant policy ∩ product/environment restriction ∩ runtime-enabled/certified rails. If that intersection is empty, checkout creation must fail closed — before a payable session exists — rather than silently omitting the option.

Live today: discover globally enabled rails

curl https://api.plaidly.io/v1/payment_methods

[
  {
    "chain": "solana",
    "network": "mainnet",
    "token": "USDC",
    "display_name": "USDC (Solana)",
    "decimals": 6,
    "kind": "spl",
    "min_amount": 0.01
  }
]

Every entry is an exact chain + network + token identity — never a bare symbol like "USDC" on its own. Two entries can share a token value while being different rails (e.g. USDC on Solana mainnet vs. USDC on Ethereum mainnet); always key your logic off the full triple, not token alone. This list is global (platform-wide), not merchant-scoped — it answers "what can Plaidly settle at all right now," not "what can this merchant's checkout offer."

Planned: per-merchant rail policy

There is currently no endpoint to restrict which of the globally enabled rails a given merchant (or a given product) is allowed to offer — every sandbox/mainnet-eligible merchant can currently request any rail returned by GET /v1/payment_methods (subject to the sandbox/mainnet gate on the session itself). The locked design adds:

• A merchant-level policy (e.g. "only stablecoins," "exclude a specific chain for compliance reasons").
• A product/environment-level restriction layered on top of the merchant policy (a specific product might only accept a subset of the merchant's allowed rails).
• The final offer set for a checkout = merchant policy ∩ product/environment restriction ∩ globally enabled+certified rails, computed at checkout-creation time, not cached.

# Illustrative — not callable yet
curl -X PUT https://api.plaidly.io/v1/me/rail-policy \
  -H "X-API-Key: your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "allow": [
      {"chain": "solana", "network": "mainnet", "token": "USDC"},
      {"chain": "ethereum", "network": "mainnet", "token": "USDC"}
    ]
  }'

What to do today instead

Filter GET /v1/payment_methods client-side against your own allowlist before presenting options to a buyer, and pass only the rail you've selected as paymentMethod on session creation — the API does not currently enforce a merchant-level restriction for you.

Next

• Create or select a checkout