The merchant ledger behind ถุงเงิน, made integrable

Every payment a shop takes through ถุงเงิน — G-Wallet inside the เป๋าตัง app, a state welfare card, or a PromptPay QR — lands as a timestamped receipt with an instant push notification, per Krungthai's own description of the app. That is the surface worth integrating: a per-merchant stream of receipts, tagged by funding channel, rolled up into daily and monthly totals a back office can reconcile against its books.

What ถุงเงิน records, receipt by receipt

The app names its own surfaces in the merchant flow. The mapping below is how we'd model them for an integration.

Authorized routes into the merchant ledger

Three routes apply to this app. They differ in reach, in how long they stay stable, and in what we set up to run them.

1 · Authorized interface integration of the merchant account

With a merchant who runs the ถุงเงิน account, we map the login and token flow and the calls that return the transaction list and the summaries, then build a clean client over them. Reach is the full set of surfaces above. Onboarding here is a step we handle with you: access is arranged against a consenting account during the build, under NDA where you want one. This is the route we'd lead with, because it reaches the receipt-level detail today and does not wait on a regulatory timeline.

2 · BOT Open Data, as it phases in

The Bank of Thailand is standing up a right-to-share-data regime covering deposits, loans and payment services. It starts with personal deposit data and widens over the years that follow, per the BOT's published plan. For merchant payment data this is forward-looking rather than live, so we treat it as the channel to migrate toward — durable and regulator-backed once it covers this data class — and design the first build so that swap is cheap.

3 · PromptPay-side confirmation

Where a sale runs over a PromptPay QR, the national rail carries its own confirmation. For merchants who also receive into a bank account directly, this gives a second, independent view of the same payment that we can cross-check settlement against. Narrow on its own, useful as a reconciliation backstop next to route 1.

What lands in your repo

The deliverable is a working integration for ถุงเงิน's surfaces, not a report about them. Concretely:

• An OpenAPI/Swagger spec describing the transaction-list, daily-summary, monthly-summary and merchant-profile endpoints as we modelled them.
• A protocol and auth-flow report: the login, token issuance and refresh chain as observed during the build, with the headers and session handling each call needs.
• Runnable source for the key calls in Python or Node.js — authenticate, page through receipts, pull a daily or monthly roll-up, normalize the channel and scheme tags.
• Automated tests against captured responses, including the co-pay split case and an empty-day case.
• Interface documentation, plus data-retention and consent-logging guidance written for PDPA.

A settlement query, sketched

Illustrative shape of the receipt-pull, confirmed against live responses during the build rather than copied from any published contract:

POST /merchant/auth/token        # session from the merchant's credentials
  -> { access_token, refresh_token, expires_in }

GET /merchant/txns?date=2026-06-26&page=1
  Authorization: Bearer <access_token>
  -> {
       "items": [
         { "ref": "TN26062600118",
           "amount": 120.00,
           "channel": "G_WALLET",        # or WELFARE_CARD | PROMPTPAY_QR
           "scheme": "KHON_LA_KHRUENG",  # null on an ordinary sale
           "subsidy": 60.00,             # state share, present on co-pay
           "customer_paid": 60.00,
           "ts": "2026-06-26T11:42:08+07:00",
           "status": "PAID" }
       ],
       "page": 1, "has_more": true
     }

# normalize: one row per receipt; sum(subsidy) reconciles to expected disbursement.
# 401 -> refresh token; 429 -> back off; re-validate map if field shape shifts.

Where integrators put this

• A multi-branch retailer pulling each shop's daily total into one dashboard instead of reading six phones at close.
• An accounting tool that needs the คนละครึ่ง subsidy share booked separately from the customer share for tax.
• A franchise back office reconciling ถุงเงิน receipts against the Krungthai settlement deposit, flagging any gap.
• A loyalty layer that reacts to a paid receipt notification in near real time.

Consent, the BOT Open Data path, and PDPA

The data belongs to the merchant, and their authorization over their own account is what the integration runs on. Thailand's Personal Data Protection Act sets how that consent is handled: it must be explicit and granular, the merchant can withdraw it, and we keep consent records and access logs accordingly, with cross-border transfer rules in mind since the PDPA's transfer regime took effect. Access is data-minimized — we pull the fields an integration needs and no more. The Bank of Thailand's Open Data framework is the regulated channel this migrates onto as it reaches merchant payment data; until then it is the forward path, not the present basis, and the page does not pretend otherwise.

