API Enhancements
Card Dispute Fields Now ExposedCard account and transaction payloads now surface dispute information so cobranders can display dispute state to cardholders and react to dispute lifecycle events.What’s New
CardAccount.disputeAmount — a number field on every card account response.- The total amount currently under dispute, denominated in the card account currency.
- Returns
0when there is no disputed amount.
CardAccountTransaction.disputeStatus — a nullable string field on every card account transaction.- Possible values:
requested,pending,success,failed,reported, ornull(not disputed).
Webhook Behavior
Thecardaccount.transaction.updated webhook now also fires when a transaction’s dispute status changes (previously fired only on transaction status transitions such as pending → posted). The webhook payload’s data.disputeStatus carries the latest value.Example Response — GET /cardaccounts/transactions?cardAccountId=...
Example Response — GET /cardaccounts
Action Suggested
- If your UI surfaces card account balances, consider showing
disputeAmountalongsidebalance/outstandingso users see funds locked in dispute review. - If you subscribe to
cardaccount.transaction.updated, branch ondata.disputeStatusto react to dispute lifecycle (e.g. notify the user when a dispute completes).
API 增強
新增卡片爭議資料欄位卡賬戶與交易回應現已提供爭議資訊,方便聯名銀行向持卡人展示爭議狀態並對爭議生命週期事件作出回應。新增內容
CardAccount.disputeAmount — 每個卡賬戶回應中的 number 欄位。- 以卡賬戶幣種計算的目前爭議中總金額。
- 沒有爭議金額時返回
0。
CardAccountTransaction.disputeStatus — 每筆卡賬戶交易上的可為 null 的 string 欄位。- 可能的值:
requested、pending、success、failed、reported,或null(非爭議)。
Webhook 行為
cardaccount.transaction.updated Webhook 現在也會在交易爭議狀態變更時觸發(過去僅在交易狀態轉換如 pending → posted 時觸發)。Webhook 載荷中的 data.disputeStatus 會帶有最新值。響應範例 — GET /cardaccounts/transactions?cardAccountId=...
響應範例 — GET /cardaccounts
建議行動
- 如果您的介面顯示卡賬戶餘額,請考慮在
balance/outstanding旁邊顯示disputeAmount,以便使用者看到因爭議審核而鎖定的金額。 - 如果您已訂閱
cardaccount.transaction.updated,請根據data.disputeStatus進行分支處理,以對爭議生命週期作出回應(例如在爭議完成時通知使用者)。
Important Update
Card Endpoints: Business Errors Now Return HTTP 400Seven card endpoints have been fixed so that known business-state errors now returnHTTP 400 Bad Request with a typed code field, instead of HTTP 500. Genuine upstream/system failures continue to return HTTP 500. This change is live in production.Affected Endpoints and Error Codes
| Endpoint | Business errors now returned as 400 |
|---|---|
POST /cards/change-pin | INACTIVE_CARD, CARD_NOT_ISSUED, CARD_NUMBER_MISMATCH |
POST /cards/activate | UNPENDING_CARD, CARD_NUMBER_MISMATCH, CARD_EXPIRY_MISMATCH |
POST /cards/lock | CARD_ALREADY_LOCKED, INACTIVE_CARD, CARD_NUMBER_MISMATCH |
POST /cards/unlock | ERROR_UNLOCK_CARD_STATUS_INVALID, CARD_NUMBER_MISMATCH |
POST /cards/suspend | CARD_ALREADY_SUSPENDED, INACTIVE_CARD, CARD_NUMBER_MISMATCH |
POST /cards/unsuspend | UNSUSPENDED_CARD, CARD_NUMBER_MISMATCH |
POST /cards/cancel | CARD_ALREADY_CANCELLED |
HTTP 500 with a generic error body.Action Required
- Before: business errors such as
CARD_ALREADY_LOCKEDleaked through asHTTP 500. - After: the same errors return
HTTP 400with a structured body containing the errorcode— branch oncode, not on the HTTP status alone.
Example Response (After)
Recommended Client Handling
Branch on the HTTP status, not on individualcode values. Use body.code for user-facing messages or telemetry — not for retry decisions.code values is in the table above — useful when mapping each code to a localized user message in your UI.📚 API Reference: Cards →重要更新
卡片端點:業務錯誤現在返回 HTTP 400七個卡片端點已修正,已知的業務狀態錯誤現在會返回HTTP 400 Bad Request,並附帶具類型的 code 欄位,而不再返回 HTTP 500。真正的上游或系統錯誤仍會返回 HTTP 500。此變更已於生產環境上線。受影響的端點與錯誤碼
| 端點 | 現在以 400 返回的業務錯誤 |
|---|---|
POST /cards/change-pin | INACTIVE_CARD、CARD_NOT_ISSUED、CARD_NUMBER_MISMATCH |
POST /cards/activate | UNPENDING_CARD、CARD_NUMBER_MISMATCH、CARD_EXPIRY_MISMATCH |
POST /cards/lock | CARD_ALREADY_LOCKED、INACTIVE_CARD、CARD_NUMBER_MISMATCH |
POST /cards/unlock | ERROR_UNLOCK_CARD_STATUS_INVALID、CARD_NUMBER_MISMATCH |
POST /cards/suspend | CARD_ALREADY_SUSPENDED、INACTIVE_CARD、CARD_NUMBER_MISMATCH |
POST /cards/unsuspend | UNSUSPENDED_CARD、CARD_NUMBER_MISMATCH |
POST /cards/cancel | CARD_ALREADY_CANCELLED |
HTTP 500 配合通用錯誤主體返回。需要採取的行動
- 修正前:例如
CARD_ALREADY_LOCKED之類的業務錯誤會以HTTP 500形式返回。 - 修正後:相同錯誤會以
HTTP 400返回,並在響應主體中包含結構化的code欄位 — 請根據code進行分支處理,而非僅依賴 HTTP 狀態碼。
響應範例(修正後)
建議的客戶端處理方式
請以 HTTP 狀態碼作為分支判斷依據,而非個別的code 值。body.code 應用於使用者訊息或紀錄分析 — 而非作為重試判斷的依據。400 code 值清單見上方表格 — 在介面上將每個 code 映射為本地化的使用者訊息時可派上用場。📚 API 參考:卡片 →API Enhancements
New KYC Rejection Reason for CardsAdded a new detailed rejection reason for card KYC review:Supporting Document Rejections (Non-HK Residents):Additional Doc for Non-HK Resident (hotel info invalid)- The hotel information provided in the supporting document is invalid
rejectedReason field when the KYC status is rejected.📚 API Reference: Get Client Identity →新增卡片 KYC 拒絕原因新增一項卡片 KYC 審核的詳細拒絕原因:證明文件拒絕(非香港居民):
Additional Doc for Non-HK Resident (hotel info invalid)- 證明文件中提供的酒店資料無效
status 為 rejected 時,此拒絕原因會在 rejectedReason 欄位中返回。📚 API 參考:取得客戶身份資訊 →API Enhancements
New KYC Rejection Reasons for CardsAdded three new detailed rejection reasons for card KYC review:ID Document Rejections:Invalid ID (name check hit)- The cardholder’s name triggered a name screening checkInvalid ID (exceed the company's risk appetite)- The application exceeds the company’s risk appetite threshold
Additional Doc for Non-HK Resident (missing id back photo)- The back photo of the ID document is missing
rejectedReason field when the KYC status is rejected.📚 API Reference: Get Client Identity →新增卡片 KYC 拒絕原因新增三項卡片 KYC 審核的詳細拒絕原因:身份證件拒絕:
Invalid ID (name check hit)- 持卡人姓名觸發了姓名篩查Invalid ID (exceed the company's risk appetite)- 申請超出公司風險承受範圍
Additional Doc for Non-HK Resident (missing id back photo)- 缺少身份證件背面照片
status 為 rejected 時,這些拒絕原因會在 rejectedReason 欄位中返回。📚 API 參考:取得客戶身份資訊 →API Enhancements
Enhanced Transaction Intent DescriptionsTheintent field on transactions and the intent query parameter on the List Transactions endpoint now include detailed descriptions for all supported values:charge- Card purchase or payment authorizationrefund- Reversal or refund of a previous chargetopup- Funds loaded into the card accountwithdraw- Funds withdrawn (e.g. ATM or cash advance)repay- Repayment towards outstanding balancecashback- Cashback reward credited to the accountinterest- Interest accrued on outstanding balancetransfer- Balance transfer between card accountsfee- Service fees (e.g. annual fee, late payment fee)other- Uncategorized transaction types
intent query filter now also accepts an array of values for filtering by multiple intent types.📚 API Reference: List Transactions →New KYC Rejection ReasonAdded a new rejection reason for address verification during KYC review:
Incomplete Info (not residential address)- The address provided is not a valid residential address
rejectedReason field when the KYC status is rejected.📚 API Reference: Get Client Identity →交易意圖說明增強交易的
intent 欄位及列出交易端點的 intent 查詢參數現已包含所有支援值的詳細說明:charge- 卡片消費或支付授權refund- 退款或撤銷先前的消費topup- 資金存入卡賬戶withdraw- 資金提取(如 ATM 或現金預借)repay- 償還未清餘額cashback- 現金回饋獎勵interest- 未清餘額的利息transfer- 卡賬戶之間的餘額轉帳fee- 服務費用(如年費、逾期還款費)other- 未分類的交易類型
intent 查詢篩選器現在也支援數組值,可同時按多種意圖類型進行篩選。📚 API 參考:列出交易 →新增 KYC 拒絕原因新增一項用於地址驗證的 KYC 審核拒絕原因:
Incomplete Info (not residential address)- 提供的地址不是有效的住宅地址
status 為 rejected 時,此拒絕原因會在 rejectedReason 欄位中返回。📚 API 參考:取得客戶身份資訊 →New Features
Sandbox Simulation for Client Identity VerificationProgrammatically simulate the approval or rejection of Client Identity (KYC) verification for card accounts in the Sandbox environment. This allows you to test your webhook handlers and downstream flows immediately without waiting for manual intervention.What’s New:
A new endpointPOST /cardaccounts/simulate-client-identity-status is now available in the Sandbox environment.Usage:
Send a request with thecardAccountId and the desired action (approve or reject).Example Request:
ClientIdentityApproved, ClientIdentityRejected) as a real manual review, ensuring your integration is fully tested against production-like behavior.📚 API Reference: Simulate Client Identity Status →客戶身份驗證沙盒模擬在沙盒環境中以程式方式模擬卡賬戶客戶身份(KYC)驗證的批准或拒絕。這使您能夠在無需運營團隊手動干預的情況下,即時測試您的 Webhook 處理程序和下游流程。
新增內容:
沙盒環境中新增了端點POST /cardaccounts/simulate-client-identity-status。使用方法:
發送包含cardAccountId 和所需 action(approve [批准] 或 reject [拒絕])的請求。請求範例:
ClientIdentityApproved、ClientIdentityRejected),確保您的集成測試與生產行為一致。📚 API 參考:模擬客戶身份狀態 →API Enhancements
Enhanced KYC Rejection Reasons for Supporting DocumentsAdded five new detailed rejection reasons specifically for supporting documents submitted by non-Hong Kong residents. These new rejection codes provide clearer feedback when supporting documents are rejected during KYC review:Additional Doc for Non-HK Resident (document type not accepted)- The submitted document type is not acceptedAdditional Doc for Non-HK Resident (expired document)- The submitted document has expiredAdditional Doc for Non-HK Resident (unclear image)- The document image quality is insufficientAdditional Doc for Non-HK Resident (document not belong to client)- The document does not belong to the applicantAdditional Doc for Non-HK Resident (potential bogus document)- The document appears to be fraudulent
rejectedReason field when the KYC status is rejected.📚 API Reference: Get Client Identity →Important Update
Travel Permit Document Submission UpdateEffective Date: February 1, 2026, 00:00 HKT
What’s Changing:
The previous document typeTRAVEL_PERMIT has been replaced with two new document types:TRAVEL_PERMIT_FRONT- Front side of the permitTRAVEL_PERMIT_BACK- Back side of the permit
Example Submission:
往來港澳通行證文件提交要求更新
生效日期: 2026年2月1日,香港時間 00:00
變更內容:
先前的文件類型TRAVEL_PERMIT 已被替換為兩個新的文件類型:TRAVEL_PERMIT_FRONT- 通行證正面TRAVEL_PERMIT_BACK- 通行證背面
提交範例:
Important Updates
New Mandatory KYC Requirements for Individual CardholdersEffective Date: February 1, 2026, 00:00 HKT
occupation- Select from/v1/occupationsendpointposition- Select from/v1/positionsendpointgender- MALE or FEMALEnationality- ISO 3166-1 alpha-2 format (e.g., HK)supportingDocuments- Required for non-Hong Kong (HK) nationals (see accepted document types →)
個人持卡人強制性 KYC 要求更新
生效日期: 2026年2月1日,香港時間 00:00
occupation(職業)- 從/v1/occupations端點選擇position(職位)- 從/v1/positions端點選擇gender(性別)- MALE 或 FEMALEnationality(國籍)- ISO 3166-1 alpha-2 格式(例如:HK)supportingDocuments(證明文件)- 非香港 (HK) 國籍申請人必須提供(查看可接受的文件類型 →)
New Features
New 3D Secure (3DS) Challenge Flow for Online TransactionsEnhanced security for online transactions with the new 3DS challenge flow, providing a more secure and streamlined verification experience.📖 View 3D Secure Integration Guide →Go-Live Date: December 19, 2025, 00:00 HKT
⚠️ Deprecated Webhook:
cardaccount.transaction.verification-code-delivered - This webhook has been replaced by the new 3DS challenge flow. Please migrate to the new integration.New Features
Webhook Auto-Recovery MechanismNew automatic recovery system for suspended webhooks to reduce manual intervention and prevent webhook accumulation:- Auto-Recovery: Suspended webhooks are automatically pinged every 5 minutes for up to 24 hours
- Automatic Resumption: If a ping succeeds, webhook delivery resumes automatically without manual intervention
- Auto-Deletion: Webhooks are automatically deleted if they remain suspended with failed recovery pings for 24 consecutive hours
Go-Live Date: November 29, 2025, 00:00 HKT

