Pulling wallet and SPayLater records out of ShopeePay

Inside ShopeePay sits a financed-purchase ledger most wallets do not carry: SPayLater records each buy-now-pay-later commitment with a personalized credit limit, an outstanding balance, due dates, and a repayment plan running three, six, nine, or twelve months. That ledger sits next to a normal wallet feed — balance, top-ups, QR payments, bill payments, mobile reloads. Two account-bound data stores, one login. An integrator who wants ShopeePay activity reflected in their own books needs both, kept apart.

The app serves the Thai market, where it reads as the country's third-most-used wallet behind TrueMoney and Rabbit LINE Pay (per 2026 fintech coverage). The package id is com.beeasy.airpay per its Play listing — a reminder that ShopeePay shares plumbing with the wider Sea/SeaMoney stack rather than running as a standalone codebase. That shapes how the session and the data read.

Bottom line: a vendor feed is not the lever here, and Thailand's open-data work has not yet opened wallets to licensed third parties. What works dependably is the account holder's own consent, with the integration built by analyzing the authorized session and modelling what the app already shows that user. The wallet feed and the SPayLater ledger are both reachable that way.

What ShopeePay holds, surface by surface

Rows reflect what the app describes and what its support material confirms a user can open — full transaction history, upcoming SPayLater payments, and the credit limit that ShopeePay personalizes from a user's own repayment record. We map the real fields during the build; the table is the shape, not a guess at every key name.

Where integrators put this

• A Thai merchant aggregator pulling each customer's consented ShopeePay payment history into one reconciliation dashboard alongside bank lines.
• A lender or scoring service reading a consenting applicant's SPayLater limit, outstanding balance, and on-time repayment pattern as an affordability signal.
• A personal-finance app that wants wallet spend categorized next to a user's bank and card data, refreshed daily.
• An accounting tool exporting QR-payment references so a small business can close its books without manual entry.

Routes to the data

