对接 CardX 应用：电子账单、Dee Jung 与 SPEEDY 账目

2022 年 12 月 10 日，CardX 承接了此前隶属于泰国汇商银行（Siam Commercial Bank）的信用卡资产、SPEEDY CASH 现金卡以及 SPEEDY LOAN 个人贷款组合，这一切源自前一年宣布的 SCBX 集团重组。CardX 与 PingCAP 合作的 TiDB-on-AWS 案例研究提到，由此形成的核心系统可支撑 3—4 百万个信用卡账户的规模；而 th.co.cardx 这款安卓应用——连同泰国 App Store 列表中 id 为 1622961294 的 iOS 版本——正是这些客户如今查看账单、安排 Dee Jung 转换、查看 SPEEDY 账目的入口。

对合作方而言，问题很少在于 CardX 是否掌握某项数据，而在于：具体要接哪一部分、认证链（CardX、SCB EASY、经 ThaID 的 NDID）如何与合作方自身的认证配合，以及当信用卡阶段启动、进入泰国央行 Your Data 法规后，哪些内容还能延续下来。这些正是本页余下部分要逐一说清的，最后落到我们为一次 CardX 项目所交付的具体成果上。

CardX 登录背后的数据

下表每一行，都把已登录 CardX 客户所看到的一个功能面，对应到它在应用中的来源，以及对接方通常会拿它做什么。凡是 cardx.co.th 产品页或 App Store 列表使用了特定泰文术语的地方，功能面名称沿用 CardX 自己的标签。

有一点表格无法干净地表达：少量联名 SCB 信用卡仍在 SCB EASY 而非 CardX 中受理。CardX 应用的用户评价里提到了这一点；对接方案对此已有考虑（见下方实现要点）。

真正能触达这些数据的路径

有四条路径适用于 CardX。四条之中，我们通常先搭建路径 1；一旦泰国央行 Your Data 的信用卡阶段落地，路径 2 会作为入口被接上。

1. 基于 PDPA 的授权，进入应用的已认证功能面

客户依据泰国 PDPA 明确授权此次对接，用途与范围写入我们随对接一并保存的授权记录。随后，实现会读取与客户在应用中所见相同的电子账单、Dee Jung、SPEEDY 与 POINTX 功能面。工作量适中；只要授权定期刷新、应用版本得到跟踪，稳定性良好。接入准备——一个已授权的测试账户、我们用来测试的 CardX 应用版本，以及合作方的 PDPA 文书——会在第一周与你一同安排到位。

2. 泰国央行“Your Data”数据共享通道（前瞻性）

一旦 2025 年 10 月 30 日法规的信用卡阶段在 2027—2028 年的扩展期上线，同样这些数据点就可以通过受央行监管的数据共享接口来请求。我们今天就把内部接口设计好，让这一切换是传输层的改动，而非重写。这条路径对信用卡而言尚未生效，本文对此如实说明。

3. 经 SCB TechX 的 NDID Proxy 做 NDID 中介的重新认证

据 SCB TechX 自己的产品说明，CardX 的开户／eKYC 依托 SCB TechX 的 NDID Proxy 对接 ThaID。同一路径也是在客户更换设备时维持长期授权最干净的方式；对于用户频繁更换设备的合作方，我们会把它接进来。

4. 原生导出（电子账单 PDF）

CardX 会出具可由客户下载的每月电子账单。作为一条对接路径，它只是一个薄薄的兜底——适合一次性拉取某份账单，用于实时读取则偏弱。我们只在它确实值得的地方去解析，否则跳过。

针对账单接口的一个请求示例

下面这段伪调用仅作示意，确切结构会在实现过程中针对客户本人的已授权账户加以确认。凡是用户可见之处，字段名沿用 CardX 自身的功能面标签，因此你的服务写出的 JSON 读起来会与应用中一致。

POST /v1/cardx/statement.query
Headers:
  Authorization: Bearer <session_token>     # from the PDPA-consented auth flow
  X-Device-Fingerprint: <stable_install_id> # the app expects a per-install id
  X-CardX-App-Version: 2.14.2               # Android floor tested in this build
Body:
  {
    "card_token": "ctx_xxx",                 # opaque per consented card
    "from":  "2026-04-01",
    "to":    "2026-04-30",
    "include": ["transactions", "dee_jung_actions", "pointx_deltas"]
  }

Response (200, illustrative):
  {
    "card_token": "ctx_xxx",
    "currency":   "THB",
    "statement_cycle": { "closes": "2026-04-25", "due": "2026-05-10" },
    "available_credit": 84200.00,
    "transactions": [
      { "posted": "2026-04-03", "merchant": "BTS RABBIT",
        "amount": -320.00, "category": "transport" },
      { "posted": "2026-04-14", "merchant": "TOPS DAILY",
        "amount": -1480.50, "category": "groceries" }
    ],
    "dee_jung_actions": [
      { "type": "transfer", "amount": 15000.00,
        "tenor_months": 12, "effective_rate": 0.22,
        "destination_bank": "SCB", "booked_at": "2026-04-08T11:02:00+07:00" }
    ],
    "pointx_deltas": [
      { "date": "2026-04-12", "points":  850, "reason": "spend_accrual" },
      { "date": "2026-04-19", "points": -300, "reason": "redeem_cashback" }
    ]
  }

