Skip to main content
POST
Create a Blockchain Payment

Authorizations

Authorization
string
header
required

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Headers

Idempotency-Key
string
required

Idempotency key

Required string length: 5 - 255

Body

application/json

Creates a payment to a fiat or cross-border creditor.

Only fiat-to-fiat transfers are currently accepted: a wallet_address debtor and the blockchain creditor rails (solana, base, ethereum) are advertised in the enums but rejected at creation.

The debtor's available balance is checked at creation: insufficient funds are normally rejected synchronously with HTTP 400 and no payment is created. When the balance service is temporarily unavailable the check is deferred to asynchronous processing, so a successful create response is not an absolute guarantee of settlement.

debtor
object
required

The source of funds for the transfer.

creditor
object
required

Common creditor fields shared by every payment rail. This is the base of the rail-specific creditor variants; integrations reference BlockchainPaymentCreditor, which selects the correct variant from payment_rail.

amounts
object
required

The transfer amounts and currency codes.

payment_purpose
object
required

The purpose of the transfer.

creditor_agent
object

Details of the receiving financial institution. Required when creditor.payment_rail is not a blockchain network (solana, base, ethereum). When creditor.payment_rail is swift, address is also required.

reference
string

An optional reference message for the transfer, passed on to the recipient on rails that carry a reference.

Formatting requirements depend on creditor.payment_rail. The reference is stored and delivered exactly as submitted — it is never shortened, stripped, or otherwise altered. A reference that does not meet its rail's requirements is rejected when the payment is created, with HTTP 422 and an invalid_parameters entry for reference.

Additional rules:

  • wire and swift references are formatted into at most 4 lines of 35 characters. Words are kept whole and wrapped at spaces; include your own line breaks (\n) to control the layout. A single word longer than 35 characters, or text that cannot fit within 4 lines, is rejected.
  • iban requires a minimum of 6 characters. If you omit the reference on an iban payment, one is generated for you and returned on the created payment object.
  • bre_b, ethereum, base, and solana do not carry a reference; supplying one is rejected.
  • Omitting the field, or sending an empty string, is allowed on every rail except iban and results in no reference being sent.
Example:

"INV2024001"

Response

Successful response

A blockchain payment object representing a fiat or cross-border payment.

id
string

The ID of the Blockchain Payment object.

Pattern: ^blockchain_payment_\w+$
Example:

"blockchain_payment_xyz123"

debtor
object

The source of funds for the transfer, with enriched entity data.

creditor
object

Common creditor fields shared by every payment rail. This is the base of the rail-specific creditor variants; integrations reference BlockchainPaymentCreditor, which selects the correct variant from payment_rail.

creditor_agent
object

Details of the receiving financial institution. Required when creditor.payment_rail is not a blockchain network (solana, base, ethereum). When creditor.payment_rail is swift, address is also required.

amounts
object

The transfer amounts, currency codes, and settlement details.

payment_purpose
object

The purpose of the transfer.

reference
string

The reference message for the transfer. For iban payments created without a reference, this is a value generated automatically at creation, of the form Payment via Lead <payment id> (the payment's public ID with underscores replaced by hyphens, e.g. Payment via Lead blockchain-payment-2x7abc...). See reference on the create request for the per-rail formatting rules.

Example:

"INV2024001"

status
enum<string>

The current status of the blockchain payment.

Available options:
created,
under_review,
awaiting_funds,
submitted,
posted,
rejected,
canceled
Example:

"created"

rejection_reason
enum<string>

Reason the transfer was rejected, as a closed machine-readable code (BlockchainPaymentStatusReasonCode). Present only when status is rejected. See that enum for the per-value terminal-vs-retryable semantics you need to build the right resubmit logic.

Available options:
payment_could_not_be_processed,
name_mismatch,
name_not_validated,
account_closed
Example:

"name_mismatch"

cancelation_reason
string

Reason the transfer was canceled. Present only if status is canceled.

Example:

"Requested by customer"

created_at
string<date-time>

ISO 8601 format timestamp representing when the blockchain payment was created.

Example:

"2024-06-27T11:22:33Z"

updated_at
string<date-time>

ISO 8601 format timestamp representing when the blockchain payment was last updated.

Example:

"2024-06-27T11:22:33Z"