# Payment Data Maps

Reuse your field names and labels, identify missing data, and prepare a reusable payment map.

Product: Payment API
Guides follow API reference 0.1.0 and event reference 0.1.0.
Canonical page: https://docs.axiym.io/payment-api/integration-guide/prepare-payout-data/payment-data-maps

Smart Payload Mapping helps you connect your existing records to Axiym's payment
requirements. You can assemble payment data in a JSON structure that suits your
integration, using your own field names and labels.

The result is a **Payment Data Map**: a reusable set of rules that prepares your
data in the structure and codes Axiym expects.

## When to use a map

**Payment Data Maps are optional.**

* Use `POST /payouts` if your data already follows Axiym's field structure and codes.
* Use `POST /payouts/mapped` if you want to use your own structure or labels through
  a saved Payment Data Map.

## How the tool helps

* **Reuse your existing records.** Keep familiar field names and assemble payment
  details, parties, and documents in a structure that is practical for your system.
* **Find missing information.** Compare the data you have with Axiym's requirements
  and identify gaps before building the integration.
* **Check document ownership.** Review which person, identification, or payment each
  document supports.
* **Reuse reviewed rules.** Agree the mapping once and apply it to subsequent
  payments, even as their values and numbers of people or documents change.

AI helps propose mappings for you to review. You can inspect the resulting
payment data and correct the rules before using the map in your integration.

## Value mapping

Some fields, such as payment purpose and identification type, require a code from
an Axiym-defined set. The tool helps you translate your existing codes and labels
into those values. Several labels can lead to the same Axiym code.

Names, amounts, references, and other unrestricted values do not need this
translation. See [Controlled values](/payment-api/integration-guide/prepare-payout-data/controlled-values)
for the fields and codes involved.

## Using a map in your integration

Your integration stores the reviewed map and references it when creating payouts.
Each request still supplies the current payment data; the map holds the reusable
rules. If your structure or labels change, review and store a new map for
future requests.

Mapping helps prepare the data. You still need to supply the required information,
construct the API requests, and handle payout confirmation and tracking. Mapped
payments must meet the same baseline and corridor requirements as direct payments.

## Explore the mapper

[How it works](/payment-api/tools) explains what to prepare and walks through
mapping, review, testing, and export. Open
[Smart Payload Mapping](/payment-api/tools/payload-mapper-v2) to explore the tool.

For request formats and examples, see the API reference for
[storing a map](/payment-api/api-reference/payment-data-maps/createPaymentDataMap)
and [creating a mapped payout](/payment-api/api-reference/payouts/createMappedPayout).