Pulling installment and order data out of Tabby

Tabby splits a purchase into four monthly payments — or up to twelve — and every one of those plans, with its amounts, due dates and paid-down balance, lives behind the consumer login, per the app's description on Google Play. That ledger is the thing third parties actually want from Tabby. A lender running an affordability check, a personal-finance app showing upcoming bills, a debt-advice service tallying what a household owes across providers: all of them need the plan, not just the card debit that funded the last installment. This brief maps that data and the authorized way to read it.

The package id is app.tabby.client, per its Play Store listing. Tabby was founded in 2019 and is, by news coverage, the larger of the two GCC BNPL leaders; SAMA licensed its financing arm, Tabby Finance, to carry on BNPL activity in Saudi Arabia, and the Central Bank of the UAE granted it a wallet authorization. None of that changes the practical point: the plan-level records sit in Tabby's own backend and reach a third party through the user's authenticated session, so the integration is built on the consenting account, not on a bank statement.

What sits behind a Tabby login

These are the surfaces a consenting account exposes inside the app, named the way Tabby presents them.

Getting to the ledger

Two routes carry most of the value here, and they read different data — one is Tabby's own plan records, the other is the bank money behind them.

User-consented interface integration

The plan ledger, schedule, orders and card balance all come through the Tabby consumer interface, read under the account holder's consent. We analyze the app's own traffic — the login and token-refresh chain, then the plan and schedule calls — and turn the relevant ones into a clean, documented interface. Effort is moderate; the main durability cost is that a mobile front end changes, so the build includes a watch on the calls we depend on. Access is arranged with you during onboarding against a consenting test account; nothing about that is a hurdle you clear before we begin.

Licensed open-banking AIS for the funding account

SAMA's Open Banking Framework has account information services live in the Kingdom, and licensed aggregators such as Lean already connect Saudi banks. That route reaches the bank account a customer repays Tabby from — the debit, not the installment plan. It is standardized and durable, and we wire it in through a licensed third-party provider when a project needs the funding-account side alongside the Tabby ledger.

Native export

In-app export is thin; statements tend to come through support rather than a download. It works for a one-off pull but not for anything that has to stay current, so we treat it as a backstop.

For most briefs the consumer-interface route is the one we build first, because it is the only path that returns the installment schedule and outstanding balance that make Tabby data useful; the AIS connection is added when the funding flow has to be reconciled against it. Which combination you need depends on whether your product reasons about the plan, the money, or both — we settle that in the first call.

A repayment-schedule pull, sketched

Illustrative shape only — exact paths and field names are confirmed against live traffic during the build, not asserted here.

POST /auth/session            # exchange consented credential -> short-lived token
GET  /me/plans?status=active  # list open installment plans for the account

200 OK
{
  "plans": [
    {
      "plan_id": "pl_4f...",
      "merchant": "SHEIN",
      "principal": 480.00,
      "currency": "SAR",
      "installments_total": 4,
      "outstanding": 360.00,
      "schedule": [
        { "n": 1, "amount": 120.00, "due": "2026-05-20", "status": "paid" },
        { "n": 2, "amount": 120.00, "due": "2026-06-20", "status": "upcoming" },
        { "n": 3, "amount": 120.00, "due": "2026-07-20", "status": "upcoming" },
        { "n": 4, "amount": 120.00, "due": "2026-08-20", "status": "upcoming" }
      ]
    }
  ]
}

# error handling we build in:
#   401 -> refresh token via the documented refresh call, retry once
#   429 -> respect backoff, the app is rate-limited per session
#   plan with installments_total > 4 -> rescheduled / long plan, do not assume four

The delivered client normalizes amounts to minor units, carries the currency through (plans are in SAR, AED and other local currencies), and treats the schedule as mutable so a late or rebooked installment updates instead of staying frozen at checkout.

What lands at the end of the build

• An OpenAPI spec covering the plan, schedule, order-history and card-balance calls, with request and response field documentation.
• A protocol and auth-flow report: the login, token issuance and refresh chain as it actually behaves, including the rate-limit and retry rules above.
• Runnable source for the key endpoints in Python or Node.js — the client that produced the response shape shown above, with the normalization layer.
• Automated tests against the consenting test account, including the late-installment and long-plan cases.
• Interface documentation plus consent-handling and data-retention notes sized to SAMA and Central Bank of the UAE expectations.

SAMA, consent, and what the rules allow