Failure modes worth handling explicitly:
  401  consent_expired       -> trigger NDID re-auth via SCB TechX proxy
  409  card_not_in_cardx     -> fall back to the SCB EASY adapter
  423  app_version_too_old   -> refresh the per-install fingerprint & retry

交付时落入你代码库的内容

一次 CardX 项目以一份可用的实现落在你的代码库里作为收尾。具体包括：

• 一份覆盖上述功能面的 OpenAPI 3 规范：/statement.query、/dee-jung/transfer.simulate、/dee-jung/installment.preview、/speedy-cash/draws、/speedy-loan/schedule、/pointx/balance、/pointx/redemptions，以及认证与刷新路由。
• 一份 协议与认证流程报告，走一遍与 SCB EASY 相邻的登录链、实现过程中观察到的会话刷新窗口，以及用于长期授权的、经 NDID 中介的重新认证交接。
• 针对最常被问到的接口——通常是电子账单拉取与 Dee Jung 模拟／落单这一对——提供 可运行的 Python 与 Node.js 源码，让你的团队在交付当天就能把它跑起来。
• 一套 契约测试套件（默认 pytest），会在你的环境里命中一个已授权账户，并配一份录制夹具回放，这样 CI 不必每次运行都做真实登录。
• 合规说明：PDPA 授权记录 schema、按范围跟踪的留存策略，以及一段简短说明，讲清当信用卡阶段推出时，如何把传输层切换到受央行监管的 Your Data 通道。

对接方在此之上做过的三件具体的事

合作方在提出 CardX 需求时，有几种形态反复出现。每一种都以上文同一套 OpenAPI 接口交付，范围收得很窄：

• 面向中小企业主的费用自动化。每天把信用卡电子账单拉进合作方的记账工具，保留 CardX 侧的归类，并把 Dee Jung Installment 落单拆成独立的会计科目行。
• 债务辅导看板。每周对 SPEEDY LOAN 摊还计划与 SPEEDY CASH 取现做一次快照，在第三方规划应用中呈现给客户，并按 CardX 公布的计息方式（余额递减的实际利率）测算提前还款场景。
• 积分聚合器。每晚读取 POINTX 余额与近期兑换，并与同一客户的 KTC FOREVER、Krungsri UCHOOSE 和 AEON 积分合并进同一个账本。

CardX 对接所处的泰国授权规则

今天，CardX 对接可靠的依据是客户基于 PDPA 的授权——用途明确、范围明确、可撤销。泰国《个人数据保护法》（B.E. 2562）自 2022 年 6 月 1 日起全面施行；据 2023 年 12 月 25 日的《政府公报》公布，PDPC 落实第 28 条与第 29 条的跨境传输通知已于 2024 年 3 月 24 日生效。执法早已不是纸面上的事：据 DLA Piper 2025 年的分析，PDPC 在 2024 至 2025 年间的公告里，多个公开案例的罚款金额落在 1500 万至 2100 万泰铢区间。

而路径真正拓宽之处，在于泰国央行的“Your Data”法规。据泰国央行自己的新闻稿，2025 年 10 月 30 日的这次出台，赋予消费者和企业一项权利，可在受央行监管的各服务方之间，共享受央行监管的金融数据——通过账户、电子货币和信用卡的存款、贷款与支付信息。分阶段上线从 2026 年底贯穿至 2027—2028 年，存款账户信息在先，信用卡信息在扩展期靠后。CardX 作为受央行监管的非银行信用卡运营方，处于这一监管边界之内。我们今天就把授权存储与内部接口设计好，让最终的切换是传输层的改动，而非重构架构。

以往 CardX 实现中的要点

有两条判断值得先讲清，因为它们对范围沟通的影响比其他任何因素都大。

我们把 CardX 对接按三个产品族分别界定范围。信用卡、SPEEDY CASH 现金卡和 SPEEDY LOAN 个人贷款共用一个应用，却不共用一个数据模型。三者之间，Dee Jung 选项、还款计划字段和 POINTX 可见性各不相同；一个把它们抹平的笼统“CardX”对接，会悄悄丢掉每一项各自有用的地方。我们在第一周就商定哪些产品族在范围内，并据此定价。

重新认证是围绕 SCB TechX 的 NDID Proxy 来设计，而非与之对抗。CardX 的开户／eKYC 本就走这条路径通往 ThaID，而它也是在设备更换时维持已授权会话最干净的方式。我们把合作方的重新认证接进同一条链，而不是另建一条平行的。已授权测试账户、我们锁定的 CardX 应用版本，以及合作方的 PDPA 文书，都会在接入阶段与你一同安排到位，好让实现命中真实的 CardX 数据，而不只是对数据的描述。

