Skip to main content
POST
Register a credit instruction (no processing)

Authorizations

Authorization
string
header
required

Assume OAuth 2.0 client credentials issued by the bank, presented as a bearer token. Meridian can adapt to the bank's preferred authentication scheme during onboarding.

Body

application/json

A credit (payout) instruction from Meridian to the bank.

transactionId
string
required

Meridian's unique identifier for this credit and the idempotency key. Stable across retries and across the validate/commit/status lifecycle of one transaction.

Maximum string length: 64
Example:

"mrdn-9f2c1e4a-71bd-4c5e-a2f3-8d6b0c9e1a27"

amount
object
required
recipient
object
required

The customer being credited at the home bank.

sender
object

Originator of the funds (KYC data). Included on commit for compliance screening. Field-level availability is confirmed during onboarding, and some corridors add further compliance fields (for example the sender's relationship to the recipient, or source of income) that Meridian agrees with the bank at that time.

purpose
string

Human-readable purpose / remittance information for the transfer.

Maximum string length: 140
Example:

"Wallet withdrawal payout"

metadata
object

Additional key/value context supplied by Meridian (e.g. a customer-facing reference to print on statements). Banks should persist and echo these where their core allows, but must not require fields beyond those agreed at onboarding.

Response

Instruction registered (or already registered with an identical payload).

Acknowledgement that the instruction was registered. No recipient checks have run and no funds have moved, so the only status this endpoint reports is RECEIVED.

transactionId
string
required

Echo of Meridian's transaction identifier.

status
enum<string>
required

Always RECEIVED. The instruction is stored and nothing else has happened yet.

Available options:
RECEIVED