Pulling a shop's receivables out of Direct (دايركت)

What sits behind a Direct login

Every customer balance a shop tracks in Direct sits on the app's servers, not the handset. Its store listing describes electronic storage that opens from any device, with detailed debt reports the merchant can push to Telegram. The ledger lives server-side. For a third party — an accounting tool, a collections desk, a credit model — that means a shop's whole receivables book is reachable through one authorized account, and that account is where we build the integration.

The short of it: the records worth syncing are per-customer entries and the balance each one rolls up to, the authorized way in is the app's own sync driven by the account holder's consent, and the Telegram report channel gives a cheap second source for the aggregate numbers. The rest of this maps each piece against what we hand over.

The receivables Direct keeps for a shop

Each row is a surface Direct exposes to its own client. The granularity column is what an integrator actually gets to work with once the sync is mapped.

Routes into a merchant's ledger

Reaching the ledger comes down to where you tap it. Three authorized paths apply here, and they differ in what they return and how long they hold up.

Interface integration of the app's sync

We capture and document the traffic the Direct client exchanges with its backend — login, token, the per-customer entry queries — under the merchant's authorization, then rebuild it as a clean client. Reachable: the full ledger as the app itself sees it, down to individual entries and live balances. Effort is moderate; durability is tied to the app's private endpoints, so it wants a refresh when the app updates. Access is arranged with you during onboarding, against a consenting account.

User-consented credential access

Where the merchant prefers to drive it through their own session, they authorize us to operate a scoped token on their account and we sync their own data through it. Same scope as the route above; the practical limit is token and session lifetime, which we design the refresh around. We set up the consent records and keep the access logged.

Native export — the Telegram feed

The report-to-Telegram feature already emits formatted summaries. We can read that channel as a low-effort export for aggregate reporting. It is light to stand up and stable in format, but it carries period summaries rather than entry-level lines.

For most jobs we would build against the app's own sync traffic, because that is the only path that returns line-level entries and current balances rather than a periodic summary, and we keep the Telegram feed wired in alongside it as a cheap reconciliation source. If all a team needs is a weekly receivables digest, the Telegram channel alone can carry it.

How a balance pull would look

Illustrative shape only — the exact paths, field names and auth header are confirmed against a live session during the build, not asserted here. It reflects the surfaces above: a token login, then a per-customer entry query returning IQD amounts, Arabic notes and Iraq-local timestamps.

# Illustrative; confirmed during the build
POST https://api.<direct-backend>/auth/login
{ "phone": "+9647xxxxxxxxx", "pin": "••••" }
→ 200 { "token": "ey…", "store_id": 4821, "expires_in": 86400 }

# One customer's ledger lines
GET /api/v1/customers/1934/entries?store_id=4821
Authorization: Bearer ey…
→ 200 {
    "customer": { "id": 1934, "name": "…", "balance": "275000", "currency": "IQD" },
    "entries": [
      { "id": 88142, "type": "debit",  "amount": "300000", "note": "بضاعة", "at": "2026-05-02T09:14:00+03:00" },
      { "id": 88207, "type": "credit", "amount": "25000",  "note": "دفعة",  "at": "2026-05-19T17:40:00+03:00" }
    ]
  }

# Normalize on the way out: ٠-٩ → 0-9, RTL amount → integer minor units, tag IQD

The two things worth noting in that response: amounts come through as Arabic-Indic strings inside an RTL field, and the timezone offset is +03:00 for Iraq. Both get normalized before anything downstream sees them.

What lands in your repo

At handoff you get runnable code, not a slide deck. For Direct that set is:

• An OpenAPI / Swagger description of the sync endpoints we map — login, customer list, per-customer entries, balances, report export.
• A protocol and auth-flow report covering the login, the bearer-token chain and its refresh, and the Telegram bot channel as a documented export.
• Runnable source in Python and Node.js for the key calls: authenticate, list customers, pull a customer's entries, read a balance, fetch a report.
• A normalization layer that turns Arabic-Indic numerals, RTL amounts and IQD figures into machine numbers, with the Arabic notes preserved in UTF-8.
• Automated tests run against a consenting test account, plus interface documentation an in-house team can maintain.
• Data-retention and consent guidance written to the Iraqi context below.

Consent and Iraq's data picture

Iraq has no single data-protection statute in force yet. Privacy rests on guarantees in the 2005 Constitution and scattered provisions in older law; a comprehensive Personal Data Protection Law was approved at cabinet level in 2019 but, as the data-protection trackers describe it, has not been enacted. So the dependable basis for this work is not a national data-rights regime — it is the merchant's own authorization over their own account and their own customers' records.