还有一个更小、却已绊倒过两次以往项目的点：CardX 更名后，仍有少量联名 SCB 信用卡留在 SCB EASY 而非 CardX 里。我们会把落入那个轻量 SCB EASY 适配器的卡片列成清单，作为设计说明的一部分，这样下游调用方无需知道某张卡具体落在哪个面上。

最后一点关于身份的事务性说明：cardx.com 那家美国的支付附加费公司，与由 SCBX 分拆而来的泰国 CardX 毫无关系。我们会在启动会上确认，我们对接的是 th.co.cardx——那个 SCBX 实体，而不是美国的同名者。

这一领域里其他的泰国卡片与消费金融应用

下面这份清单仅作背景参考：每一项都是真实存在、同类别的泰国应用，其持有方常被统一对接与 CardX 一并聚合。名称保持中性；合作方想接哪一个，我们就以同样的形态去做。

• KTC Mobile — 由 Krungthai Card PCL 发布；呈现 KTC 信用卡与 KTC PROUD 个人贷款。
• MAAI by KTC — 来自 Krungthai Card PCL 的配套忠诚度／积分应用。
• UCHOOSE — Krungsri Consumer；在同一登录下管理 Krungsri Credit Card、Krungsri First Choice、Krungsri Now 与 HomePro Visa。
• Krungsri First Choice — 通过 UCHOOSE 呈现的循环信用与个人贷款产品。
• AEON THAI MOBILE — AEON Thana Sinsap (Thailand) PCL；AEON 信用卡、Digital Your Cash、Happy Loan、车贷、保险。
• ttb touch — TMBThanachart 的手机银行应用，也是 ttb 信用卡与个人／车贷的主要渠道。
• UOB TMRW Thailand — 大华银行泰国的数字银行应用，含大华收购后原花旗泰国的消费金融组合。
• LINE BK — KASIKORN 与 LINE 的合资项目；在 LINE 内提供 Credit Line 与 Nano Credit Line 产品。
• Krungthai NEXT — 泰京银行的银行应用，覆盖 KTB 信用卡与个人贷款。
• K PLUS — 开泰银行的旗舰手机银行应用；KBank 信用卡功能面在此。

对接方签约前会问的问题

对接是端到端覆盖 Dee Jung Transfer（信用卡转现金），还是只覆盖电子账单视图？

两者都覆盖。交付内容既包含 Dee Jung 的模拟调用（金额、期数、实际利率）和落单调用，也包含电子账单交易流水以及 SPEEDY CASH 与 SPEEDY LOAN 的还款计划。Dee Jung Installment、Dee Jung 0% 和 Dee Jung Min Pay 由于可选期数和适用金额不同，会分别映射；在需求梳理阶段，我们会明确你实际需要哪些 Dee Jung 子项。

对接 CardX 做身份认证，与走 SCB EASY 相比有什么不同？

CardX 与 SCB EASY 共用一套上游身份体系——新 CardX 客户的 eKYC 由 SCB TechX 的 NDID Proxy 对接 ThaID 完成——但各产品面和会话处理并不相同。SCB EASY 的令牌无法直接在 CardX 的 SPEEDY LOAN 计划上发起交易，反之亦然。我们把它们当作同一内部接口后面的两个相邻端点来处理。

泰国央行“Your Data”规则上线后，会覆盖 CardX 的数据吗？

2025 年 10 月 30 日出台的法规在适用范围中明确点名了信用卡信息（通过账户、电子货币和信用卡的支付信息），并将从 2026 年底起分阶段上线，一直延续到 2027—2028 年。CardX 作为受泰国央行监管的非银行信用卡运营方，处于这一监管边界之内。我们今天的实现方式，使得信用卡阶段落地后切换到受央行监管的数据共享通道，只是同一 OpenAPI 接口背后的路由调整，而非推倒重建。

那些仍在 SCB EASY 而非 CardX 中管理的卡片怎么办？

少量联名 SCB 信用卡目前仍在 SCB EASY 而非 CardX 中受理。对接方案会同时覆盖两个端点——一个轻量的 SCB EASY 适配器位于同一内部接口之后，因此下游调用方无需知道某张卡具体落在哪个面上。落入该适配器的卡片清单会作为设计说明的一部分记录下来。

这些说明的来源

本简报的资料来源：CardX 的分拆时间线，与 SCBX 投资者关系页 及 2022 年 10 月至 12 月的泰国当时新闻做了交叉核对。数据功能面清单来自 cardx.co.th 产品页与 泰国 App Store 中 id 1622961294 的应用列表。3—4 百万个信用卡账户的规模数字来自 CardX 自己的 PingCAP 案例研究。泰国央行“Your Data”的状态、范围与分阶段安排来自 央行就 2025 年 10 月 30 日出台所发的新闻稿。由 OpenBanking Studio 对接团队于 2026 年 5 月 30 日审阅。

覆盖上述 CardX 功能面的源码交付 300 美元起，在实现能跑通你的账户、完成交付之后再付款——通常端到端一到两周。如果你不想自己托管任何东西，同样这些接口也提供按调用计费的托管 API，无前期费用。把应用名称和你想要什么，通过 /contact.html 发来，我们就为你界定范围。