获取 Krung Thai 旗下 Paotang 超级 App 里的数据

一份 Paotang 安装包背后至少挂着六本各自独立的服务端账本：Paotang Pay 开放钱包、政府 G-Wallet、สบม. 储蓄债券钱包、公司债（หุ้นกู้）钱包、覆盖最多三个 Krungthai 银行账户的关联账户视图，以及一条 Krungthai 消费贷额度。正是这种铺开的结构让这款 App 值得对接，也正是它让粗暴的抓取毫无用处——每一本账本都有自己的状态、自己的标识符、自己的更新节奏。真正的工作在于：在通过一次授权会话把它们统统拉出来的同时，把它们彼此隔开。

结论很直接：第三方想从 Paotang 拿到的几乎一切，都藏在针对 Krung Thai 后端的已认证会话背后，而不在 App 导出的任何文件里。所以我们采用的路径，是在账户持有人授权下对该会话做合规协议分析，逐个钱包地梳理，并把泰国即将生效的开放数据规则按存款与支付类别逐步纳入进来。

每个钱包究竟存了什么

下表依据 App 在 Play 商店和 Krungthai 官网上的功能说明整理。这里的颗粒度是各界面向账户持有人展示的程度，也就是任何授权拉取所能达到的上限。

这里适用的对接路径

对会话进行合规协议分析

在你的授权下，我们对 Paotang 客户端与 Krung Thai 端点之间的流量进行观测，还原认证握手（设备绑定、令牌签发、刷新）以及各钱包的请求结构，并把它们重建为干净的调用。这条路径能覆盖上表中的每一个数据域，因为它工作在与 App 相同的层面。真正的工夫在设备绑定和令牌轮换上，而非数据调用本身。日常稳定性良好，App 更新后再做一轮重新校验即可。

在真实账户上的授权访问

对于单个自愿授权的账户持有人，对接在其已认证会话内运行，只拉取他们同意的那些钱包。这是 PDPA 下最干净的基础，也最适合快速搭起一个只覆盖一两个钱包的试点。

“Your Data” 下的受监管数据共享

泰国央行于 2025 年 10 月 30 日颁布的数据共享法规，覆盖存款、贷款和支付数据，含电子货币（e-Money）和信用卡。它从 2026 年底起分阶段落地，先是个人存款数据，随后在 2027—2028 年逐步扩大。随着 Paotang 的存款与支付类别进入适用范围，一次对接中的存款与 PromptPay 部分可以迁移到这一标准化通道上；投资和健康钱包则继续走授权访问。

如果你现在就要一个可用的实现，我们会以在授权账户上的合规协议分析作为主路径——它是当下唯一能触达全部六本账本的路径——待 Krung Thai 在 Your Data 上线后，再把存款与支付这一部分迁移到该通道。这样对接从设计上就合法，且面向未来兼容，无需坐等分阶段落地的时间表。

示例演练：钱包对账单拉取

以下是构建过程中确认的示意结构，并非从 Krung Thai 文档照搬。字段名由我方归一化；认证链条反映的是 Paotang 所用的那种设备绑定移动会话。

# 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

你会收到什么

交付物与你实际需要的钱包挂钩，而不是一个通用打包件：

• 一份 OpenAPI 规范，覆盖在范围内的钱包、转账、债券、公司债和贷款端点，并附归一化后的响应结构。
• 一份协议与认证流程报告：设备绑定和令牌刷新链条、各钱包的请求结构，以及上文提到的错误与限流行为。
• 可运行的源代码——Python 或 Node.js——针对你所选的端点，包含对账单分页器和各钱包归一化器。
• 针对录制夹具（fixtures）的自动化测试，外加一个面向授权账户的小型实盘冒烟测试。
• 接口文档，以及针对你所存储记录的、符合 PDPA 的数据留存指引。

授权，以及约束它的法律

这里牵涉两件事。其一是 PDPA，即泰国《个人数据保护法》，它把金融数据视为敏感个人数据，要求取得明确、有据可查、可撤回的同意——而且 PDPC 已经开始开出实打实的罚单，这绝非纸面功夫。我们的构建会按钱包分别记录同意范围，并支持撤回，撤回后即干净地停止采集。其二，泰国央行的 “Your Data” 规则是从 2026 年底起到位的标准化共享通道；在某一类别尚未在其上上线之前，可靠的依据是账户持有人本人的同意，而这正是我们授权访问路径的立足点。访问始终针对一个自愿授权的账户，全程留痕并做数据最小化，并在需要时置于保密协议（NDA）之下。

Paotang 特有的工程要点

有两件事我们会提前规划，因为它们决定对接能否保持正确：