The financial-compliance backdrop is firmer. The Central Bank of Iraq issued Electronic Payment Services Regulation No. (2) of 2024, published in the Official Gazette on 29 April 2024 per the legal analyses we read, and the AML/CFT regime pushes long record-retention on licensed payment firms. A merchant ledger app is not itself a licensed payment provider, but that retention posture is the sensible reference point when we set how long synced records and consent logs should be kept. We minimize to the fields a job needs, log access, keep consent records, and work under an NDA where the merchant asks for one.

What we plan around in the build

A few specifics about Direct shape how the integration is engineered. We handle each of these inside the project.

Arabic, RTL and Arabic-Indic numerals

Amounts and notes arrive in Arabic. We normalize the ٠-٩ digits and right-to-left number formatting into plain integers, hold the free-text notes in UTF-8 throughout, and tag every figure as IQD so an external total reconciles against the app's.

Multiple stores under one login

The listing points to continuous use across devices and ongoing updates, and some merchants run more than one shop. Where that is the case we scope the sync per store so balances and customers from different shops never bleed into each other.

Frequent app updates moving the endpoints

Because Direct ships regular updates, its private sync shape can shift between releases. We add a check that flags when a response no longer matches what we mapped, and budget a short refresh into maintenance so a sync keeps working after an update lands.

Where teams plug a Direct sync in

The data tends to land in one of a few places:

• Accounting and ERP — folding a shop's receivables into the books so the debt ledger and the financial statements agree.
• Collections — turning aged balances and entry history into a prioritized follow-up queue instead of a manual scan.
• Credit and BNPL underwriting — reading a merchant's repayment behaviour from real entries before extending a line.
• Reporting dashboards — feeding the Telegram summaries, or the richer sync, into a single view across several shops.

Screens this brief was read against

The notes here were read against the app's own store screenshots. They are the merchant's view of the same ledger the sync carries.

Where these notes come from

Research ran in June 2026. We worked from the app's own Play Store description and screenshots for what it holds and how it surfaces it, and read Iraq's data and payments situation against legal and regulatory write-ups rather than guessing it. The specifics that matter — Iraq's lack of an in-force data-protection statute, the Central Bank's 2024 electronic-payment regulation, and AML record-retention — are drawn from the sources below.

• Iraqi News — analysis of the 2024 Electronic Payment Services regulation
• Al Tamimi & Company — new regulation on electronic payment services in Iraq
• DataGuidance — Iraq data protection overview
• Iraq Business News — the Central Bank's digital-payment transformation

Compiled at the OpenBanking Studio integration desk · reviewed June 2026.

Other shop-ledger apps in the same space

Direct sits in a crowded category of digital daftar and customer-credit books. Several hold the same shape of data, which is exactly why a single integration pattern carries across them.

• Debty — a debt-management app out of Mosul that records customer payments and remaining balances and lets a shopkeeper switch between stores.
• pDaftar — a digital debt ledger that drops the paper book and sends payment-date reminders over SMS and Telegram.
• Credit Debit (Udhaar Khata) — a shopkeeper credit book that tracks customer accounts and exports daily, weekly and monthly reports as PDF and Excel.
• Salaf سلف — an Arabic, right-to-left tracker for personal debts, loans and shared expenses.
• Debt Manager – Money Tracker — a multi-currency Arabic and English ledger for debts and daily transactions.
• Debt Manager (by Jazib Khan) — a cashbook-style ledger aimed at shopkeepers tracking sales, credits and loans.
• Debt Manager Pro — a debt tracker that shares financial reports over WhatsApp and email.
• Khatabook — a widely used digital khata that replaces the paper udhaar book for small merchants.

Questions integrators ask about Direct

Does Direct keep the debt records on a server, or only on the phone?

Its store listing describes electronic storage usable from any device, so the ledger lives server-side and syncs to each handset rather than sitting only on one phone. That is what lets us pull from the sync itself instead of scraping a screen.

Can the Telegram report feature double as an export channel?

Yes. Direct already pushes formatted debt reports to Telegram, so we can map that bot channel as a low-effort feed for the aggregate reports and pair it with the sync route when you need entry-level detail rather than summaries.

How do you handle Arabic text and Arabic-Indic numerals in the balances?

We normalize the ٠-٩ digits and right-to-left amount formatting into plain machine numbers, keep the Arabic notes in UTF-8 from end to end, and tag every figure as IQD so the totals reconcile against an external system.

What happens to the integration when Direct ships one of its frequent updates?

The private sync endpoints can shift between releases, so we add a check that flags when a response shape changes and refresh the client in a short maintenance pass. A sync does not silently break the next time the app updates.