Axiym

Getting Started

This guide takes you from initial access through your first payout and the operational handling required for production.

The integration path

1. Set up

2. Validate your data

  • Discover the corridors available to the partnership.
  • Decide whether sender and receiver use Axiym's fields or a stored Party Data Map.
  • Run Payout Test with representative party, transaction, and document data.
  • Resolve every normalization or validation issue before creating a payout.

3. Execute a payout

  • Request a quote against a funded Axiym account.
  • Prepare the payout using the active quote.
  • Review the final mapped and normalized instruction.
  • Confirm it before the deadline. Confirmation reserves totalPayable and starts asynchronous processing.

4. Operate reliably

  • Verify signed webhook events and de-duplicate deliveries.
  • Poll the payout when authoritative current state matters.
  • Retry ambiguous state-changing requests with the same idempotency key.
  • Reconcile settled movements against the funding account statement.

Complete Make your first payout to see the full payment sequence.

Implementation guides

GuideOutcome
Discover corridorsSelect an available route and retrieve its amount limits and requirements.
Prepare and test payout dataChoose a party-data structure, optionally store a map, and validate representative data without creating a payout.
Request a quoteObtain immutable sell and buy amounts, rate, fee, and expiry.
Create and confirm a payoutPrepare, review, and confirm the complete payment instruction.
Track a payoutProcess asynchronous status updates using webhooks and polling.
Reconcile payoutsJoin payouts, events, references, and account statement entries.

Shared fundamentals

Use these rules across every endpoint:

Production-ready checklist

  • Credentials and base URLs are isolated by environment.
  • Every runtime calls from an allowlisted public egress address.
  • Every account, quote, payout, Party Data Map, and webhook subscription belongs to the authenticated partnership.
  • The selected funding account is active, payout-enabled, and sufficiently funded before the payment is confirmed.
  • State-changing requests use stable idempotency keys across retries.
  • Quote expiry and invalidation are handled before payout confirmation.
  • Representative payout data has been tested for each supported destination context and input structure.
  • Stored Party Data Map versions are tied to the integration version that uses them.
  • The prepared payout's final normalized values are reviewed before confirmation.
  • Confirmation reservations and settlement debits are represented separately.
  • Webhook signatures are verified against the raw request body.
  • Event deliveries are de-duplicated and can arrive out of order.
  • Payouts are polled when current state matters.
  • Account statement reconciliation can recover from missed notifications.
  • Secrets, access tokens, base64 document content, and sensitive party data are excluded from application logs.