Glossary

This section defines key terms used throughout the PNSL API documentation.

Payment Network

A Payment Network is the partner institution integrating with the PNSL API. It retains the relationship with the Clients it represents.

The Payment Network is responsible for:

• Onboarding Clients
• Initiating payment funding requests
• Submitting repayments
• Receiving webhook notifications

Client

A Client is the legal entity whose payments may be funded through the PNSL API.

Clients are typically financial institutions like Money Service Businesses (MSB’s), Payment Service Providers (PSP’s), and others that originate payments through a Payment Network.

A Client must be onboarded with Axiym before it can use PNSL. This includes compliance verification and PNSL financial underwriting before the Client becomes eligible for payment funding. Onboarding can be completed through the API or manually with Axiym.

Each Client is identified by a unique clientId.

Credit Account

A Credit Account represents the financing capacity available to a Client for a specific currency and payment rail. The Client is also the Payment Originator.

A Client may have multiple accounts, each associated with:

• A specific currency
• A funding/credit limit
• Current balances and outstanding obligations

Payment Originator

The Payment Originator refers to the entity initiating a payment through the Payment Network.

Within the PNSL API documentation, the Payment Originator is the same entity as the Client. The terms may be used interchangeably depending on context:

• Client is used when referring to the entity’s onboarding, account, and credit relationship with Axiym.
• Payment Originator is used when referring to the entity initiating a payment transaction.

Both terms refer to the same legal entity.

Payment Rails

A payment rail is a configured settlement channel Axiym uses to hold and move funds. A rail may represent a banking partner for fiat accounts (e.g. ZENUS_BANK, FREEMARKET) or a blockchain network for digital-asset wallets (e.g. TRON, AVALANCHE). Each rail is identified by a unique code, returned by GET /settings/payment-rails.

Payment rails are used when processing:

• Payment disbursements (when Axiym funds a payment)
• Repayments (when repayment funds are processed through the Payment Network)

A payment rail represents the infrastructure through which settlement occurs, such as a specific banking relationship or settlement channel.

Choosing a Payment Rail

When an operation accepts paymentRails, use a code returned by GET /settings/payment-rails. The request schemas determine whether it is required for that operation. Do not assume a default rail when the field is omitted; confirm the applicable settlement arrangement with Axiym.

Payment Transaction

A Payment Transaction represents the original payment that was initiated the Client/Payment Originator and which the Payment Network wants Axiym to fund and triggered the receivable.

This transaction includes:

• A unique payment identifier
• A timestamp
• Payment data associated with the original transaction

Receivable

A Receivable represents the financial obligation created when Axiym funds Payment Transaction on behalf of a Client.

When a payment is executed by the Payment Network and funded through Axiym, Axiym creates a receivable that records the financial terms of that funding event.

Each receivable includes:

• The original funded amount (initialPrincipal)
• The remaining outstanding amount (currentPrincipal)
• The total repayment amount due (including fees or interest)
• The payment transaction that triggered the funding

Use the returned receivable status, principal values, and transaction records to track the obligation over time.

Funding a Payment

Funding a Payment is the process through which Axiym finances a payment initiated by a Client through a Payment Network.

When a payment is funded:

1. The Payment Network submits request to Axiym to fund a Payment Transaction.
2. Axiym creates a receivable associated with that payment.
3. Axiym disburses the funds through the configured settlement rail.
4. The Payment Network tracks the receivable, disbursement, and applicable events before advancing its own payment workflow.

This process allows payments to be executed without requiring the Client to pre-position funds.

Disbursement

A Disbursement represents the movement of funds from Axiym to the Payment Network to support a funded Payment Transaction.

Disbursements occur after a receivable has been created and represent the settlement of the financed payment through the configured payment rail.

Each disbursement is recorded as a Disbursed Transaction within the receivable.

Repayment

A Repayment represents the settlement of a receivable after a payment has been funded.

Repayments occur when funds corresponding to previously funded payments are processed through the Payment Network and transferred to Axiym.

A receivable may be repaid through one or multiple repayment transactions until the outstanding principal and associated fees are fully settled.

Each repayment is recorded as a Repayment Transaction.

Webhook

A Webhook is a real-time notification sent by Axiym to the Payment Network to communicate system events.

Webhook notifications are used to inform integrators about:

• Client onboarding status changes
• Account updates
• Fund Flow events
• Operational events

Client Status

A Client progresses through several states during onboarding: