UPAYNET keeps every cross-border top-up behind one account — the authorized route to that data

Every top-up UPAYNET processes lands as a dated, USD-priced transaction tied to a sender account and a destination number in Uzbekistan or Tajikistan. That is the asset worth integrating: not a marketing surface but a live ledger of who funded what, through which card or wallet, to which operator, with a status that moves from pending to delivered within five to fifteen minutes. The app also carries saved beneficiary numbers, a multi-rail payment-method list, ISP and utility payments, and — in recent versions — air-ticket orders. The route into all of it is authorized interface integration of UPAYNET's own client-server traffic, operated under a consenting account. Below is what is reachable, how we'd build it, and what you receive.

Where UPAYNET keeps the records worth syncing

Each row maps a domain to the screen it originates from, the grain you get, and what an integrator does with it. These reflect UPAYNET's actual surfaces as described on its store listing and site, not a generic finance template.

The authorized ways into the top-up data

Three routes genuinely apply here. A fourth is on the horizon and named honestly as future, not current.

1 — Interface integration of UPAYNET's client-server traffic

We analyse the app's own authenticated traffic under your authorization and rebuild the calls behind history, methods, favourites, profile, bill pay and ticket orders as a clean interface. Reachable: the full per-account surface. Effort: medium. Durability: bound to the app's client version, which we account for in maintenance. We set up a consenting test account and the capture environment as part of the build — that is our step, arranged with you, not something you hand over before we start.

2 — User-consented credential access

We operate as the account holder using their own credentials and session, read-scoped and logged. Reachable: the same per-account data the user sees. Durability: solid while consent and the session remain valid; we design around the session window so a sync does not silently expire.

3 — Device-side history as a supplement

Where UPAYNET surfaces a shareable history view, we use it as a low-friction supplement to confirm field meanings and back-fill older records. It is a corroboration path, not the spine.

4 — Uzbekistan open banking (forward-looking)

A national open-banking regime is expected to go live around September 2026 under a presidential decision. When it arrives it may offer a consent-based rail for the bank-funding leg; today it is not something to build on, and we say so plainly.

For UPAYNET the working recommendation is route 1 as the structural backbone, run through route 2's consent so every pull is attributable to a real sender, with route 3 used only to validate fields. We build it that way because the value is the transaction ledger, and the ledger only makes sense per authenticated account.

A recharge-history pull, sketched

Illustrative of the shape we implement; exact field names and the auth chain are confirmed during the build against a consenting account, since UPAYNET's client is not publicly documented.

POST /auth/session
  body: { login, secret }            # session established as the consenting sender
  -> { session_token, expires_in }   # short-lived; we schedule refresh inside expires_in

GET /account/recharges?from=2026-01-01&cursor=
  headers: { Authorization: Bearer <session_token> }
  -> {
       items: [
         { id, created_at,
           charged: { amount: "12.00", currency: "USD" },     # what the sender paid
           delivered: { value: "150000", currency: "UZS",     # what landed on the SIM
                        operator: "Beeline", msisdn: "+998..." },
           method: { type: "card", network: "VISA", last4 },
           status: "delivered" | "pending" | "failed" },
         ...
       ],
       next_cursor
     }

errors:
  401  -> session expired      => re-auth, resume from last cursor (idempotent)
  429  -> throttled            => respect Retry-After, backoff, do not double-count
  409  -> record state changed => re-fetch the single id, not the whole page

The charged-vs-delivered split is the part most naive integrations get wrong; we carry both, plus operator and status, so reconciliation survives the USD-to-UZS/TJS conversion.

What lands in your repo

Concrete artefacts, each tied to a UPAYNET surface above:

• An OpenAPI specification covering session, recharge history, payment methods, favourites, bill payments and ticket orders.
• A protocol and auth-flow report: the exact session/token chain, refresh behaviour, pagination and the charged/delivered field model.
• Runnable source for the key endpoints in Python and Node.js — the history pull, the method list, the favourites read.
• Automated tests, including the currency-split assertion and the pending-to-delivered status transition.
• Interface documentation a developer can hand to a teammate.
• Data-retention and consent-logging guidance written against the Uzbek rules below.

Where integrators actually use this

• A remittance dashboard that shows a US-based sender every top-up to family in Tashkent, reconciled by the USD charged and the UZS delivered.
• A bookkeeping sync that pulls a small reseller's UPAYNET activity into accounting, split by operator and payment rail.
• A fraud-and-limits check that watches a sender's saved-number set and method list for sudden change before a large recharge.
• A support tool that resolves “my top-up did not arrive” by reading the live status field instead of asking the user to screenshot it.

Consent and the Uzbek data rules that apply

