Operational lifecycle
The PNSL lifecycle starts before any payment is funded. A client must first be onboarded with Axiym and each funding request must be supported by suitable financing capacity.
1. Onboard the client
Onboarding may be completed through the API or through Axiym's manual process. Both routes complete KYB review. Because PNSL provides payment funding, it also requires financial due diligence and underwriting.
With API onboarding, POST /onboardings creates and immediately submits the
case for review. Document intake is owned by Axiym's compliance KYB flow and
is not exposed through PNSL.
Review is asynchronous. Poll GET /onboardings/{clientId} while the case is
ONBOARDING. A rejected case returns REJECTED. Once approved, the client
becomes available through the Clients endpoints. Client events notify you of
client lifecycle changes after that client record exists.
2. Check financing capacity
Call GET /clients/{clientId}/credit-accounts. Select an active credit account
whose currency and payment rail match the payment you intend to fund.
Use availableBalance to assess current capacity. A capacity check does not
reserve funds and can become stale.
3. Submit the payment for funding
Call POST /clients/{clientId}/receivables with the amount, currency, payment
rail, and original payment transaction. Send an idempotency key so an ambiguous
request can be retried safely.
The 201 response contains the created receivable and its receivableId.
Store it with your original payment identifier and clientId.
4. Track financing and disbursement
Process signed receivable.* events, then retrieve
GET /clients/{clientId}/receivables/{receivableId} when current state matters.
HTTP acceptance is not proof of disbursement. Advance your payment workflow only when the current receivable state supports it.
5. Manage the obligation
The receivable records the original principal, unpaid principal, total repayment amount, disbursement transaction, and repayment transactions.
In the normal repayment flow, funds deposited with the client's reference are
routed and applied automatically. POST /clients/{clientId}/repayments
triggers the same FIFO repayment mechanism from the linked client account
balance; it does not accept an amount. Use the refund endpoint for an
authorized refund adjustment.
6. Reconcile
Join the original client payment to the receivable, events, disbursement, repayments or refunds, and the client's credit-account balances. Use list and get endpoints to recover from missed or out-of-order events.
Lifecycle reference
| Stage | Primary resource or operation | What to retain |
|---|---|---|
| Onboarding | /onboardings | Your client reference and clientId |
| Capacity | Client credit accounts | Account, currency, rail, status, and available balance |
| Funding | Create receivable | Idempotency key, payment ID, and receivableId |
| Disbursement | Receivable and events | Event IDs, current state, and disbursement transaction |
| Repayment or refund | Financial operation and receivable | Request ID, idempotency key, amount, currency, and rail |
| Reconciliation | Receivables and credit accounts | Complete identifier chain and period-end values |
Contract rules to preserve
- Send and read monetary values as decimal strings, exactly as defined in the API Reference. Do not convert them to binary floating-point values.
- Treat receivable
statusas a contract-returned string. Preserve values you do not recognize and use the Events and Receivables references to interpret the lifecycle. - A
201response creates the receivable. It does not by itself prove that an external disbursement has completed.
For implementation details, start with Getting Started.