Test payout data

The Payout Test checks a complete representative payload before you use it in a live payout workflow. It is useful for testing Axiym-shaped data, custom party structures, controlled-value normalization, and destination requirements.

What the test checks

Party structure

Validate sender and receiver objects directly, or apply a stored Party Data Map first.

Controlled values

Normalize representative sender, receiver, transaction, and document values to their allowed Axiym results.

Destination requirements

Apply the baseline and destination-specific data rules selected by the test context.

Actionable results

Inspect normalized data, every changed controlled value, warnings, and field-level errors.

With or without a Party Data Map

Input mode	How sender and receiver are handled
Without `partyDataMapId`	Use Axiym's documented party field structure.
With `partyDataMapId`	Use the partner structures associated with the stored map. Axiym maps their field paths first.

In both modes, transaction uses Axiym's documented field structure. Controlled values across all three objects are normalized before validation.

No quote is required

The test uses a non-financial context to select the applicable requirements:

{
  "context": {
    "sellCurrency": "USD",
    "destinationCountry": "PH",
    "buyCurrency": "PHP",
    "payoutMethod": "BANK"
  },
  "transaction": {
    "purpose": "monthly software development",
    "sourceOfFunds": "income from normal business operations",
    "supportingDocuments": [
      {
        "documentType": "supplier invoice",
        "documentContentType": "application/pdf",
        "documentData": "JVBERi0xLjQKJcTl8uXrCg=="
      }
    ]
  },
  "sender": {},
  "receiver": {}
}

The origin country is derived from the partner's onboarded location.

What the test does not do

The Payout Test does not:

create or consume a quote;
create a payout or clientReference;
check an exchange rate, amount limit, or available balance;
reserve or move funds; or
persist the submitted representative payload.

A structurally valid request returns 200 even when the result has valid: false. Read normalizations, warnings, and errors before deciding that the payload is ready.

Use Test a payout with the same complete sender, receiver, and transaction structures that the partnership intends to submit when creating the payment.