• 钱包隔离。Paotang Pay 和 G-Wallet 在同一个 App 里是刻意分开的两个钱包，而投资类钱包（สบม.、หุ้นกู้）又是另外分开的。我们在入库时就给每条记录按来源钱包打标签，这样政府补助消费永远不会污染普通支付流，债券单位也不会被拿去和现金相抵。把这条边界弄错，是 Paotang 拉取悄无声息地出错的最常见原因。
• 设备绑定与会话刷新。该 App 使用带令牌轮换的设备绑定会话，因此我们围绕刷新窗口和重新绑定质询来设计同步，而不是每次运行都从头重新认证。访问方式——一个自愿授权的账户或一套赞助方测试环境——会在启动阶段与你商定好；构建就跑在那之上。
• 债券的单位级对账。储蓄债券以一泰铢为单位交易，二级市场活动全天候进行，因此我们在每次同步时都用单位数量与交易事件相互核对，以捕捉部分成交，而不是只信一次余额读数。

当 Krung Thai 改动 App 前端时，我们会针对录制夹具重跑校验，并修补受影响的调用——这类维护是保持对接存活的方式之一，而不是什么意外。

与我们合作

一个典型的 Paotang 构建，从我们敲定哪些钱包在范围内算起，通常耗时 1—2 周。可以 300 美元起买断源代码：你拿到可运行的 API 代码、规范、测试和文档，并且在交付后、验证可用后再付款。或者调用我们的托管端点，按次计费、无需预付，这适合起步阶段只需要钱包对账单或 PromptPay 转账数据的试点。把 App 和你关心的钱包告诉我们，其余交给我们处理——从这里开始沟通。

它会用在哪里

• 一款泰国记账工具，每晚把商户的 Paotang Pay 和 PromptPay 收款对账进其账本。
• 一个财富看板，把 สบม. 和公司债持仓拉进单一固定收益视图，含票息和预扣税字段。
• 一家放贷机构，在核保前拉取 Krungthai 贷款还款计划，以确认借款人已有的分期承诺。
• 一家福利项目运营方，把 G-Wallet 发放与 ถุงเงิน 商户核销相互对账。

界面佐证

取自商店页面的 App 截图。点击可放大。

泰国钱包体系中的同类应用

一次统一对接往往会触及的同类应用。此处仅作生态背景说明。

• TrueMoney Wallet — 泰国最大的独立电子钱包，承载储值、充值和商户支付。
• Rabbit LINE Pay — 内嵌于 LINE 的钱包，覆盖支付、公共交通和账单缴费。
• GrabPay — Grab 内的钱包，与出行、外卖和应用内消费绑定。
• ShopeePay — 附着于 Shopee 市场的钱包，承载余额和订单支付。
• K PLUS — Kasikornbank 的手机银行，含存款账户、转账和 PromptPay。
• SCB EASY — Siam Commercial Bank 的 App，承载账户、卡片和投资入口。
• Krungthai NEXT — Krung Thai 自家的零售银行 App，是 Paotang 的姊妹应用，含存款和转账数据。
• Tang Rath (ทางรัฐ) — 政府服务超级 App，呈现征信、社保和交通罚单记录。

本页是如何核对的

于 2026 年 6 月 25 日，依据 App 的商店和 Krungthai 官网信息以及泰国央行公开的开放数据资料整理；钱包结构取自 Paotang 自己的功能说明，监管时间线取自泰国央行的颁布公告。主要来源：

• Google Play 上的 Paotang（功能列表）
• Krung Thai — Paotang Pay
• 泰国央行颁布数据共享法规（2025 年 11 月）
• 泰国央行 — Open Data

2026 年 6 月 25 日由 OpenBanking Studio 集成团队审阅。

常见问题

你们能把 G-Wallet 里的政府补助活动和 Paotang Pay 钱包的日常消费区分开吗？

可以。Paotang Pay 与 G-Wallet 在同一个 App 里作为两个独立钱包运行，我们在构建中把它们保持在各自独立的规范化数据流里——Paotang Pay 承载开放钱包的 QR 与 PromptPay 流水，G-Wallet 承载国家补助权益和 ถุงเงิน 商户消费。每一条记录都按来源钱包打标签，因此补助报表永远不会和普通支付流混在一起。

Paotang 的哪些界面存放投资记录？颗粒度如何？

两个钱包。สบม. 储蓄债券钱包以一泰铢为单位记录政府债券持仓，并带有二级市场买入与卖出事件；公司债（หุ้นกู้）钱包记录企业债持仓，包含买入价、卖出价、票息和预扣税等字段。我们把两者都建模为持仓加交易台账，因此组合同步时能用单位数量与资金变动相互核对。

泰国的 “Your Data” 法规是否已经覆盖 Paotang 的数据？

还没有全面覆盖。泰国央行于 2025 年 10 月 30 日颁布了数据共享法规，但它从 2026 年底起分阶段落地，先从个人存款数据开始，并在 2027 年和 2028 年逐步扩展到其他类别。在某个钱包尚未进入该窗口之前，可依赖的基础是账户持有人本人的 PDPA 同意，我们从第一天起就围绕它来设计整个对接。

对于关联的多个 Krungthai 账户，你们如何处理其中的 PromptPay 转账？

根据 Paotang 自己的说明，它最多可关联三个 Krungthai 账户，并在其上呈现 PromptPay 转账、账单缴费和充值。我们把转账归一化到统一的数据结构，包含对手方 PromptPay ID、方向、金额和时间戳，并把每一条记录键接到发起的关联账户，从而保证多账户对账始终正确。