Authorized interface analysis (the one we'd run)

We work against a consenting account, observe the authenticated traffic the app uses to render the wallet feed and the SPayLater tab, and rebuild those calls as a clean, documented client. Reachable: everything the user can see in-app. Effort is moderate; the session model is the bulk of it. Durability is good once the auth chain is mapped, with a maintenance pass when the front end shifts. We arrange the consenting test account and access during onboarding, with you.

User-consented credential access

For a product where the end user is in the loop, the integration carries the user's own login and reads only their data under recorded PDPA consent. Reachable: the same surfaces, scoped to that user. This is the cleaner fit when ShopeePay records belong to your customers rather than to you.

Native in-app history as a fallback

ShopeePay lets a user view full transaction history and SPayLater schedules in the app. Where a one-off pull is enough, capturing that view is a low-effort fallback — thinner than a live client, but useful for a migration or an audit snapshot.

For most ShopeePay work we'd build on the first route and fold in user consent when the data belongs to your users. The native view is a backstop, not the thing you run every day. The reason is durability: a mapped session keeps a daily reconciliation alive, a screen capture does not.

How a read looks

Illustrative — field names are confirmed against the live session during the build, not asserted here:

POST /wallet/v2/transaction/list      # authorized session, device-bound
Authorization: Bearer <session_token>   # derived from the Shopee/SeaMoney login chain
{
  "cursor": null,
  "limit": 50,
  "include": ["spaylater"]
}

# response (shape, abbreviated)
{
  "balance": { "available": 1840.50, "currency": "THB" },
  "items": [
    { "id": "txn_8842", "ts": 1718870400, "type": "qr_pay",
      "amount": -129.00, "merchant": "7-Eleven", "ref": "PP-...ISO20022" },
    { "id": "spl_2207", "ts": 1718611200, "type": "spaylater",
      "principal": 3600.00, "plan_months": 6, "due_next": "2026-07-05",
      "outstanding": 3000.00, "limit": 12000.00 }
  ],
  "next_cursor": "eyJ..."
}

# handle: token refresh on 401, OTP/device step on new-device,
# and tag spaylater rows so BNPL never merges into wallet spend

What lands at the end

• An OpenAPI/Swagger spec for the wallet-feed and SPayLater reads, with the field set we confirmed.
• A protocol and auth-flow report: the session token chain off the Shopee/SeaMoney login, device binding, OTP step, and token refresh.
• Runnable source for the key endpoints in Python or Node.js — transaction list, balance, SPayLater state — with paging and error handling.
• Automated tests covering the auth refresh and the SPayLater-vs-wallet tagging.
• Interface documentation plus data-retention and consent-record guidance shaped to the PDPA.

Consent and the PDPA

Thailand's Personal Data Protection Act (B.E. 2562), in full force since 1 June 2022 and overseen by the PDPC, is the regime that governs this. Its consent rules read close to the GDPR: consent must be explicit, the purpose disclosed, and withdrawal kept easy. We build to that — consent captured and logged, scope limited to the agreed data domains, an expiry and revocation path so a withdrawn consent stops the sync, and data minimization so we read the wallet and SPayLater fields the use case needs and nothing more. The Bank of Thailand is the relevant financial regulator and opened open-data consultations in 2024, but a licensed third-party-provider route for non-bank wallets is not yet available, which is why consent — not a mandated feed — is the dependable basis. We work under NDA where the engagement calls for it, and keep access records.

Engineering notes we account for

Two things about ShopeePay specifically shape the build, and we handle both:

• The SPayLater credit limit moves. It is personalized from a user's transaction and repayment record, so a one-time read goes stale. We capture limit, outstanding, and plan state at read time and re-fetch on a schedule, so a credit or exposure view reflects the current number rather than last month's.
• The session is not standalone. Because the wallet rides the Shopee/SeaMoney account, the auth is a token chain with device binding and an OTP step on new devices. We map that chain and handle the refresh and device step inside the consenting-account flow, set up with you during onboarding.
• PromptPay payloads are ISO 20022. QR and SPayLater-via-PromptPay payments carry standardized reference fields; we normalize them into one reconciliation key so ShopeePay lines match bank statements.
• Account eligibility is Thai-resident. ShopeePay tightened foreign-user access in early 2025 (per fintech coverage), so we scope test and consenting accounts as Thai-resident during onboarding rather than discovering the limit mid-build.

Interface evidence

Screens from the listing, for reference. Tap to enlarge.

Sources and method

Checked in June 2026: ShopeePay's Play and App Store listings for the SPayLater feature set and stated package, support material describing the in-app transaction history and credit-limit personalization, the Bank of Thailand's open-data status, and the PDPC's PDPA consent framework. Primary references:

• ShopeePay App Store listing (TH)
• Bank of Thailand open-banking status
• Thailand PDPA overview (DLA Piper)
• Thailand e-wallet market overview (2026)

ShopeePay mapping by the OpenBanking Studio integration desk · June 2026.

Similar wallets in the same data picture

Teams integrating ShopeePay usually want the same view across Thailand's other wallets and banking apps. Each holds comparable account-bound data a unified integration can normalize:

• TrueMoney Wallet — the market-leading wallet; balances, transfers, top-ups, plus savings and small-loan records.
• Rabbit LINE Pay — payments inside LINE, with transit, points, and merchant payment history.
• K PLUS — Kasikornbank's app; full account statements, transfers, and PromptPay activity.
• mPay — AIS's wallet; bill payments, top-ups, and QR transactions.
• Krungthai Paotang — government-linked wallet; state payouts, wallet balance, and transaction records.
• SCB Easy — Siam Commercial Bank; balances, statements, and transfer history.
• Dolfin Wallet — wallet with payments, BNPL, and spend history.
• Bangkok Bank Mobile Banking — account balances, statements, and QR-payment records.
• Krungsri KMA — Bank of Ayudhya's app; balances, transfers, and statement data.

Questions integrators ask

Can SPayLater installment records be separated from ordinary wallet spend in the extract?

Yes. SPayLater lives in its own surface inside the app, with credit limit, outstanding balance, due dates and the 3-, 6-, 9- or 12-month plan attached to each financed purchase. We model it as a distinct ledger and tag each row with a plan id, so BNPL obligations never get mixed into wallet payment lines.

How do PromptPay QR payments appear once the data is pulled?

Scan-to-pay and SPayLater-via-PromptPay flows carry the ISO 20022 reference fields Thailand's rail uses. We normalize those into a stable payment-reference column so a finance team can reconcile a ShopeePay line against the corresponding bank statement entry.

Does Thailand's open data work cover a wallet like ShopeePay yet?

The Bank of Thailand opened open-data consultations in 2024 and is still drafting consumer-permissioned access standards; a full third-party-provider ecosystem is not in place for non-bank wallets. So the dependable basis is the account holder's own PDPA consent, with the integration built around authorized interface analysis rather than a mandated feed.

Our reconciliation runs daily — can a ShopeePay sync match that without breaking on app updates?

Yes. We schedule the read against the wallet activity feed and SPayLater state, and wire a validation step that flags structural drift when the app front end changes, so a daily reconciliation keeps running instead of failing silently.

Most ShopeePay builds finish inside one to two weeks. Source-code delivery starts at $300 — runnable API source plus documentation, billed only after we hand it over and you have confirmed it works; the hosted alternative charges per API call with nothing paid upfront. Give us the app and what you need from its data, and we arrange access and the consent setup with you: start a project.