The governing instrument for the people whose data this is — senders topping up numbers in Uzbekistan — is the Law of the Republic of Uzbekistan No. ZRU-547 “On Personal Data” (adopted 2 July 2019, effective 1 October 2019, per published legal analyses). Cross-border handling is permitted to states with adequate protection; absent an adequacy list, the explicit consent of the data subject is the operative basis, which is exactly the basis we build on. Amendments to Article 27¹ in the 2024–2025 cycle eased blanket localization, but telecom-related identifiers remain in the domestically-stored category — relevant here because destination MSISDNs are telecom data, and we keep the data flow consistent with that carve-out. Uzbekistan's open-banking regime is a 2026 forward step, not a current rail, and the page does not lean on it. In practice that means consent records kept per sender, read-only scope, data minimization to the fields an integration needs, request logging, and an NDA where the engagement calls for one.

Engineering realities we plan around

Two specifics shape how we build this, both handled on our side:

• Multi-rail funding. UPAYNET accepts a long, mixed set of payment methods — card networks plus PayPal, Apple Pay, Google Pay, Cash App, Amazon Pay and Authorize per its own materials. We normalize these into one method schema so your downstream code does not branch per provider, and so a new rail added by UPAYNET maps into the existing model rather than breaking it.
• Frequent feature additions. The app has been adding surfaces — the Air Tickets section, newer pay methods such as Amazon Pay and Authorize. We schedule a periodic capture-and-diff against the live client so a changed or added screen shows up in our test run, not in your production data.
• Currency duality. Pricing and charging are in USD while delivery is in UZS or TJS; we keep both sides of every record so reconciliation is correct rather than off by the FX spread.

Cost and how the build runs

Source for the recharge-history, payment-method and favourites endpoints lands in your repository within one to two weeks of the go-ahead. From there it works one of these ways. Source-code delivery starts at $300: you get the runnable code, the OpenAPI spec, tests and the interface docs, and you pay only after delivery, once you are satisfied it does what this brief describes. Or the hosted route — we run the integration and you call our endpoints, paying per call with no upfront fee. You give us the app name and what you want out of UPAYNET's data; access, the consenting account and compliance scaffolding are arranged with you during onboarding. To start or ask a specific question, get in touch with OpenBanking Studio.

Screens we mapped against

Store screenshots used to confirm the surfaces named above. Select to enlarge.

What was checked

In May 2026 we reviewed UPAYNET's Google Play listing and the operator's own site, including its announcements and support pages, to fix the data surfaces and the charged/delivered behaviour; the Uzbek personal-data position was taken from published legal analyses, and the open-banking timeline from primary regional reporting. Sources opened: Google Play listing, UPAYNET announcements, Uzbekistan personal-data compliance (Legal 500), Uzbekistan open-banking timeline (Kursiv).

Mapped by the OpenBanking Studio integration desk, May 2026.

The cross-border top-up neighbourhood

Same-category services an aggregator would normalize alongside UPAYNET. Listed for ecosystem context, not ranked.

• Ding — international airtime top-up across many operators and countries; per-transaction recharge records by operator and amount.
• Recharge.com — global mobile top-ups via app and web; account holds order history and saved recipients.
• BOSS Revolution — international top-up and calling; transaction ledger plus calling-credit balances per account.
• MobileRecharge.com — worldwide top-up service; per-user history and beneficiary numbers.
• Rebtel — calling and mobile top-up; account activity spanning recharge and call spend.
• TopUp.com — international airtime; order history keyed to destination operator.
• DoctorSIM — international top-up and related mobile services; per-account order records.
• Fonoma — regional top-up and bill payment; transaction history by service and operator.

Questions integrators ask about UPAYNET

Can you keep the USD amount charged separate from the airtime value delivered in UZS or TJS?

Yes. UPAYNET prices and charges in US dollars while the credit lands in the destination operator's currency, so every record is stored with both sides: the USD debit against the sender's payment method, and the destination-side value and operator. Reconciliation that ignores the currency split is wrong by the FX spread, so we carry both fields through the schema.

Does the route survive UPAYNET adding sections like the Air Tickets tab or new pay methods?

It does, because we do not hard-code the screen layout. UPAYNET ships feature additions fairly often, with the Air Tickets section and pay methods such as Amazon Pay and Authorize among recent ones. We capture the live client on a schedule and diff it, so a changed surface shows up in our test run rather than in your production data.

If we only have a consenting sender's login, can you still pull their favorites and saved payment methods?

Yes. Under user-consented access we operate strictly as the account holder using their own credentials and session, scoped to read, and logged. That reaches the same per-account surface the app shows that user: recharge history, saved favourite numbers, the tokenized payment-method list, profile and bill payments.

Which Uzbek data rule governs a pull of a sender's recharge history, and is open banking relevant yet?

The governing instrument is Uzbekistan's Law ZRU-547 On Personal Data, which requires explicit consent of the data subject for cross-border handling absent an adequacy finding. Uzbekistan's open banking regime is expected to go live around September 2026 per a presidential decision, so it is a forward-looking rail, not a basis you can build on today. The dependable basis now is the sender's own authorization.