Prepare and test payout data

Payout data includes the sending business, receiving business and bank account, transaction context, and supporting evidence. Validate this data independently of a financial quote before entering the payout lifecycle.

1. Choose how party fields are submitted

Mode	Sender and receiver	Transaction
Axiym structure	Use Axiym's documented field names and nesting.	Use Axiym's documented transaction structure.
Party Data Map	Use your own sender and receiver field names and nesting with a stored `partyDataMapId`.	Continue to use Axiym's documented transaction structure.

Both modes accept descriptive strings for controlled values. Axiym normalizes those strings to allowed values for the tested or prepared payout, then applies deterministic validation.

Party Data Maps translate field paths only. They do not store sample values, translate enums, map transaction fields, or remove destination requirements.

2. Create a Party Data Map when needed

Use the Payload Mapper to paste representative sender and receiver objects, review suggested field paths, and export a portable map definition. The tool does not store the map or identify your partnership.

Store the reviewed definition through the authenticated API:

curl --request POST \
  "https://partner-api.sandbox.axiym.io/api/v1/party-data-maps" \
  --header "Authorization: Bearer $AXIYM_ACCESS_TOKEN" \
  --header "Content-Type: application/json" \
  --header "Idempotency-Key: party-map-acme-erp-v2" \
  --data @party-data-map.json

Retain the returned partyDataMapId, version, and contentHash with the integration configuration that uses it. Stored maps are immutable. When your source structure changes, review and store a new definition rather than silently changing an existing map.

3. Run Payout Test

Payout Test accepts complete representative sender, receiver, transaction, and supporting-document data. It uses destination context instead of a quote:

curl --request POST \
  "https://partner-api.sandbox.axiym.io/api/v1/payouts/tests" \
  --header "Authorization: Bearer $AXIYM_ACCESS_TOKEN" \
  --header "Content-Type: application/json" \
  --data @payout-test.json

Use POST /payouts/tests when validating data in an integration before creating a quote or payout.

The request includes:

{
  "context": {
    "sellCurrency": "USD",
    "destinationCountry": "PH",
    "buyCurrency": "PHP",
    "payoutMethod": "BANK"
  },
  "partyDataMapId": "eaf72392-b8fb-4ca4-bc42-416445a6acbb",
  "transaction": {},
  "sender": {},
  "receiver": {}
}

Omit partyDataMapId when sender and receiver already use Axiym's structure.

4. Read the result

A structurally valid test request returns 200 even when the payout data is not valid. Inspect every part of the result:

Field	Meaning
`valid`	Whether the mapped and normalized payload satisfies baseline and destination requirements.
`normalizedData`	Sender, receiver, and transaction data after mapping and value normalization.
`normalizations`	Each descriptive input changed to an allowed Axiym value.
`warnings`	Non-blocking observations, such as unused mapped source fields.
`errors`	Blocking mapping or validation failures keyed by payout-data path.

Only proceed when valid is true, every normalization is acceptable for the business transaction, and warnings have been reviewed.

What Payout Test does not cover

Payout Test creates no quote or payout and does not persist the representative payload. It does not check exchange rates, amount limits, account balances, quote expiry, or confirmation reservations. Those checks happen in the financial payout workflow.

Read Test payout data for the conceptual model and the Payout Test API reference for the complete contract.

1. Choose how party fields are submitted

2. Create a Party Data Map when needed

3. Run Payout Test

4. Read the result

What Payout Test does not cover

On this page