The payout payload

A payout request combines the financial terms established by a quote with the businesses, destination bank account, purpose, and evidence needed to execute the payment.

The quote fixes the amounts, currencies, rate, fee, funding account, and payout corridor. The payout payload supplies everything that is specific to the payment being made.

Anatomy of a payout request

Quote and reference

quoteId selects the agreed financial terms. clientReference identifies the payment in your own system.

Sender

The business sending the funds, including its registered details, contact information, identification, and ultimate beneficial owners.

Receiver

The business receiving the funds, its relationship to the sender, and the bank account where local currency will be delivered.

Transaction

Why the payment is being made, where the funds originate, the remittance reference, and at least one supporting document.

{
  "quoteId": "978490c4-4227-4a75-9820-5f90482bb78b",
  "clientReference": "PAYOUT-2026-001",
  "transaction": {
    "purpose": "payment for imported inventory",
    "sourceOfFunds": "revenue from normal business operations",
    "reference": "INV-2026-001",
    "supportingDocuments": [
      {
        "documentType": "supplier invoice",
        "documentContentType": "application/pdf",
        "documentData": "JVBERi0xLjQKJcTl8uXrCg=="
      }
    ]
  },
  "sender": {},
  "receiver": {}
}

Explore the sender and UBOs, receiver and bank account, transaction, and supporting documents individually for their complete field requirements.

How Axiym prepares the instruction

Receive

Axiym receives the active quote reference and complete payout data.

Map fields

If a Party Data Map is supplied, Axiym translates sender and receiver field paths.

Normalize values

Axiym resolves controlled values across sender, receiver, and transaction data.

Validate

The normalized instruction is checked against baseline and corridor rules.

Prepare

Axiym returns the exact prepared payout for you to review and confirm.

Creating a payout does not move funds. The response has status PENDING_CONFIRMATION and contains normalized paymentData. Exact accepted Axiym values pass through unchanged; descriptive controlled values are returned as their final allowed values. Review that exact sender, receiver, transaction, destination, and financial summary before confirming it. Confirmation commits the prepared instruction and starts compliance review, settlement, and execution.

Choose how to supply party data

The Payment API accepts the same required party information in two ways.

	Axiym party structure	Your saved party structure
Use when	Your integration can construct Axiym's documented sender and receiver objects.	Your systems already produce stable sender and receiver objects with different names or nesting.
`partyDataMapId`	Omit it.	Include the ID of the saved sender-and-receiver map.
`sender` and `receiver`	Controlled values are normalized, then the objects are validated against Axiym's schemas.	Field paths are translated by the saved map; controlled values are then normalized and validated against the same schemas.
`transaction`	Always uses Axiym's transaction structure.	Always uses Axiym's transaction structure.
Controlled values	Exact Axiym values or descriptive text.	Exact Axiym values or descriptive text. Value normalization is not stored in the map.
Required information	Baseline and corridor requirements.	The same baseline and corridor requirements.

With a saved party data map, the request becomes:

{
  "quoteId": "978490c4-4227-4a75-9820-5f90482bb78b",
  "clientReference": "PAYOUT-2026-001",
  "partyDataMapId": "eaf72392-b8fb-4ca4-bc42-416445a6acbb",
  "transaction": {
    "purpose": "payment for imported inventory",
    "sourceOfFunds": "revenue from normal business operations",
    "supportingDocuments": [
      {
        "documentType": "supplier invoice",
        "documentContentType": "application/pdf",
        "documentData": "JVBERi0xLjQKJcTl8uXrCg=="
      }
    ]
  },
  "sender": {},
  "receiver": {}
}

A party data map changes how sender and receiver fields are named and nested. It does not make required data optional, transform transaction data, or bypass validation. Learn when to use one in Custom party data maps, or explore a sample object in the Payload Mapping Tool.

Field mapping is separate from value normalization. Normalization runs for every payout, with or without partyDataMapId.

Test the payload before creating a payout

Use the Payout Test to apply an optional Party Data Map, normalize controlled values, and validate representative sender, receiver, and transaction data against destination requirements. It uses corridor context rather than a quote and does not create a resource or move funds.

Read Test payout data for the two input modes and response behavior.

Where requirements come from

The final requirements are resolved in layers:

The OpenAPI schemas define the stable sender, receiver, transaction, and document structures.
The quote identifies the corridor and therefore its destination-specific requiredness, formats, and bank-routing rules.
Axiym normalizes controlled payment-data values to their final allowed values.
Axiym derives values that should not be supplied, such as the applicable clearing system.
The complete normalized result must pass validation before a payout can be prepared for confirmation.

Use the Country Playbook to explore destination-specific requirements. Then follow Create and confirm a payout for the complete API workflow.