Things we plan around for ถุงเงิน

A few specifics shape the build, all of them ours to handle:

• Government co-pay receipts are not single-amount sales. We model the subsidy and customer shares as separate fields so a คนละครึ่ง transaction reconciles against the expected state disbursement instead of looking like a discount.
• Three funding channels share one receipt list. We carry the channel tag through normalization so G-Wallet, welfare-card and PromptPay takings stay separable downstream, which matters for how each settles.
• Timestamps are local. Receipts are stamped in Thai time (UTC+07:00); we keep the offset explicit so daily roll-ups close on the merchant's day boundary, not a server's.
• App releases move the surfaces. We version the interface map and keep a re-validation step in maintenance so a Krungthai update is caught and patched rather than silently breaking a sync.

Access to a consenting account and any compliance paperwork are arranged with you during onboarding; the build runs against that account, so none of this is a hurdle you clear before we start.

Screens we worked from

How this read was put together

Checked in June 2026: the app's own merchant description for its channels, notifications and sales views; the Play listing for the package identifier; the Bank of Thailand's Open Data programme for the regulated timeline; and DLA Piper's Thailand summary for the PDPA consent and cross-border points. Sources opened:

• ถุงเงิน on Google Play (com.ktb.merchant.tungngern)
• Bank of Thailand — Open Data
• DLA Piper — Thailand data protection (PDPA)
• Mae Manee Shop on Google Play (category reference)

OpenBanking Studio integration desk · mapping reviewed 2026-06-26.

The Thai merchant-payment neighbourhood

Other apps a Thai merchant or aggregator runs alongside ถุงเงิน, named for keyword reach and for the shape of a unified integration — no ranking implied.

• เป๋าตัง (Paotang) — the consumer wallet that pays into ถุงเงิน via G-Wallet; holds the customer side of the same scheme transactions.
• Mae Manee (แม่มณี) — SCB's merchant app; QR receipts and payment notifications for shops.
• Krungsri Mung-Mee Shop — Krungsri's merchant collection app for individual businesses.
• K PLUS Shop — Kasikornbank's merchant-side companion to K PLUS for accepting QR payments.
• Bangkok Bank Mobile Banking — QR acceptance and merchant transfers for Bualuang customers.
• TrueMoney Wallet — a widely used e-wallet that settles QR payments to merchants.
• ShopeePay — wallet payments tied to marketplace and in-store QR.
• LINE Pay — wallet-based QR payments used by Thai merchants.
• Krungthai NEXT — Krungthai's retail banking app, often the settlement destination behind ถุงเงิน.

Questions integrators ask about ถุงเงิน

Can the daily and monthly sales summaries be pulled separately from individual receipts?

Yes. The app shows today's transactions, a per-day roll-up, and a monthly total as distinct surfaces, so we expose them as separate endpoints: a transaction list keyed by receipt, and pre-aggregated daily and monthly summaries. An integrator can pull only the rolled-up figures for accounting, or the raw receipts for reconciliation, without fetching both.

How do you tell a คนละครึ่ง co-pay apart from a normal PromptPay sale in the data?

Each receipt carries the funding channel: G-Wallet from เป๋าตัง, a state welfare card, or a PromptPay QR. Government co-pay schemes such as คนละครึ่ง settle through G-Wallet and split the amount into a subsidy share and a customer share, so we model a channel field plus, where present, the scheme tag and the two amount components rather than a single total.

Does the BOT Open Data timeline cover merchant settlement, or only personal deposits?

The Bank of Thailand's Open Data work begins with personal deposit data and expands to loans and payment services over the following years, per its published plan. Merchant settlement is not the first tranche, so for now the dependable basis is the merchant's own authorization over their account, with the regulated channel folded in as it opens.

What happens to a running integration when ถุงเงิน updates its app?

App releases can change the token flow or the shape of the transaction-list response. We version the interface map and keep a re-validation step in maintenance, so when Krungthai ships an update the integration is re-checked against the live responses and patched before it drifts.

So the engagement is short and the money follows delivery. For a fixed scope you get the runnable source, spec, tests and docs above for a one-off fee from $300, paid only after we deliver and you are satisfied; if you would rather not host anything, we run the integration and you pay per call with nothing up front. Either way the build cycle is one to two weeks. Tell us it's ถุงเงิน and what you want out of it, and we arrange access and compliance from there — start at /contact.html.