Reaching AnjirPay's cross-border transfer and bill-pay records

Every AnjirPay transaction begins on a Russian bank card and lands on a Uzcard, Humo, or Visa card in Uzbekistan, per the app's store listing. That single sentence sets the whole integration problem: the value moves across a border and across two national card systems, and the record you want to ingest changes state somewhere in between. The interesting work is not the first read of a transfer — it is knowing, reliably, when a transfer that left a Russian card has actually settled on the other side.

The recommended approach treats AnjirPay as an authenticated mobile surface we reconstruct under the account holder's consent, then ingest as a reconciling feed. The app's own screens — transfer history, service payments, receipts — define the record shapes; our job is to turn those into a stable, queryable interface plus runnable code your team owns. The corridor is crowded (TezPay, KWIKPAY, Yubor and others run the same route), but each app names its records differently, so the brief below is specific to AnjirPay.

The records AnjirPay actually carries

These map to surfaces a user sees in the app, as described in its Play Store and App Store listings. Granularity is what we expect to reconstruct from a consenting session, confirmed during the build.

Two routes that fit this app

Uzbekistan does not run a consumer open-banking consent regime of the UK or EU shape, so the dependable basis here is the account holder's own authorization rather than a statutory data-sharing mandate. That shapes which routes are real.

Authorized protocol analysis on a consenting account

We observe the app's own traffic against an account whose owner consents, reconstruct the session handshake and the transfer and payment endpoints, and rebuild them as a documented interface. This reaches everything in the table above at the cadence the app itself refreshes. It is the route we would lead with: it covers both record families, it survives because it tracks the app's real behaviour, and we re-validate it whenever the app ships a meaningful change. Access to a consenting account is arranged with you during onboarding.

User-consented credential session as a fallback

Where a live account holder drives the flow, a consent-scoped session can pull the same history without a standing reconstruction. This suits one-off exports or low-frequency pulls more than a continuous feed. It is lighter to set up and lighter to maintain, at the cost of freshness.

For a team that wants a continuously current ledger, the first route is the one to build on; the second is worth keeping for accounts that only need an occasional snapshot.

What lands in your repo

The headline deliverable is code that runs, not a document set you have to implement from.

• Runnable source for the transfer-history, service-payment and receipt surfaces — Python and Node.js clients with the session handshake, paging, and the reconciliation pass wired in.
• Status-reconciliation module that tracks each transfer from pending to settled or declined and emits only the records that changed since the last run.
• Automated test harness covering the record shapes and the state transitions, so a change in AnjirPay's responses shows up as a red test during maintenance.
• Normalized schema that splits card transfers from service payments under one account identity, ready to load into your store.
• Interface documentation describing each surface, its fields, and the FX and fee semantics across Uzcard, Humo and Visa.
• An OpenAPI/Swagger specification and a protocol and auth-flow report (token and session-cookie chain as it applies here) — included, alongside the code rather than ahead of it.
• Practical data-retention and minimization guidance for holding cross-border payment records.

A reconciliation sketch

Illustrative, in the shape we would ship. Field names are reconstructed from an authorized session and confirmed during the build; the host is resolved then, not guessed here.

# Reconcile AnjirPay transfer statuses against a local ledger.
# Pulls a short window, keeps only the records whose status moved.
import requests

BASE = "https://<resolved-at-build>/mobile/v1"

def fetch_transfers(session_token, device_id, cursor=None):
    r = requests.get(
        f"{BASE}/transfers",
        headers={"Authorization": f"Bearer {session_token}",
                 "X-Device-Id": device_id},
        params={"cursor": cursor, "limit": 50},
        timeout=15,
    )
    r.raise_for_status()
    body = r.json()
    # item: id, created_at, amount_rub, amount_uzs, fx_rate, fee_rub,
    #       dest_scheme ("uzcard"|"humo"|"visa"), dest_masked,
    #       status ("pending"|"sent"|"declined")
    return body["items"], body.get("next_cursor")

def reconcile(session_token, device_id, ledger):
    cursor, moved = None, []
    while True:
        items, cursor = fetch_transfers(session_token, device_id, cursor)
        for t in items:
            prev = ledger.get(t["id"])
            if prev is None or prev["status"] != t["status"]:
                ledger[t["id"]] = t
                moved.append(t)
        if not cursor:
            break
    return moved   # statuses that changed since the previous pass

Consent and the rules that apply

The Uzbek leg runs over Uzcard and Humo, the two national card systems supervised by the Central Bank of Uzbekistan under the Law on Payments and Payment Systems (ZRU-578 of 2019, most recently amended in late 2024 to raise information-security requirements, per Uzbek payment-law commentary). Personal data sits under the Law on Personal Data (ZRU-547), which was amended in early 2026 to ease cross-border storage and processing for international payment platforms, as reported by Uzbek news coverage. There is no consumer AIS consent surface to ride, so we anchor every read to the account holder's explicit authorization.

