​
Overview

The crypto rail enables blockchain-based transfers of stablecoins across multiple chains. Unlike traditional payment rails that route through banking networks, crypto payments settle directly on-chain, offering global reach without geographic restrictions. OpenFX supports 7 blockchain networks and 4 stablecoin assets. Crypto payments on OpenFX are created through the POST /payments/crypto endpoint with a crypto_wallet payment method.
Crypto payments on OpenFX are stablecoin-only. The platform does not support volatile cryptocurrency transfers (BTC, ETH, etc.). All supported assets are fiat-pegged stablecoins designed for payments and settlement.

​
Supported chains and assets

​
Blockchain networks

ChainDescriptionTypical confirmation timeNetwork fees
ethereumEthereum mainnet2-5 minutesHigher (gas fees)
solanaSolana mainnetSecondsVery low
tronTRON mainnet1-3 minutesLow
baseBase L2 (Coinbase)SecondsVery low
polygonPolygon PoS2-5 minutesLow
inkInk L2SecondsVery low
suiSui mainnetSecondsVery low

​
Supported assets

AssetNameDescription
USDCUSD CoinUSD-pegged stablecoin by Circle. Available on all 7 chains.
USDTTether USDUSD-pegged stablecoin by Tether. Available on Ethereum, Tron, Solana, Polygon.
EURCEuro CoinEUR-pegged stablecoin by Circle. Available on Ethereum, Base, Solana.
PYUSDPayPal USDUSD-pegged stablecoin by PayPal/Paxos. Available on Ethereum, Solana.
For the lowest fees and fastest settlement, use Solana or Base chains. Ethereum mainnet has the highest network fees but the broadest ecosystem support. TRON is widely used for USDT transfers in Asia.

​
Prerequisites

Before creating a crypto payment, you need:
  1. An active customer (KYB approved) with a funded crypto account (wallet type) holding the target asset on the target chain
  2. A counterparty with a crypto_wallet payment method containing:
    • chain — The blockchain network (ethereum, solana, tron, base, polygon, ink, sui)
    • walletAddress — The destination wallet address on the specified chain

​
Creating a crypto payment

curl -X POST https://sandbox.api.openfx.com/v1/payments/crypto \
  -H "Authorization: Bearer $API_KEY" \
  -H "X-Signature: $SIGNATURE" \
  -H "X-Timestamp: $TIMESTAMP" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "sourceAccountId": "acc_01953e1a5f4b7070",
    "counterpartyId": "cpt_01953e1a5f4b7035",
    "paymentMethodId": "pm_01953e1a5f4b7360",
    "amount": {
      "asset": "USDC", "value": "10000000000", "chain": "solana"
    },
    "network": "solana",
    "reference": "Settlement payment - March 2026"
  }'

​
Request fields

FieldRequiredDescription
sourceAccountIdYesThe funded crypto account (wallet type) to debit
paymentMethodIdYesThe crypto_wallet payment method with chain and wallet address
counterpartyIdNoThe counterparty (can be inferred from payment method)
amountYesCryptoMoney object with asset, amount, and chain
networkNoTarget blockchain network. Should match the payment method chain.
travelRuleConditionalFATF Travel Rule data. Required above jurisdictional thresholds. See below.
referenceNoInternal reference for the transfer
metadataNoUp to 50 key-value pairs for internal tracking

​
Travel rule compliance

FATF Recommendation 16 (the “Travel Rule”) requires Virtual Asset Service Providers (VASPs) to exchange originator and beneficiary information for crypto transfers. The requirements vary by jurisdiction:
JurisdictionThresholdRequirement
EU / UKAll transfersFull originator and beneficiary data required for every transfer, regardless of amount
US$3,000Travel rule data required for transfers of $3,000 or more
FATF standard$1,000Travel rule data required for transfers of $1,000 or more
For EU and UK originated or received crypto transfers, travel rule data is required for all transfers regardless of amount. Omitting travel rule data when required will cause the payment to fail.

​
Creating a crypto payment with travel rule data

curl -X POST https://sandbox.api.openfx.com/v1/payments/crypto \
  -H "Authorization: Bearer $API_KEY" \
  -H "X-Signature: $SIGNATURE" \
  -H "X-Timestamp: $TIMESTAMP" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "sourceAccountId": "acc_01953e1a5f4b7070",
    "counterpartyId": "cpt_01953e1a5f4b7035",
    "paymentMethodId": "pm_01953e1a5f4b7360",
    "amount": {
      "asset": "USDC", "value": "50000000000", "chain": "ethereum"
    },
    "network": "ethereum",
    "travelRule": {
      "originator": {
        "name": "Horizon Payments Ltd",
        "accountNumber": "acc_01953e1a5f4b7070",
        "entityType": "business",
        "address": {
          "line1": "100 Financial Drive",
          "city": "San Francisco",
          "state": "CA",
          "postalCode": "94105",
          "country": "US"
        }
      },
      "beneficiary": {
        "name": "Global Trading Co",
        "accountNumber": "0x742d35Cc6634C0532925a3b844Bc9e7595f2bD68",
        "entityType": "business",
        "address": {
          "line1": "10 Finsbury Square",
          "city": "London",
          "postalCode": "EC2A 1AF",
          "country": "GB"
        }
      },
      "beneficiaryVasp": {
        "name": "Receiving Exchange Ltd",
        "lei": "5493001KJTIIGC8Y1R17",
        "jurisdiction": "GB"
      }
    },
    "reference": "Cross-border settlement Q1-2026"
  }'

​
Travel rule data structure

The travelRule object contains:
FieldDescription
originatorTravelRuleParty — The sending party. Auto-populated from the customer entity when omitted.
beneficiaryTravelRuleParty — The receiving party. Required for above-threshold transfers.
originatorVaspTravelRuleVasp — The sending VASP (OpenFX). Auto-populated.
beneficiaryVaspTravelRuleVasp — The receiving VASP. Name, LEI, and jurisdiction.
Each TravelRuleParty contains:
FieldRequiredDescription
nameYesFull legal name
accountNumberYesAccount or wallet address
addressConditionalRequired for above-threshold transfers
dateOfBirthConditionalRequired for above-threshold individual transfers (when nationalIdentification is not provided)
nationalIdentificationConditionalRequired for above-threshold transfers (when dateOfBirth is not provided)
entityTypeNoindividual or business
The originator field is auto-populated from the customer’s entity record when omitted. You only need to provide originator data if it differs from the entity on file or if specific fields are missing from the entity record.

​
Payment lifecycle

Crypto payments have an additional confirmation step compared to traditional rails: 
created -> processing -> completed
                      -> failed
The CryptoTransferStatus on the payment detail tracks the on-chain confirmation:
StatusDescription
pending_confirmationTransaction broadcast to the blockchain, waiting for confirmations
confirmedTransaction confirmed on-chain. Funds delivered.
failedTransaction failed on-chain (e.g., insufficient gas, contract error)

​
API reference