Tabby's financing activity is licensed by SAMA in Saudi Arabia, and the Kingdom's Open Banking Framework — with account information services live since the 2022 release and payment initiation added in 2024 — sets the consent model for reading bank data through an aggregator. The Tabby plan ledger itself is read under the account holder's own authorization, which is the dependable basis for the whole integration: a consent the user grants and can revoke, scoped to the data the product needs. We keep consent records, log every read, minimize fields to what the use case justifies, and work under NDA where a client requires it. In the UAE the wallet falls under the Central Bank of the UAE, so consent and retention are scoped to whichever regulator covers the account being read.

Things this build has to get right

A few specifics about Tabby shape the work, and we account for each:

• Plans are not always four payments. The app advertises four monthly installments but also runs longer plans up to twelve, so we model installment count as a variable and never hard-code a quarter-by-quarter schedule.
• Markets diverge under different regulators. We key the integration on market — Saudi accounts under SAMA, UAE accounts under the Central Bank of the UAE — so consent scope and retention follow the right regime for each account rather than a single default.
• The schedule is a moving object. Status flips from upcoming to paid or late, and dates can shift on a reschedule, so we design the sync to re-read and diff rather than capture once.
• Currencies are local. Plans settle in SAR, AED and other GCC currencies; we carry currency through every record and normalize to minor units so totals across markets stay correct.

Cost and how the work runs

A Tabby integration usually ships as source you run yourself — priced from $300, and you pay only after delivery, once it does what you asked. The other option is a hosted endpoint: you call our API for Tabby plan and schedule data and pay per call, with nothing upfront. Either way the build runs in one to two weeks, and access to a consenting test account is set up with you as part of getting started. Tell us the app and what you need from its data and we will come back with the route and the deliverable — start at /contact.html.

Where integrators take this

• A lender pulls a consenting applicant's open Tabby plans and outstanding balance into an affordability decision, alongside the bank feed.
• A personal-finance app lists the user's next Tabby due dates next to their other bills, with reminders driven off the schedule status.
• A debt-advice or budgeting service aggregates BNPL liabilities across Tabby and its peers into one consolidated view of what a household owes.

Screens from the app

What was checked

This mapping was put together on 6 June 2026 from the app's own Play Store listing, SAMA's licensing notice for Tabby Finance, and the Kingdom's open-banking material on the framework's AIS and PIS releases, cross-read against current MENA BNPL market coverage. Sources opened:

• Tabby: Pay over time — Google Play listing
• SAMA — Tabby Finance BNPL licensing notice
• Open Banking in Saudi Arabia (SAMA framework portal)
• SAMA's second release of the Open Banking Framework

Mapped by the OpenBanking Studio integration desk · June 2026.

Other BNPL apps in the same data picture

The same plan-and-schedule pattern recurs across the region's pay-later apps, which is why a unified integration tends to span several. Each below is referenced for context only.

• Tamara — Saudi-rooted BNPL holding installment plans and order records much like Tabby's.
• Postpay — Dubai pay-later provider with per-user plans and merchant order history.
• Cashew Payments — UAE BNPL positioned against card debt, with installment schedules behind a login.
• Spotii — pay-later app across the UAE, Saudi Arabia and Bahrain, later under Zip and NymCard.
• Shahry — Egypt-focused BNPL with consumer credit and repayment records.
• Zoodpay — installment payments across several emerging markets, holding plan and order data.
• Rise — UAE financial app serving expatriate workers, with wallet and repayment surfaces.
• Payby — UAE wallet and payments app with stored balances and transaction history.

Questions integrators ask about Tabby

Does the plan data come from a bank feed or from Tabby's own backend?

The installment plans, due dates and order history are Tabby's own records and sit behind the consumer login — a bank feed only shows the debit that funds a repayment, not the plan that produced it. We read the plan ledger through the consenting account's app session, and pull the funding-account side separately through a licensed open-banking aggregator when a project needs both.

My users are split between Saudi Arabia and the UAE — does that change the build?

The app surfaces are the same, but oversight differs: SAMA licenses Tabby's financing activity in the Kingdom and the Central Bank of the UAE authorizes its wallet there. We scope consent records and data-retention to whichever regulator covers the account, and key the integration on market so a Saudi and an Emirati account are handled under the right rules.

Can you capture late and rescheduled installments, not just the original four payments?

Yes. The schedule carries a status per installment — paid, upcoming, or late — and a plan can run to twelve monthly payments rather than four, per the app's description. We model the schedule as a mutable object and re-read it, so a missed or rescheduled payment is reflected instead of frozen at checkout.

How current is the repayment data you return?

As fresh as the consenting session allows — we read on demand against the live account rather than a cached snapshot, so a payment made an hour ago shows as paid. Refresh cadence and the consent-renewal window are set with you during the build to match how often your product needs the numbers.