# Payment details

Use your existing payment data, describe supported values in familiar terms, and understand destination requirements.

Product: Payment API
Guides follow API reference 0.1.0 and event reference 0.1.0.
Canonical page: https://docs.axiym.io/payment-api/concepts/payment-details

A payment instruction identifies the funding account, amount, sender, recipient,
and destination. Supply the purpose and supporting evidence where required for
the payment.

## The information in a payment

* **Funding account and amount:** `sourceAccountId` and exactly one of
  `sourceAmount` or `destinationAmount`.
* **Sender:** the party making the payment. This may be your organization or
  a customer you are paying on behalf of. When paying for yourself, omit
  `sender`; Axiym uses the account holder's onboarded profile.
* **Recipient:** the beneficiary receiving the payment, including the account
  where the funds should be delivered.
* **Payment fields:** source of funds (`sourceOfFunds`) and purpose, where required
  by the corridor, plus an optional reference shown to the recipient.
* **Supporting documents:** evidence supplied where applicable requirements demand it, attached to
  what it evidences: the payment itself (an invoice), a party, or an
  identification (a registry extract, a passport scan).

These details form a common payment structure, even when the information
required within each part varies by destination.

## Destination requirements

Some information is required for every payment. Additional identification,
bank-routing details, or documents may be needed for a particular destination.
The selected [corridor](/payment-api/concepts/corridors) determines which
additional requirements apply. Information that is optional for one
destination may be required for another.

## Reusable value translations

You can use your own labels for purpose, source of funds, document types, identification types,
and relationships by agreeing their translations to Axiym codes during setup.
Store the reviewed rules in a Payment Data Map and reuse them in mapped payouts.
For example, an agreed purpose rule can translate "inventory purchase" to
`GOODS_PURCHASE` each time it is supplied.

Direct requests require Axiym's exact codes. Mapped requests accept the labels
covered by your saved translations. See
[Value mapping](/payment-api/integration-guide/prepare-payout-data/payment-data-maps#value-mapping).

## Smart Payload Mapping

A reusable **Payment Data Map** connects your complete payment JSON to Axiym's
input. [Smart Payload Mapping](/payment-api/tools/payload-mapper-v2) helps you
review payment and party field paths, document ownership, and controlled-value
translations, then test the result before exporting the definition.

Documents may be nested with their records or connected from a separate list
using IDs. Field mapping defines where each value goes; value mapping defines
which Axiym code a label represents. Both sets of rules are stored in the map.
See [Payment Data Maps](/payment-api/integration-guide/prepare-payout-data/payment-data-maps)
for setup and request examples.

Once the saved field and value rules are applied, Axiym checks the payment data
against the common and destination-specific requirements. You still need to
supply the information and supporting evidence required for that payment.

## Prepare the payment data

Follow [Prepare payment data](/payment-api/integration-guide/prepare-payout-data)
for the practical steps, request structures, and mapping tools.