# Payment Providers in Azerbaijan: From AniPay ID to Payment Evidence

When comparing payment providers in Azerbaijan, ask how the proposed service confirms a recipient and what happens when that recipient cannot be found. A familiar payment name can make a proposal sound complete. A merchant still needs to understand who receives the funds, what information is confirmed, and which record proves the outcome. For AZN collections and business payouts, those details should shape the shortlist before integration starts.

## A numerical starting point for the provider comparison

We reviewed **61 unique historical payment offers** linked only to this country: 32 collection offers and 29 payout offers. They provide a structured starting point for comparing payment costs, access to funds and operational requirements. 65 additional offers linked to several countries are excluded from the country-only calculations below.

The source is the PayStar export dated 14 September 2026, supplied by payment gateways. We recomputed its aggregates, but did not independently verify its commercial statements. This is a historical sample, not a market survey, a count of PSPs or methods, or proof of active connections and current availability. Conditions can change weekly or more often. Independent country, currency and method associations do not establish every possible payment route. Direction counts and settlement-label charts cover all recorded currencies. Only the percentage comparison below is restricted to explicit AZN fee records.

61 unique offers linked only to this GEO, across all recorded currencies; not methods, providers or live connections. [Download SVG](https://paystar.uk/azerbaijan-payment-solutions/media/2026-10-08-v2/charts/offers-en-desktop-download.svg)

## What the recorded AZN percentage components show

We calculate the arithmetic mean of explicit percentage components stated in AZN, giving each comparable offer equal weight. A record qualifies only when its structured percentage matches one unambiguous percentage in the original fee description. Offers in another fee currency, missing percentages and ambiguous descriptions are excluded.

We also exclude bound or conditional percentages such as “from”, tiers and explicitly restricted customer categories. Exact nominal percentage components with fixed minimums or caps can remain in the sample; those minimums and caps still affect the final charge.

| Direction | n | Mean | Median | Range |
| --- | --- | --- | --- | --- |
| Collections | 27 | 7.16% | 7% | 5.5–10.5% |
| Payouts | 27 | 2.63% | 2.5% | 2–3.5% |

Explicit AZN percentage components only. n is the comparable sample in each direction; missing fees are excluded, not zero. [Download SVG](https://paystar.uk/azerbaijan-payment-solutions/media/2026-10-08-v2/charts/fees-en-desktop-download.svg)

**These are percentage components, not all-in payment prices.** Fixed charges, FX, tax, reserves, minimums and charges for refunds or other exceptions must be assessed separately. This sample is not weighted by payment volume, contains no measured conversion rate and cannot rank provider quality. Small or insufficiently independent groups are withheld.

### A hypothetical payment calculation

Take an illustrative payment of 20 AZN; this is not a typical market ticket. Applying the rounded means shown above gives:

- Collections: 20 AZN × 7.16% = **1.43 AZN**.
- Payouts: 20 AZN × 2.63% = **0.53 AZN**.

Each line is a separate direction, not a combined service quote. The arithmetic shows only the percentage part. Ask for an actual quote at your ticket size, volume, business model and settlement currency before calculating net proceeds.

## When money becomes usable matters

Collection offers across all recorded currencies. T/D labels are recorded as supplied, without assuming calendar or business days. Other includes complex labels and pooled groups below 3 records. No guaranteed settlement time. [Download SVG](https://paystar.uk/azerbaijan-payment-solutions/media/2026-10-08-v2/charts/timing-en-desktop-download.svg)

A successful payment notification and money available to your business are different events. Treat recorded settlement labels as questions for a provider: what starts the clock, which cut-off applies, are weekends counted, which account is credited, and can a reserve or review delay availability?

For payouts, agree prefunding, beneficiary validation, rejection handling and how returned funds appear in your balance. An incoming-payment settlement label does not prove payout completion time.

### A cash-buffer planning example

If a business must fund 2,000 AZN of obligations per day, a one-day gap requires 2,000 AZN; a three-day gap requires 6,000 AZN. The additional buffer is 4,000 AZN. This is a hypothetical constant-flow model, excluding fees, reserves and volatility, not an observed settlement promise.

## Separate the network, identifier and checkout

The Central Bank announced on 3 March 2026 that the standalone AniPay mobile application and anipay.az website would be suspended from 4 March 2026. The notice says AniPay functions are available in mobile banking applications; the exact participating bank channel must be confirmed. For a merchant flow, qualify the actual bank or PSP channel rather than treating the former standalone portal as a current access route. [Central Bank: AniPay channel suspension notice](https://www.cbar.az/press-release-5430/anipay-mobile-application-and-anipayaz-to-be-suspended?language=en).

AZQR has its own requirements, approved on 12 November 2025, covering QR structure and merchant payment flows. It should be specified separately in a provider brief rather than treated as another name for a consumer app. [Central Bank: AZQR requirements](https://uploads.cbar.az/assets/6604bb880086ac07bab384bc8.pdf).

For qualification, write down four things: the underlying payment system, the identifier or account details used, the customer-facing payment flow, and the provider offering that flow to your business. Ask the PSP to demonstrate the proposed combination. A consumer-facing description alone cannot establish the merchant API, account eligibility or commercial arrangement you need.

## Make recipient resolution part of the evaluation

There is a useful local reference point. Annex 3 of the Central Bank's 2026 IPS operational rules describes AniPay ID account linking, retrieval of beneficiary details, masked recipient-name display and user confirmation. It also calls for feedback when the ID does not exist or has no linked account. These provisions concern participants' electronic banking services. [Central Bank: IPS operational rules, Annex 3](https://uploads.cbar.az/assets/ba8f0448a1d9c9170c0879e36.pdf).

Use that context to ask specific implementation questions. What can your business see before initiating a payout? Who confirms the destination? How does the provider distinguish an unresolved identifier from a rejected or completed transfer? Request sample responses and an explanation of what each response permits your operations team to do next.

Treat recipient confirmation as one piece of evidence. Separately establish the permitted business purpose, beneficiary eligibility and controls for changing a saved recipient. A recognisable name on screen does not answer those questions.

## A local scenario: a saved AniPay ID cannot be resolved

Ask a candidate PSP to walk through this hypothetical case: your business wants to pay a local service provider in AZN using a saved AniPay ID, but the identifier now has no linked account. First establish whether the proposed service supports this payout purpose and identifier at all.

Then examine the failure. Is it a recipient lookup failure before a payment exists, a rejected payment instruction, or an operation whose result is still unknown? Ask what evidence distinguishes those states and whether any funds were debited or reserved. A generic failure message leaves the next action uncertain.

If the recipient supplies a replacement identifier, decide who verifies the new destination and what confirmation is retained. Before resubmission, establish what happened to the earlier request. An unknown outcome needs investigation through the PSP's agreed status or support process; a new payout could otherwise duplicate an operation that completed.

Request a demonstration of the actual product and its documented retry procedure. This is a qualification exercise, not a claim that every PSP exposes recipient lookup, a particular error code or an automated recovery flow. The answer should tell your operators when to correct data, when to investigate and what authorises a retry.

## Compare collections and AZN payouts separately

Use a short evidence table during provider discussions:

| Decision | Collections: evidence to request | Payouts: evidence to request |
| --- | --- | --- |
| Business fit | Confirmation of the merchant entity, activity and checkout channel accepted | Confirmation of the sender, beneficiary types and permitted purposes |
| Recipient and reference | Merchant identity shown to the payer; reference returned with payment | Supported account or identifier fields; recipient checks before submission |
| Outcome | Payment notification, status lookup and an example of an unmatched payment | Distinct responses for invalid destination, pending, rejected and completed transfers |
| Exceptions | Refund procedure, duplicate payments and investigation ownership | Retry rules, duplicate prevention and returned-payment handling |
| Money available | Settlement account, currency, deductions and release schedule | Funding account, balance availability, fees and applicable limits |

Request the answers for the exact service being offered. If one PSP supports collections and another supports payouts, compare the operational handover as well as their prices. Identify which team reconciles incoming receipts, outbound transfers and each provider's statements.

For settlement, ask when funds become usable in the account your business will operate. If the quoted currency differs from your required account currency, identify the conversion step, rate basis and deductions. Record these alongside a sample statement before comparing headline fees.

The purpose of [payment reconciliation](https://paystar.uk/reconciliation) in this evaluation is concrete: your team should be able to connect each payout request, its confirmed outcome and any resulting account movement.

## The role of PayStar

PayStar provides information for comparing payment solutions and, where agreed, a technical layer for connecting and operating them. PayStar is not a bank or payment service provider and does not accept, hold or settle customer or business funds in its own name.

You select the payment provider and enter into a direct agreement with it. The provider processes payments and performs settlement under that agreement. Local eligibility, required authorisations and commercial terms must be confirmed for your company and use case. A method described in this article is not a promise that it is available through PayStar for your business.

Information about payment options is free. Payment processing and any agreed technical services have separate commercial terms.

## Official sources and research scope

- [CBAR: AniPay channel suspension](https://www.cbar.az/press-release-5430/anipay-mobile-application-and-anipayaz-to-be-suspended?language=en)
- [CBAR: AZQR requirements](https://uploads.cbar.az/assets/6604bb880086ac07bab384bc8.pdf)
- [CBAR: IPS operational rules, Annex3](https://uploads.cbar.az/assets/ba8f0448a1d9c9170c0879e36.pdf)

Research check: 8 October 2026. The export date remains 14 September 2026. Local scheme descriptions are context, not confirmation of a particular provider’s capabilities.