让 ถุงเงิน 背后的商户流水可对接

按 Krungthai 自己对这款应用的说明，商家通过 ถุงเงิน 收到的每一笔款项——无论是 เป๋าตัง 应用里的 G-Wallet、政府福利卡，还是 PromptPay 二维码——都会落成一张带时间戳的收款记录，并即时推送通知。真正值得对接的正是这个界面：一条按商户划分、按资金渠道打标的收款记录流，汇总成后台可以拿去对账的每日和每月总额。

ถุงเงิน 逐笔记录了什么

应用在商户流程中给自己的各个界面都起了名字。下面这张表是我们为对接对它们所做的建模。

进入商户流水的授权路径

这款应用适用三条路径。它们在覆盖范围、稳定持续时间，以及为运行所要搭建的东西上各不相同。

1 · 对商户账户做授权接口对接

与一位运营 ถุงเงิน 账户的商户合作，我们梳理登录与令牌流程、以及返回交易列表和各类汇总的调用，然后在其上构建一个干净的客户端。覆盖范围就是上面那整套界面。这里的开通我们会与你一起完成：在开发过程中针对一个已授权的账户安排访问权限，你需要时可签保密协议。这是我们会优先采用的路径，因为它今天就能触达到收款记录级别的细节，且不必等待监管的时间表。

2 · BOT Open Data，随其分阶段推进

泰国央行正在搭建一套涵盖存款、贷款和支付服务的数据共享权制度。按其公布的计划，它从个人存款数据起步，并在随后几年逐步扩大。就商户收款数据而言，这是面向未来而非当下可用，所以我们把它当作要迁移过去的渠道——一旦覆盖这一数据类别，它就稳定且有监管背书——并且在第一版就把这种切换的成本设计得很低。

3 · PromptPay 一侧的核对

当一笔销售走 PromptPay 二维码时，这条国家清算网络自身会携带核对信息。对于同时直接收款到银行账户的商户，这就为同一笔付款提供了第二个独立视角，我们可以据此交叉核对结算。它单独看范围较窄，但作为路径 1 之外的对账兜底很有用。

会进到你代码库里的东西

交付的是一套针对 ถุงเงิน 各界面、可运行的对接，而不是一份关于它们的报告。具体来说：

• 一份 OpenAPI/Swagger 规范，描述我们建模后的交易列表、每日汇总、每月汇总和商户资料等接口。
• 一份协议与鉴权流程报告：开发期间观察到的登录、令牌签发与刷新链路，以及每个调用所需的请求头和会话处理方式。
• 关键调用的可运行源代码，Python 或 Node.js 版——鉴权、翻页取收款记录、拉取每日或每月汇总、规整渠道与计划标签。
• 针对已抓取返回的自动化测试，包括共付拆分场景和空白日场景。
• 接口文档，外加为 PDPA 撰写的数据留存与授权日志指引。

一段结算查询示意

这是取收款记录的示意形态，在开发期间对照实时返回核实过，而非照抄任何公开的接口契约：

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.

对接方会把它用在哪里

• 一家多门店零售商，把每家店的每日总额拉进同一个看板，而不必在收档时挨个翻看六部手机。
• 一款记账工具，需要把 คนละครึ่ง 的补贴份额与顾客份额分开入账，以备税务。
• 一个连锁后台，把 ถุงเงิน 的收款记录与 Krungthai 的结算入账对上，标出任何缺口。
• 一个会员积分层，对已付款的收款通知近乎实时地作出响应。

授权、BOT Open Data 路径与 PDPA

数据属于商户，整个对接靠的正是他们对自己账户的授权。泰国《个人数据保护法》（PDPA）规定了这份授权同意的处理方式：它必须是明确且颗粒化的，商户可以撤回，我们也据此保存授权记录和访问日志；由于 PDPA 的跨境传输制度已经生效，我们还会把跨境传输规则纳入考量。访问遵循数据最小化——只取对接所需的字段，绝不多取。泰国央行的 Open Data 框架是这套对接日后迁移落地的受监管渠道，待其覆盖到商户收款数据；在此之前它只是前进方向，而非当下依据，本页也不会假装相反。

为 ถุงเงิน 需要提前考虑的事

有几处具体细节会影响这次开发，且都由我们来处理：

