Reaching the data inside Krung Thai's Paotang super-app

One Paotang install carries at least six distinct server-side ledgers: the Paotang Pay open wallet, the government G-Wallet, the สบม. savings-bond wallet, the corporate-debenture (หุ้นกู้) wallet, a linked-account view over as many as three Krungthai bank accounts, and a Krungthai consumer-loan line. That spread is what makes the app interesting to integrate and also what makes a naive scrape useless — each ledger has its own state, its own identifiers, and its own update cadence. The work is keeping them apart while pulling them through one consented session.

The bottom line: nearly everything a third party would want from Paotang lives behind an authenticated session against Krung Thai's backends, not in any file the app exports. So the route we run is authorized protocol analysis of that session, mapped wallet by wallet, with Thailand's incoming open-data rule layered in for the deposit and payment categories as it reaches them.

What each wallet actually holds

Mapped from the app's own feature descriptions on the Play and Krungthai listings. Granularity below is what the screens expose to the account holder, which is the ceiling for any consented pull.

The routes that apply here

Authorized protocol analysis of the session

We instrument the Paotang client traffic against Krung Thai's endpoints under your authorization, recover the auth handshake (device binding, token issuance, refresh) and the per-wallet request shapes, and rebuild them as clean calls. This reaches every domain in the table above because it works at the same layer the app does. Effort sits in the device-binding and token rotation rather than the data calls. Durability is good day to day with a re-validation pass when the app updates.

Consented access on a live account

For a single consenting account holder, the integration runs inside their authenticated session and pulls only the wallets they agree to. This is the cleanest basis under PDPA and the fastest to stand up for a pilot covering one or two wallets.

Regulated data sharing under "Your Data"

The Bank of Thailand's data-sharing regulation, enacted 30 October 2025, covers deposit, loan and payment data including e-Money and credit cards. It phases in from late 2026 with personal deposit data first, then widens through 2027–2028. As Paotang's deposit and payment categories enter scope, the deposit and PromptPay parts of an integration can move onto that standardized channel; the investment and health wallets stay on consented access.

For a build you need now, we lead with authorized protocol analysis on a consented account — it is the only route that reaches all six ledgers today — and migrate the deposit-and-payment slice onto the Your Data channel once Krung Thai is live on it. That keeps the integration legal-by-design and forward-compatible without waiting on a phase-in timetable.

A worked example: wallet statement pull

Illustrative shapes confirmed during a build, not copied from Krung Thai documentation. Field names are normalized on our side; the auth chain reflects a device-bound mobile session of the kind Paotang uses.

# 1) Re-establish a device-bound session (token refresh, not a fresh login)
POST /paotang/auth/token/refresh
  headers: { x-device-id, x-app-ver, authorization: Bearer <refresh> }
  -> { access_token, expires_in, wallet_scope: ["pay","gwallet","sbm","debenture","loan"] }

# 2) Statement for one wallet, paged
GET /paotang/pay/statement?from=2026-05-01&to=2026-05-31&page=1
  headers: { authorization: Bearer <access_token> }
  -> { items: [ { txn_id, posted_at, direction, amount_thb,
                  counterparty_promptpay, channel: "QR|PROMPTPAY|BILL",
                  running_balance } ], next_page }

# normalize -> one row per movement, keyed by source wallet
def normalize(item, wallet):
    return {
      "wallet": wallet,            # keep pay / gwallet / sbm separate
      "id": item["txn_id"],
      "ts": item["posted_at"],
      "sign": +1 if item["direction"]=="IN" else -1,
      "amount": item["amount_thb"],
      "party": item.get("counterparty_promptpay"),
    }

# error handling that matters in practice:
#   401 -> token expired mid-page: refresh, resume from next_page
#   423 -> device re-bind required: re-run step 1 device challenge
#   429 -> backend throttle: exponential backoff, honour Retry-After

What you receive

Deliverables are tied to the wallets you actually want, not a generic bundle:

• An OpenAPI specification covering the wallet, transfer, bond, debenture and loan endpoints in scope, with the normalized response schemas.
• A protocol and auth-flow report: the device-binding and token-refresh chain, the per-wallet request shapes, and the error and throttle behaviour above.
• Runnable source — Python or Node.js — for the endpoints you pick, including the statement pager and the per-wallet normalizer.
• Automated tests against recorded fixtures, plus a small live smoke test for a consenting account.
• Interface documentation and PDPA-aligned data-retention guidance for the records you store.

Consent and the law that governs it

Two things are in play. PDPA, Thailand's Personal Data Protection Act, treats financial data as sensitive personal data that needs explicit, documented, withdrawable consent — and the PDPC has started issuing real fines, so this is not a paper exercise. The build records consent scope per wallet and supports withdrawal that stops collection cleanly. Separately, the BOT "Your Data" rule is the standardized sharing channel arriving from late 2026; until a category is live on it, the dependable basis is the account holder's own consent, which is exactly what our consented-access route is built on. Access happens against a consenting account, runs logged and data-minimized, and sits under an NDA where the engagement needs one.

