Integrate using AI

Use the sources below with your coding agent to build a Payment API integration.

AI-readable documentation

Source	Use it for
Payment API llms.txt	Finding guides, references and available versions.
Markdown pages	Reading guides and examples. Use View Markdown or append `.md` to a documentation page URL.
OpenAPI contracts	Versioned operations and request/response schemas.

Markdown is generated from the same sources as this site. Give your agent the relevant links; llms.txt is not automatically read by every tool. If it cannot fetch a page, paste the Markdown instead.

Describe one feature at a time

Include your feature goal and application constraints. For example:

Add Payment API corridor discovery to our payout form. Show availability, limits and required fields for the selected destination, using our existing backend client and UI patterns.

For larger integrations, work incrementally through corridor discovery, payout preparation, review and confirmation, and outcome tracking.

Optional integration prompt

Copy the prompt into your coding agent with your repository open. Add your feature goal; the prompt supplies documentation links and Payment API guidance.

Payment API integration

Add your feature goal when you paste this into your coding agent.

Help me integrate the Axiym Payment API into the application in this repository.

Implement only the feature I describe alongside this prompt. If I have not supplied a feature goal, ask what I want to build before choosing the scope. Follow the application's existing architecture and conventions.

## Start with the application

Inspect the repository's instructions, language, framework, HTTP client, configuration, authentication and authorization, persistence, background jobs, and tests. Find any existing Axiym integration before adding another one. Reuse the project's established components and libraries.

Explain where the integration will fit and then implement it. Ask focused questions only when a missing decision materially changes the implementation. If no application repository is available, ask which project to use before creating a new application. If this is a backend-only project, implement the appropriate service/API interfaces and document how a caller supplies the review and confirmation decision.

## Read the Axiym sources

Target Payment API 0.1.0 and event reference 0.1.0. These versions were selected when this prompt was copied. Use matching contracts and verify that current guides still describe those versions. Flag any mismatch and establish the intended version before implementing.

Start with:
- Documentation index: {{DOCS_ORIGIN}}/payment-api/llms.txt
- Getting started: {{DOCS_ORIGIN}}/payment-api/integration-guide/quickstart.md
- Access and environments: {{DOCS_ORIGIN}}/payment-api/integration-guide/access-and-environments.md
- Sandbox validation: {{DOCS_ORIGIN}}/payment-api/integration-guide/sandbox-testing.md
- API contract: {{DOCS_ORIGIN}}/openapi/payment-api/0.1.0.yaml
- Event contract: {{DOCS_ORIGIN}}/openapi/payment-api/events/0.1.0.yaml

Read the guides relevant to the requested feature:
- Authentication: {{DOCS_ORIGIN}}/payment-api/integration-guide/fundamentals/authentication.md
- Idempotency: {{DOCS_ORIGIN}}/payment-api/integration-guide/fundamentals/idempotency.md
- Errors and retries: {{DOCS_ORIGIN}}/payment-api/integration-guide/fundamentals/error-handling-and-retries.md
- Pagination: {{DOCS_ORIGIN}}/payment-api/integration-guide/fundamentals/pagination-and-query-parameters.md
- Corridor discovery: {{DOCS_ORIGIN}}/payment-api/integration-guide/discover-corridors.md
- Payment data preparation: {{DOCS_ORIGIN}}/payment-api/integration-guide/prepare-payout-data.md
- Payment Data Maps: {{DOCS_ORIGIN}}/payment-api/integration-guide/prepare-payout-data/payment-data-maps.md
- Create, review and confirm: {{DOCS_ORIGIN}}/payment-api/integration-guide/create-a-payout.md
- Tracking: {{DOCS_ORIGIN}}/payment-api/integration-guide/track-a-payout.md
- Reconciliation: {{DOCS_ORIGIN}}/payment-api/integration-guide/reconcile-payouts.md
- Webhook registration: {{DOCS_ORIGIN}}/payment-api/webhooks/registration-and-management.md
- Webhook signatures: {{DOCS_ORIGIN}}/payment-api/webhooks/verifying-signatures.md
- Webhook processing: {{DOCS_ORIGIN}}/payment-api/webhooks/overview.md

Use these sources for endpoints, schemas, scopes, states, signature verification and retry rules. Follow linked operation and schema references for field details. If sources conflict or cannot be retrieved, identify the gap and ask for the missing information. Do not invent endpoints, an Axiym SDK or undocumented behavior.

## Implement the requested functionality

Apply only the guidance relevant to the requested feature, in manageable steps. Use the existing server-side HTTP stack and configuration or secret store. Derive authentication and environment URLs from the documentation. Keep credentials and tokens server-side, omit secrets from logs, and supply empty example configuration values. Represent monetary values without floating-point rounding errors.

1. Discover accessible funding accounts and available corridors, then retrieve the selected corridor's limits and data requirements. Listing an account does not establish payout eligibility: the selected account must be active, payout-enabled and sufficiently funded at confirmation. The current Payment API supports bank destinations; it does not fund accounts. Keep accounts, corridors, payouts and Payment Data Maps within the same integration and environment.

2. Prepare payment data using the baseline payout schemas alongside the selected corridor requirements. When paying for yourself, omit sender; Axiym uses the account holder's onboarded profile. Supply sender details when paying on behalf of another party, purpose and supporting documents where required, and an optional reference. Choose direct Axiym-shaped input or a registered Payment Data Map only as needed. For a mapped integration, consult the Payment Data Maps overview, the mapper's How it works page, and the mapped payout API reference. Follow the reviewed map and published request contract. Direct and mapped payouts must satisfy the same payment-data requirements. Do not invent mappings, required fields or document fixtures; use the preparation guides and selected contract.

3. Create the payout and retain its identifier and returned prepared instruction and commercial terms for review. Creation does not reserve funds or start processing. Keep confirmation as a separate explicit decision before terms expire. Review translated values and accepted document metadata as well as amounts and fees. A material correction requires a new payout, not altered details in confirmation.

4. Keep creation and confirmation idempotency keys distinct and reuse each key for retries of that exact operation. Handle expiry, insufficient funds and ambiguous responses without duplicate execution. Confirmation reserves funds and starts processing; it is not compliance approval or proof of delivery.

5. Track documented outcomes through signed webhooks and authoritative retrieval. Reconcile payout identifiers with account statements, distinguishing reservation from settlement. Use the documented signature verification, deduplication and recovery procedures. Coordinate sandbox outcome scenarios with Axiym; do not assume live bank progression or invent simulation endpoints.

## Verify and hand over

Use mocked responses and synthetic fixtures derived from the selected contracts. Test authentication, authorization, pagination and error handling as relevant, plus corridor unavailability, incomplete payment data, amount modes, prepared instruction review, creation without confirmation, expired terms, insufficient funds, ambiguous confirmation, duplicate or out-of-order events, and settlement reconciliation. For webhook features, cover invalid signatures and recovery from missed notifications.

Run the project's relevant checks and fix failures caused by your changes. Code generation and local tests should not require real credentials. Leave live API calls, webhook registration, deployment and money movement for separately requested setup or validation.

Finish with changed files, configuration instructions, checks actually run, assumptions and remaining gaps. Distinguish passing local tests from a verified sandbox integration, and list the provisioning and application decisions still needed.

Preview the full prompt before copying. Documentation links and versions are filled in automatically.

Review and validate

Passing local tests does not verify an Axiym integration. Use the quickstart and sandbox testing guide to validate your selected flows with provisioned access.

AI-readable documentation

Describe one feature at a time

Optional integration prompt

Review and validate

On this page