所有接口共用一套錯誤結構。
{
"code": 400,
"error": "invalid_request",
"type": "invalid_request_error",
"message": "訂單金額必須是以最小貨幣單位表示的正整數",
"param": "amount",
"doc_url": "https://kukopay.com/docs/api/errors",
"request_id": "req_9f2c1a7b4e8d0356c1ab77de90f4b215"
}| 字段 | 説明 |
|---|---|
code | 與 HTTP 狀態碼一致 |
error | 穩定的機器可讀標識,請基於它做程序分支 |
type | 錯誤大類。新增 error 時不變,適合做粗粒度判斷 |
message | 給人看的描述,文案可能調整,不要用於邏輯分支 |
param | 出錯的請求字段名;與字段無關的錯誤為 null |
doc_url | 指向本頁對應錯誤碼的説明 |
request_id | 本次請求的唯一標識 |
request_id
每一個響應——無論成功還是失敗——都會在響應體的 request_id 字段和 X-Request-Id 響應頭中返回同一個值,它與平台側日誌一一對應。
請在你的 HTTP 客戶端裏統一把 request_id 記進訪問日誌。反饋問題時附上它,平台可以直接定位到那一次請求;沒有它只能靠訂單號和時間範圍人工翻查。你也可以自己用 API 日誌 查。
request_id 始終由平台簽發,不接受請求方傳入,所以兩次不同的調用一定拿到不同的值。
錯誤大類
| type | 含義 | 能否重試 |
|---|---|---|
authentication_error | 密鑰缺失或無效,請求沒有被識別為任何商戶 | 修正後 |
permission_error | 身份成立,但當前商戶無權執行該操作 | 否 |
invalid_request_error | 請求本身不合法:參數錯誤、對象不存在、狀態衝突 | 修正後 |
idempotency_error | 同一個冪等鍵被用於了不同的請求內容 | 修正後 |
rate_limit_error | 觸發調用頻率限制 | 退避後可以 |
api_connection_error | 上游渠道異常,本地資金未被修改 | 可以 |
api_error | 平台內部錯誤 | 可以 |
完整錯誤碼
| HTTP | error | 含義 | 建議 |
|---|---|---|---|
| 401 | missing_api_key | 缺少認證頭 | 檢查 X-Api-Key 拼寫與是否被代理層剝離 |
| 401 | invalid_api_key | 密鑰錯誤或已重置 | 更新服務端配置 |
| 403 | merchant_not_approved | 正式能力未開通 | 先用沙箱聯調並完成審核 |
| 403 | ip_not_allowed | 來源不在 IP 白名單 | 核對固定出口與白名單 |
| 403 | app_disabled | 密鑰所在的應用已停用,不能再創建訂單;已有訂單的查詢、退款與通知不受影響 | 在商戶後台「設置 → 應用管理」重新啓用該應用,或改用其他應用的密鑰 |
| 403 | forbidden | 該對象不屬於當前商戶 | 核對單號與密鑰歸屬 |
| 400 | invalid_request | 請求字段不合法 | 按 param 與 message 修正 |
| 400 | idempotency_error | 同一個 Idempotency-Key 用於了不同請求體 | 重試請原樣重發;新請求換 Key |
| 409 | idempotency_in_progress | 該 Key 的首次請求仍在處理中 | 稍後用相同的 Key 重試 |
| 404 | order_not_found | 訂單不存在、環境或應用不匹配 | 核對訂單號與密鑰的環境、應用 |
| 404 | refund_not_found | 退款不存在、環境或應用不匹配 | 核對退款號與密鑰的環境、應用 |
| 404 | dispute_not_found | 拒付記錄不存在、環境或應用不匹配 | 核對 dispute_no 與密鑰的環境、應用 |
| 404 | event_not_found | 事件不存在、環境或應用不匹配 | 核對事件 id 與密鑰的環境、應用 |
| 404 | payment_link_not_found | 收款鏈接不存在、環境或應用不匹配 | 核對 link_id 與密鑰的環境、應用 |
| 404 | endpoint_not_found | Webhook 端點不存在 | 核對 endpoint_id 與密鑰歸屬 |
| 404 | route_not_found | 請求地址不是任何 API 接口 | 核對地址與 HTTP 方法,接口都位於 https://api.kukopay.com/v1 之下 |
| 409 | conflict | 對象狀態已變化,訂單存在未結案拒付,或相同商戶訂單號對應的下單內容不同 | 查詢原訂單的最新狀態與拒付情況;新訂單請換新的商戶訂單號 |
| 400 | payment_limit_exceeded | 訂單金額超出該商戶的正式環境收款限額(單筆、近 24 小時或近 30 天) | 調整金額或分筆;需要提高限額請聯繫平台。見 收款限額 |
| 400 | refund_window_expired | 訂單的支付方式有退款期限且已超過 | 查看訂單的 refundable_until;超期退款請與買家線下處理 |
| 429 | rate_limited | 超出商戶調用配額 | 按 Retry-After 退避 |
| 502 | processor_error | 上游通道異常,本地資金未被修改 | 使用相同冪等鍵安全重試 |
| 500 | internal_error | 平台內部錯誤 | 帶相同冪等鍵重試;持續出現請附 request_id 聯繫我們 |
重試原則
- 網絡超時、
429、502和500:保留相同冪等鍵,指數退避後重試。 400、401、403:先修復參數、憑據或權限,不要原樣循環重試。404:確認資源標識與測試/正式環境是否一致。409:重新查詢訂單、退款或拒付的最新狀態,再決定下一步。
請求超時後不要直接判定訂單不存在並重新生成訂單號。正確做法是用原 out_trade_no 重試,或調用訂單查詢確認真實狀態。
調用頻率限制
商戶 API 按商戶賬戶限流(賬戶下所有應用共用配額),窗口為一分鐘:
| 類別 | 配額 | 覆蓋接口 |
|---|---|---|
| 寫 | 120 次 / 分鐘 | 下單、退款、創建鏈接與端點等會觸達上游的操作 |
| 讀 | 600 次 / 分鐘 | 各類查詢與列表 |
| 導出 | 10 次 / 分鐘 | 列表接口的 format=csv |
超出後返回 429 rate_limited,響應頭 Retry-After 給出距離窗口重置的秒數。按這個秒數退避即可,不必自己猜。
這個額度是給異常流量兜底的,不是計費口徑。正常業務量需要更高配額時聯繫平台運營調整即可。