Engineering notes specific to Paotang

Two things we plan for up front, because they decide whether the integration stays correct:

• Wallet isolation. Paotang Pay and G-Wallet are deliberately separate wallets in the same app, and the investment wallets (สบม., หุ้นกู้) are separate again. We tag every record by source wallet at ingestion so government-scheme spend never contaminates ordinary payment flow and bond units never get netted against cash. Getting this boundary wrong is the most common way a Paotang pull goes silently wrong.
• Device binding and session refresh. The app uses a device-bound session with token rotation, so we design the sync around the refresh window and the re-bind challenge rather than re-authenticating from scratch each run. Access — a consenting account or a sponsor test setup — is arranged with you during onboarding; the build runs against that.
• Unit-level bond reconciliation. Savings bonds trade in one-baht units with secondary-market activity 24/7, so we reconcile unit counts against trade events on every sync to catch partial fills, rather than trusting a single balance read.

When Krung Thai changes the app front end, we re-run the validation pass against the recorded fixtures and patch the affected calls — that maintenance is part of how the integration is kept alive, not a surprise.

Working with us

A typical Paotang build runs 1–2 weeks from the point we agree which wallets are in scope. Buy the source outright from $300: you get the runnable API code, the spec, the tests and the docs, and you pay after delivery once it works for you. Or call our hosted endpoints and pay per call with nothing upfront, which suits a pilot that only needs the wallet-statement or PromptPay-transfer feed at first. Tell us the app and the wallets you care about and we handle the rest — start the conversation here.

Where this gets used

• A Thai accounting tool reconciling a merchant's Paotang Pay and PromptPay receipts into its ledger nightly.
• A wealth dashboard pulling สบม. and debenture holdings into a single fixed-income view with coupon and withholding-tax fields.
• A lender pulling the Krungthai loan schedule to confirm a borrower's existing installment commitments before underwriting.
• A welfare-program operator reconciling G-Wallet disbursements against ถุงเงิน merchant redemptions.

Interface evidence

App screens, as published on the store listing. Tap to enlarge.

Peer apps in the Thai wallet stack

Same-category apps a unified integration tends to touch. Listed for ecosystem context only.

• TrueMoney Wallet — the largest standalone e-wallet in Thailand, holding stored value, top-ups and merchant payments.
• Rabbit LINE Pay — wallet inside LINE, covering payments, transit and bill pay.
• GrabPay — wallet within Grab, tied to transport, food delivery and in-app spend.
• ShopeePay — wallet attached to Shopee's marketplace, holding balances and order payments.
• K PLUS — Kasikornbank's mobile bank, with deposit accounts, transfers and PromptPay.
• SCB EASY — Siam Commercial Bank's app, holding accounts, cards and investment links.
• Krungthai NEXT — Krung Thai's own retail-banking app, a sibling to Paotang with deposit and transfer data.
• Tang Rath (ทางรัฐ) — the government services super-app, surfacing credit-bureau, social-security and traffic-fine records.

How this was checked

Mapped on 25 June 2026 from the app's store and Krungthai listings and the Bank of Thailand's published open-data materials; wallet structure taken from Paotang's own feature descriptions, the regulatory timeline from the BOT enactment notice. Primary sources:

• Paotang on Google Play (feature list)
• Krung Thai — Paotang Pay
• BOT enacts data-sharing regulation (Nov 2025)
• Bank of Thailand — Open Data

Reviewed 25 June 2026 by the OpenBanking Studio integration desk.

FAQ

Can you separate G-Wallet government-scheme activity from Paotang Pay wallet spend?

Yes. Paotang Pay and G-Wallet run as distinct wallets inside the one app, and the build keeps them in separate normalized streams — Paotang Pay carries the open-wallet QR and PromptPay traffic, G-Wallet carries the state-scheme entitlements and ถุงเงิน merchant spend. We tag each record by source wallet so subsidy reporting never mixes with ordinary payment flow.

Which Paotang surfaces hold investment records, and at what granularity?

Two wallets. The สบม. savings-bond wallet holds government bonds at one-baht unit granularity with secondary-market buy and sell events; the debenture (หุ้นกู้) wallet holds corporate-bond positions with purchase price, sale price, coupon and withholding-tax fields. We model both as holdings plus a trade ledger so a portfolio sync reconciles unit counts against cash movements.

Does Thailand's 'Your Data' regulation already cover Paotang's data?

Not yet across the board. The Bank of Thailand enacted the data-sharing regulation on 30 October 2025, but it phases in from late 2026 starting with personal deposit data and expands to other categories through 2027 and 2028. Until a given wallet falls inside that window, the working basis is the account holder's own PDPA consent, which we design the integration around from day one.

How do you treat PromptPay transfers across the linked Krungthai accounts?

Paotang links up to three Krungthai accounts, per its own description, and surfaces PromptPay transfers, bill payments and top-ups against them. We normalize transfers to a common schema with counterparty PromptPay ID, direction, amount and timestamp, and key each entry to the originating linked account so multi-account reconciliation stays correct.