# Terminology Definitions for payment concepts, commercial terms, and the API names used in this documentation. 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/terminology ## Payments and parties | Term | Meaning | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Payment | A transfer of funds from a funding account to a beneficiary. Its details are returned in the common payment response document. | | Payment instruction | The funding account, exactly one fixed amount (`sourceAmount` or `destinationAmount`), recipient and destination, plus sender details where applicable. Purpose and supporting evidence depend on applicable requirements; reference is optional. | | Payout request | A complete payment instruction submitted for pricing and validation before confirmation. | | Payout | An outgoing payment created through the payout endpoints and tracked through validation, approval, settlement, and execution. | | 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 / beneficiary | The party receiving the payment. These terms refer to the same party in this documentation. | | Destination | The account where the beneficiary receives the funds, together with the information needed to deliver the payment. | ## Accounts and corridors | Term | Meaning | | --------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | Axiym account | An account that holds a balance in one currency and is connected to a payment rail. | | Funding account | The Axiym account selected to fund a payment. | | Payment rail | The network or system through which funds move, such as a banking network or blockchain network. | | Corridor | A combination of funding currency, destination country, and destination currency, with its own availability, limits, and requirements. | | Clearing system | A system used to route and process bank payments. The destination determines which bank-routing information is required. | ## Pricing and amounts The API uses `source` for the funding side and `destination` for the receiving side of a payment: `sourceAccount`, `sourceAmount`, `sourceCurrency` versus `destination`, `destinationAmount`, `destinationCurrency`. In the concepts pages, the two amounts are described as the amount to send and the amount to receive. | Term | Meaning | | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | Commercial terms | Time-limited pricing returned when a payout is created: `sourceAmount`, `fee`, `rate`, `destinationAmount`, and `termsExpireAt`. | | Funding currency | The currency held in the selected Axiym account and used to pay for the payment. | | Destination currency | The currency to be delivered to the beneficiary. It need not be the destination country's local currency. | | Amount to send (`sourceAmount`) | The total debited from the funding account, in the funding currency. It includes the fee. | | Amount to receive (`destinationAmount`) | The amount to be delivered to the beneficiary in the destination currency. | | Exchange rate | The rate used to calculate the payment amount in one currency from the amount in the other. | | Fee | The charge for the payment, deducted from `sourceAmount` before conversion and delivery. Returned with the commercial terms. | | Fixed amount | The side you supply on creation: exactly one of `sourceAmount` or `destinationAmount`. Axiym calculates the other from the exchange rate and fee. | ## Processing and reconciliation | Term | Meaning | | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | Reservation | Funds set aside when you authorize a payment for processing. They are unavailable for other payments until debited at settlement or released. | | Approval | The decision that a payment may proceed after compliance and transaction-control review. Passing data validation is not payment approval. | | Settlement | The debit of the reserved payment amount and fee from the funding account after approval. It does not confirm delivery to the beneficiary. | | Execution | Carrying out the approved payment for delivery to the beneficiary. | | Reconciliation | Matching the payment's records and outcome with the resulting movements in the funding account statement. | ## Payment data | Term | Meaning | | ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Payment fields | The payment's `sourceOfFunds`, `purpose`, `reference`, and `supportingDocuments`, supplied and returned at the top level of the payout. | | Supporting document | Evidence attached to the payment (`supportingDocuments[]`), a party (`documents[]`), or an identification (`identification.documents[]`). Requests include the file content as base64; responses return document metadata without file content. Corridor rules decide which documents are required. | | UBO (ultimate beneficial owner) | A natural person who ultimately owns or controls a business. | | Source of funds | Origin of the funds used for this payment, such as business income or a loan. Supplied as the top-level `sourceOfFunds` and required where the corridor asks for it, including when `sender` is omitted; distinct from the payment's `purpose`. | | Payment Data Map | Reusable rules for sender or recipient field paths and reviewed translations from partner labels to Axiym codes. Used through the mapped payout endpoint. | | Smart Payload Mapping | The tool for creating, reviewing, and exporting a Payment Data Map containing sender fields, recipient fields, value translations, or any combination. | | Controlled value | A value drawn from an Axiym-defined set of terms, such as a payment purpose or document type. | | Value mapping | Reviewed translations from partner labels to Axiym codes, stored in a Payment Data Map and applied by exact match on the mapped endpoint. | | Validation | Checking that payment data meets the required structure, formats, and common and destination-specific requirements. Passing data validation is not payment approval. | | Prepared payment data | The validated payment instruction after any saved field and value rules are applied, available for review before processing. | See [Payment details](/payment-api/concepts/payment-details) for the concepts and [Prepare payment data](/payment-api/integration-guide/prepare-payout-data) for field structures, controlled values, and preparation guidance. ## Integration terms and identifiers | Term | Meaning | | ------------------------------- | ------------------------------------------------------------------------------------------------------------- | | Partner | The organization integrating with Axiym. This documentation generally addresses that organization as **you**. | | Partner context | The accounts and resources accessible through your integration's credentials. | | `accountId` / `sourceAccountId` | Identifier of an Axiym account; `sourceAccountId` selects the funding account on a payout. | | `paymentId` | Identifier used to retrieve, track, and reconcile a payout. | | `externalReference` | Your unique business reference for a payout. | | `paymentDataMapId` | Identifier of a stored Payment Data Map. | | Idempotency key | A request header that lets you retry the same operation without creating a duplicate. | | Request ID | A tracing identifier sent in `X-Request-Id` and echoed by Axiym. | | Event | A notification about a payout, account movement or status change, or a requested subscription test. | | Webhook subscription | Registration of the HTTPS endpoint that receives events from Axiym. | | Sandbox | A test environment with credentials, resources, and balances separate from production. | ## Formats | Term | Meaning | | ---------------------- | ----------------------------------------------------------------- | | ISO 4217 | The standard for currency codes such as `USD` and `PHP`. | | ISO 3166-1 alpha-2 | The standard for two-letter country codes such as `SG` and `PH`. | | ISO 8601 UTC timestamp | A date and time expressed in UTC, such as `2026-08-04T05:07:00Z`. |