How we operate: access only with consent, every pull logged with a consent record, data minimized to the fields the integration needs, masked PANs kept masked, and an NDA in place where the engagement calls for one. The Russian originating leg adds its own card-network constraints, which we account for in how the session is handled rather than passing along to you as homework.

Engineering notes specific to AnjirPay

Two things about this app shape the build, and we handle both on our side.

• Three destination schemes, three settlement behaviours. Uzcard, Humo and Visa do not settle on identical timing and do not format masked card data the same way. We branch the parser per dest_scheme so a Humo transfer and a Visa transfer are normalized to the same ledger shape without losing scheme-specific detail.
• Status drift after send. A cross-border transfer is rarely final on first read; it walks from pending toward settled or declined. We design the feed so the reconciliation pass owns that drift, which means your ledger reflects the true final state instead of the optimistic first response.
• Two record families, one wallet. Transfers and utility/service payments share an account but differ in fields. We model them as distinct types under a common identity key so each can be reconciled on its own without double-counting the wallet.

Keeping the feed current

Because the records that matter move after they are first written, freshness is the design centre here, not an afterthought. The cursor poll is sized to the corridor's real settlement window — frequent enough to catch a transfer flipping to settled, sparse enough not to hammer the session. When AnjirPay changes a response shape, the test harness flags it during maintenance and we re-validate the affected surface. The aim is a ledger you can trust at a glance, not one you have to re-audit by hand.

Similar apps in the same corridor

These run comparable routes between Russia, the CIS and Uzbekistan; naming them maps the ecosystem a unified remittance integration usually spans. No ranking is implied.

• TezPay — Russia-to-Uzbekistan P2P transfers to Uzcard and Humo with a stated percentage fee; holds transfer and fee records.
• KWIKPAY — transfers from Russia to any Uzcard or Humo card; holds card-to-card transfer history.
• Yubor — cash and P2P card transfers from Russia to Uzbekistan; holds both cash-pickup and card records.
• PayWay — transfers across CIS destinations; holds multi-corridor transfer data.
• Avosend — transfers to MIR, UnionPay, Humo, Uzcard and bank accounts; holds multi-scheme payout records.
• AsiaExpress — money-transfer system focused on the Russia-Uzbekistan and wider CIS routes.
• Golden Crown (Korona) — account-free instant transfers with a large physical service network; holds transfer and pickup records.
• TransferGo — international transfers to Uzbek bank accounts with instant options; holds cross-border payout history.

Interface evidence

Store screenshots, useful for confirming which surfaces exist before a session is mapped.

How this was put together

Drawn from the app's own App Store and Play Store descriptions for its feature set, plus current Uzbek regulatory and fintech sources for the scheme and data-law context, checked in June 2026. Primary references:

• AnjirPay on the App Store
• Regulation of payment organizations in Uzbekistan
• Uzbekistan amends its personal data law for payment systems
• Uzbekistan fintech ecosystem overview

Compiled by OpenFinance Lab's integration engineering team, June 2026.

Questions an integrator tends to ask

How do you keep a transfer ledger in sync once an AnjirPay status changes after the money leaves the Russian card?

A card-to-card transfer can sit at pending for seconds or minutes before it settles on the Uzbek side, so we design the feed around a status-reconciliation pass rather than a single fetch. We pull transfers on a short cursor poll, compare each record's status against the last stored value, and emit only the ones that moved. The result is a ledger that converges on the final state of every transfer without re-reading the whole history each cycle.

Which regulator and card schemes sit behind AnjirPay's Uzbekistan leg?

The recipient side runs over Uzcard and Humo, the two national card systems overseen by the Central Bank of Uzbekistan under the Law on Payments and Payment Systems. Visa cards in Uzbekistan are also a destination per the app's listing. We map each scheme separately because settlement timing and the masked-PAN format differ between them, and we keep the integration inside the consent the account holder grants.

Can you separate utility and service payments from the card-to-card transfers in the export?

Yes. AnjirPay carries two distinct record families: cross-border card transfers, and service payments for electricity, gas, water, internet, TV/IPTV and loans. They share a wallet but have different fields, so we model them as separate record types with a common identity key. That lets you reconcile remittances and bill payments independently while still rolling both into one account view.

How quickly can a first AnjirPay reconciliation feed be running against a consenting account?

A first working feed over the transfer and payment surfaces lands inside one to two weeks. Early days go to mapping the session and the record shapes against a consenting account; the back half goes to the reconciliation logic, the test harness, and the interface docs you keep.

On commercials: a source-code build of the AnjirPay interface starts at $300, billed after delivery once it runs to your satisfaction; if you would rather not host it, the same surfaces are available as a pay-per-call hosted API with no upfront fee. Either way the cycle is one to two weeks. Tell us the app and what you need from its data and we take it from there — start a conversation here.