Reaching a TrueMoney Wallet account: balance, history and the Pay Next loan ledger

Roughly 17 million Thai accounts run money through TrueMoney Wallet, by the figures quoted in independent e-wallet round-ups, and the same write-ups put it near a 53% share of the local wallet market. Every one of those accounts sits behind a PIN and an OTP, and behind that sits exactly the kind of state a third party wants to read: a current balance, a transaction history the app shows about three months deep, transfer records, and — for many users — a revolving or term loan account with its own statement dates. This page is about getting that account-level data out in a structured, repeatable way, under the account holder's authorization, and handing you working code to do it.

The dependable basis here is the consumer's own consent to share their data, exercised against a live account. The integration route follows from that: we map the app's authenticated traffic and rebuild it as a clean interface you can call. Below is what the account actually exposes, the routes in, what we hand over, and how the Thai regime shapes the design.

What a TrueMoney account exposes

These surfaces come from TrueMoney's own support material and store description, named the way the app names them where it can be checked.

Routes into the account

Three routes fit this app. They are not equal, and the recommendation sits at the end.

Authorized protocol analysis of the app session

We observe the traffic between the TrueMoney app and its backend on a consenting account, reconstruct the request and response shapes for balance, history and loan reads, and rebuild them as documented endpoints. Reach is wide: anything the app itself can show, the rebuilt interface can return. Effort is moderate and concentrated up front in mapping the auth handshake. Durability depends on the app's release cadence, which we account for in maintenance.

User-consented credential access

Where the account holder authorizes it directly, we drive the authenticated session on their behalf — PIN and OTP supplied by the user — and read the same surfaces through a controlled flow. This suits one-account or low-volume cases and keeps the consent trail explicit, with each pull tied to a recorded authorization.

Standardized data sharing under "Your Data"

The Bank of Thailand's Your Data programme is building a consent-based channel covering deposit, loan and payment data including e-Money, with sharing phased in from late 2026 per BOT's announcements. It is not callable today. We design the normalized schema so that when the standardized channel reaches wallet and e-Money data, the integration can move onto it without a rebuild on your side.

For a TrueMoney build today, protocol analysis on a consenting account is the route that returns real data now and covers every surface in the table above; the consented-credential flow is the right pick when volume is low and a single user's authorization is the whole job; the Your Data channel is the forward path we keep the schema aligned to. We would start on protocol analysis and fold in the standard as it becomes reachable.

What you receive

Each item is tied to a real TrueMoney surface, not a generic checklist.

• An OpenAPI 3 spec covering the account reads — balance, paged transaction history, transfers, loan account — with the Thai field labels and Baht formatting normalized to clean JSON.
• A protocol and auth-flow report documenting the PIN/OTP session handshake, the session token lifetime, device binding, and the refresh path, as confirmed during the build.
• Runnable source for the key endpoints in Python and Node.js, including paging logic that walks past the ~3-month visible window and accumulates a longer ledger.
• A normalized schema that separates the three loan products by servicer so Pay Next, Pay Next Extra and KKP Cash Now amortization never blend.
• Automated tests against recorded fixtures, plus interface documentation, plus data-retention and consent-logging guidance keyed to the PDPA.

The auth flow, in outline

Illustrative shape of a balance-and-history read after a consented session is established; exact field names are confirmed against live traffic during the build.

# illustrative — names verified during the engagement
session = tmn.open_session(
    msisdn="66xxxxxxxxx",      # Thai mobile, account identity
    pin=user_pin,              # supplied by the consenting holder
    otp=otp_from_sms,          # one-time, device-bound
)
# session yields a short-lived bearer token + device id

bal = session.get("/wallet/v?/balance")
# -> {"currency":"THB","available": ...,"asOf":"2026-06-24T..."}

# history pages ~3 months by default; we walk older pages
page = session.get("/wallet/v?/transactions",
                   params={"limit": 50, "cursor": None})
while page["cursor"]:
    for tx in page["items"]:
        normalize(tx)          # THB minor units, EN labels, PromptPay ref
    page = session.get("/wallet/v?/transactions",
                       params={"limit": 50, "cursor": page["cursor"]})

# loan accounts return per-product; do not merge servicers
loans = session.get("/lending/v?/accounts")
# -> [{"product":"PayNext","servicer":"AscendNano","apr": ...,
#      "nextDue":"...","installments":[...]}, ...]

# expired session -> 401; refresh once, then re-prompt OTP

Consent and the Thai regime

Two layers apply. The PDPA (Personal Data Protection Act B.E. 2562) has been in full force since June 2022 and sets the consent and data-controller rules; Section 19 requires the data subject's consent before personal data is collected or used, and the regulator issued its first sizeable fines in 2025, so the grace-period posture is over. Everything we build records consent explicitly, minimizes the fields pulled to what the use case needs, logs each access, and supports revocation. On top of that, the Bank of Thailand's Your Data project is standing up a national consent-based sharing standard for deposit, loan and payment data including e-Money — announced and now in regulation, with sharing phased from late 2026. We treat the account holder's authorization as the working basis today and keep the schema ready for that channel; NDAs are in place where the engagement needs them.