• 政府共付收款不是单一金额的销售。我们把补贴份额和顾客份额建模为各自独立的字段，好让一笔 คนละครึ่ง 交易能与应拨付的国家补贴对上，而不是看起来像一笔折扣。
• 三种资金渠道共用一份收款列表。我们在规整过程中一路带着渠道标签，让 G-Wallet、福利卡和 PromptPay 的收款在下游仍可区分——这对各自如何结算很重要。
• 时间戳是本地时区。收款记录以泰国时间（UTC+07:00）打戳；我们把这个偏移显式保留，好让每日汇总按商户的一天为界收档，而不是按服务器的。
• 应用发版会挪动这些界面。我们对接口映射做版本管理，并在运维中保留一道重新校验的步骤，让 Krungthai 的更新被及时捕捉并修补，而不是悄无声息地把某次同步弄坏。

对已授权账户的访问以及任何合规文书都在开通阶段与你一起安排；开发针对那个账户进行，所以这些都不是你在我们动工前需要先跨过的门槛。

我们据以工作的界面

这份解读是怎么拼起来的

2026 年 6 月核对：应用自己对渠道、通知和销售视图的商户端说明；用于确认包名的 Play 商店页面；泰国央行的 Open Data 计划，用于查证受监管的时间表；以及 DLA Piper 的泰国概览，用于 PDPA 的授权同意与跨境要点。查阅过的来源：

• ถุงเงิน 在 Google Play（com.ktb.merchant.tungngern）
• 泰国央行 —— Open Data
• DLA Piper —— 泰国数据保护（PDPA）
• Mae Manee Shop 在 Google Play（同类参考）

OpenBanking Studio 对接组 · 映射审阅于 2026-06-26。

泰国商户收款的周边生态

泰国商户或聚合方常与 ถุงเงิน 一同使用的其他应用，列在这里既为关键词覆盖，也为呈现一套统一对接的样貌——不含任何排名之意。

• เป๋าตัง（Paotang）—— 通过 G-Wallet 向 ถุงเงิน 付款的消费者钱包；持有同一批计划交易的顾客侧。
• Mae Manee（แม่มณี）—— SCB 的商户应用；为门店提供二维码收款记录和付款通知。
• Krungsri Mung-Mee Shop —— Krungsri 面向个体经营的商户收款应用。
• K PLUS Shop —— Kasikornbank 与 K PLUS 配套的商户端应用，用于接受二维码付款。
• Bangkok Bank Mobile Banking —— 面向 Bualuang 客户的二维码收款与商户转账。
• TrueMoney Wallet —— 一款使用广泛的电子钱包，将二维码付款结算给商户。
• ShopeePay —— 与市场平台和门店二维码绑定的钱包支付。
• LINE Pay —— 泰国商户常用的基于钱包的二维码支付。
• Krungthai NEXT —— Krungthai 的零售银行应用，常是 ถุงเงิน 背后的结算到账处。

对接方常问 ถุงเงิน 的那些问题

每日和每月的销售汇总能不能和单张收款记录分开取？

可以。应用把当日交易、按天汇总和当月总额分别呈现为不同的界面，因此我们也把它们做成各自独立的接口：一个以收款记录为主键的交易列表，以及预先聚合好的每日、每月汇总。对接方可以只取汇总数字用于记账，也可以只取原始收款记录用于对账，不必两者都拉。

在数据里怎么把 คนละครึ่ง 的政府补贴支付和普通 PromptPay 收款区分开？

每张收款记录都带有资金渠道：来自 เป๋าตัง 的 G-Wallet、政府福利卡，或 PromptPay 二维码。像 คนละครึ่ง 这类政府共付计划通过 G-Wallet 结算，会把金额拆成补贴部分和顾客自付部分，所以我们建模时会有一个渠道字段，并在存在时附上计划标签和两笔金额分量，而不是只记一个总额。

BOT Open Data 的时间表涵盖商户结算数据，还是只有个人存款？

按泰国央行公布的计划，其 Open Data 工作从个人存款数据起步，随后几年才逐步扩展到贷款和支付服务。商户结算并不在第一批范围内，所以目前可靠的依据仍是商户对自己账户的授权，待受监管的渠道开放后再纳入进来。

当 ถุงเงิน 更新应用时，正在运行的对接会怎样？

应用发版可能改动令牌流程或交易列表返回的结构。我们会为接口映射做版本管理，并在运维中保留一道重新校验的步骤，这样 Krungthai 一发布更新，我们就会对照实时返回重新核对，并在对接出现偏差前完成修补。

所以这次合作周期短，且付款跟在交付之后。固定范围下，你拿到的是上面那套可运行源代码、规范、测试和文档，一次性费用起价 300 美元，只在我们交付且你满意后才付；如果你宁可什么都不自己托管，就由我们来运行这套对接，你按调用次数付费，先期零投入。无论哪种方式，开发周期都是一到两周。告诉我们是 ถุงเงิน、以及你想从中拿到什么，访问权限和合规就由我们从那里安排起——从 /contact.html 开始。