Build notes specific to this app

Things we handle as part of the work, not things you need to solve first.

• The History view only surfaces about three months. We schedule the sync to poll and append so the stored ledger outruns the app's on-screen window, and we de-duplicate on transaction id across pulls.
• The three lending products differ structurally — Ascend Nano's Pay Next pair are revolving credit with a 15th-of-month statement and 1st-of-month due date as the listing describes, while KKP Cash Now is a Kiatnakin Phatra term loan with a longer minimum. We model statement cycles and interest accrual per product.
• The session is OTP- and device-bound. We design around token expiry and re-prompt cleanly rather than letting a sync die silently; access is arranged with you during onboarding against a consenting account.
• Field labels and amounts arrive in Thai and in Baht conventions. The normalizer emits English keys and integer minor units so downstream code is locale-clean, and it carries PromptPay references through as first-class transfer fields.

Where this tends to land

• A lender or BNPL underwriter pulling a consenting applicant's TrueMoney cash-flow and existing Pay Next exposure for an affordability check.
• A personal-finance app folding wallet spend and top-ups into a single Thai-market budget view alongside bank accounts.
• An accounting tool reconciling 7-Eleven and Lotus's merchant payments against receipts for small-business users.
• A loyalty or rewards platform reading transfer and payment events to award points without manual entry.

Interface evidence

Store screenshots of the surfaces above; tap to enlarge.

How this was sourced

Checked in June 2026 against TrueMoney's support pages for the History and Identity Level surfaces, its Play Store description for the lending terms and product names, independent market round-ups for share and user figures, and Bank of Thailand material for the Your Data programme and PDPA timeline. Primary references:

• TrueMoney support — Transaction History
• Bank of Thailand — data-sharing right regulation (Nov 2025)
• Bank of Thailand — "Your Data" project
• DLA Piper — Thailand PDPA overview

OpenBanking Studio integration desk — mapping reviewed 2026-06-24.

Peer wallets in the same data picture

Builders integrating TrueMoney usually want neighbouring Thai wallets and banking apps under one schema. Named here for ecosystem context, not ranking.

• Rabbit LINE Pay — wallet inside LINE; transfers, stored value and rewards tied to a chat identity.
• K PLUS — Kasikorn Bank's app; bank balances, statements and QR payments for a large Thai user base.
• GrabPay — wallet within the Grab app; ride, delivery and merchant spend with a card link.
• ShopeePay — marketplace wallet; order-linked payments and refunds.
• Dolfin Wallet — Central-group wallet; retail spend, points and stored value.
• Paotang — Krungthai's app behind state schemes; wallet balance and government-payment records.
• Krungthai NEXT — Krungthai mobile banking; account balances, transfers and statements.
• DeepPocket — Thai e-money wallet; balance, top-ups and transfers.

Questions integrators ask

How far back does TrueMoney's transaction history actually go, and can you keep more?

The in-app History view exposes roughly the last three months of activity, per TrueMoney's own support documentation. We design the sync to poll on a schedule and accumulate records past that visible window, so your store keeps a longer ledger than the app shows on screen.

Can the three lending products be told apart in the data?

Yes. Pay Next and Pay Next Extra run through Ascend Nano while KKP Cash Now is a Kiatnakin Phatra Bank term loan, and each carries its own statement date, interest basis and installment schedule as described in the app listing. We model them as separate product types so balances, due dates and amortization are never mixed across servicers.

Which Thai data-sharing regime governs a TrueMoney integration?

Two things apply. The PDPA (B.E. 2562) sets the consent and data-controller obligations today, in force since June 2022. The Bank of Thailand's Your Data project adds a consent-based sharing standard for deposit, loan and payment data including e-Money, with rollout phased from late 2026. We build on the account holder's own authorization now and keep the design ready for the standardized channel as it lands.

Does the PromptPay QR side matter for reading wallet data?

PromptPay is the Bank of Thailand interbank rail TrueMoney rides for QR pay-in and transfers, so transfer records carry PromptPay references worth normalizing. It is a payment scheme, not the data source itself; the account ledger is what we read, and PromptPay identifiers become fields in the normalized transfer schema.

One last practical note on getting it built. You give us the app name and what you need out of it; we arrange access and the compliance footing with you and do the mapping. Source-code delivery starts at $300 — you receive runnable endpoints, the spec, tests and documentation, and you pay after delivery once it works for you. Prefer not to host anything? Use the pay-per-call hosted API instead: call our endpoints, pay only for the calls you make, nothing up front. Either way the cycle is one to two weeks. Tell us the surfaces you want and we will scope it — start a TrueMoney integration here.