方便開發人員使用的 API
Cardflo 的 API 在設計時充分考慮了開發人員的需求，優先考慮易用性、全面的文件和強大的功能。 這確保了流暢的整合過程，讓您的團隊能夠快速部署和管理支付解決方案。
專注於創新，而非整合挑戰。
- 類別
- 開發者
- 功能數
- 10
- 適用於
- 所有方案
概覽
方便開發人員使用的 API 是商戶數字基礎設施與更廣泛支付生態系統之間的主要接口。 在 B2B 領域，這意味著提供 RESTful 端點，允許以編程方式執行授權、捕獲和退款。
該架構必須考慮無卡交易所需的複雜數據結構，包括 3DS 元數據和 Level 2 或 Level 3 採購詳細信息。 有效的 API 設計優先考慮冪等請求以防止重複交易，並利用標準 HTTP 狀態代碼來傳達請求的狀態。
除了簡單的支付處理之外，這些接口還促進了循環計費計劃的管理、代幣化憑證的保管以及結算報告的檢索。 通過在 API 層級直接整合，企業可以完全控制結帳體驗，同時將敏感數據處理委託給符合 PCI-DSS 的環境。
這種結構化方法減少了技術債務，並確保後端系統與收單機構的賬本保持同步。
運作方式
身份驗證和憑證安全
整合從使用通過 TLS 傳輸的密鑰或 OAuth 令牌驗證請求開始。 開發人員配置 Webhook 以接收事件的異步通知，例如成功結算或爭議發起。
這確保了商戶的內部數據庫與每筆交易的狀態保持一致，而無需不斷輪詢伺服器。
請求構建和驗證
開發人員構建包含交易金額、貨幣代碼和支付工具詳細信息的 JSON 負載。 API 在嘗試授權之前根據架構要求驗證這些輸入。
如果缺少強制字段（例如 CVV 或賬戶持有人姓名）或針對特定 MCC 格式不正確，則會立即返回詳細的驗證錯誤。
冪等性和彈性測試
為了處理網絡不穩定，API 採用冪等性鍵。 如果由於超時而重試請求，系統會識別唯一鍵並返回原始響應，而不是創建重複收費。
此邏輯通常在沙盒環境中使用各種場景的模擬響應代碼進行驗證。
響應處理和錯誤映射
收到發卡機構的響應後，API 會將複雜的銀行響應代碼映射到標準化、可操作的類別。
開發人員使用這些分類代碼來觸發特定工作流程，例如在硬拒絕後提示用戶使用不同的支付方式，或在軟拒絕後發起 3DS 挑戰。
為何重要
減少整合延遲
結構良好、文件齊全且具有原生 SDK 的 API 允許工程團隊在更短的時間內從初始配置轉移到功能沙盒。 通過為每個端點和字段提供清晰的定義，最大程度地減少了來回支持查詢的需求。
這種效率確保了支付邏輯可以與核心產品功能一起部署，而不會成為更廣泛開發生命週期的瓶頸。
操作穩定性和調試
詳細的日誌記錄和透明的錯誤消息對於在生產環境中保持高正常運行時間至關重要。 當 API 提供有關交易失敗原因的詳細反饋時，例如特定的 BIN 相關限制或 SCA 要求，開發人員可以自動化適當的響應。
這減少了財務和支持團隊的手動開銷，否則他們需要通過收單機構門戶調查模糊的拒絕原因。
可擴展的支付架構
隨著企業擴展到新市場或採用新的商業模式，靈活的 API 允許添加替代支付方式和多幣種支持，而無需重寫整個整合。 客戶、訂閱和支付方法的標準化對象允許開發人員構建模塊化系統，這些系統可以適應不斷變化的監管要求（如 PSD3）或 Visa 和 Mastercard 不斷發展的方案規則。
應用案例
SaaS 訂閱擴展
SaaS 公司的技術團隊使用 API 自動化複雜的催收週期和訂閱升級。 對保管庫的編程訪問允許客戶更改層級時無縫地進行計費轉移。
市場支付自動化
市場平台整合 API 以在供應商之間拆分支付並實時計算佣金。 這確保了經過 KYB 驗證的子商戶根據其特定的合同條款收到結算。
自定義移動結帳
移動開發人員使用特定的 SDK 來構建自定義結帳流程，以原生觸發 3DS 身份驗證。 這保持了品牌一致性，同時確保敏感卡數據永遠不會接觸商戶自己的伺服器。
ERP 系統同步
大型企業將其 ERP 系統直接連接到支付 API，以自動化銀行對賬。 交易元數據用於在收到結算通知後自動結清未結發票。
數據概覽
工程團隊在從傳統 SOAP 接口切換到具有全面 SDK 的現代 RESTful API 時報告的典型效率提升。
網關每個請求的行業標準基準開銷，不包括卡網絡和發卡銀行引入的下游延遲。
在網絡重試常見的高流量環境中，防止重複交易的觀察到的可靠性率。
Talk to our team about a live rollout on your acquiring stack.
為您帶來 方便開發人員使用的 API
- 全面的 RESTful 架構，提供可預測的資源導向 URL 和標準 HTTP 方法使用。
- 適用於 Python、Node.js 和 Java 的原生 SDK，可加速伺服器端整合和維護。
- 獨立的沙盒環境，用於嚴格測試邊緣案例，而不會影響實時財務數據。
- 精細的 Webhook 通知，用於實時更新退單、退款和成功結算事件。
- 冪等性標頭支援，以防止在間歇性網絡連接失敗期間重複交易。
- 廣泛的文件，包含代碼範例、字段描述和互動式 API 探索工具。
- 標準化的錯誤對象，包含特定代碼和人類可讀的消息，以便快速故障排除。
- 版本化的 API 發布，以確保向後兼容性並控制遷移到新功能。
- 符合 PCI 標準的代幣化端點，以最大程度地減少年度安全審計和評估的範圍。
- 支援自定義元數據字段，以便於與內部商業智能工具進行對賬。
A short scoping call, then a written plan for your MIDs.
關於 方便開發人員使用的 API
API 如何處理 PSD2 下的強客戶身份驗證 (SCA) 要求？
API 旨在通過在授權請求中包含特定標誌來支援 3-D Secure 協議。 當交易需要身份驗證時，API 會返回一個響應，表明需要挑戰。
然後，開發人員將用戶重定向到發卡機構的身份驗證頁面，或使用 SDK 在應用程式內處理挑戰。 一旦通過身份驗證，交易過程將繼續。
此邏輯確保符合地區法規，同時通過僅在發卡機構或方案規則要求時觸發 SCA，最大程度地減少最終用戶的摩擦。
冪等性鍵在 B2B 支付整合中的作用是什麼？
冪等性鍵是在 POST 請求的標頭中發送的唯一標識符。 它們的主要目的是確保操作只執行一次，即使請求被多次重新發送。
在交易價值高的 B2B 環境中，這可以防止由於網絡超時或瀏覽器刷新而導致的意外重複收費。
如果 API 收到帶有相同冪等性鍵的第二個請求，它將返回第一個成功請求的存儲結果，而不是再次嘗試授權支付。
我們能否通過單一 API 連接管理不同的貨幣結算？
可以。 API 通過允許開發人員在交易負載中指定貨幣代碼來支援多幣種處理。
根據您的收單機構設置和 MID 配置，系統可以處理一種貨幣的交易並以另一種貨幣結算，或提供同類結算。
API 響應通常會包含原始貨幣的交易金額以及如果需要國內結算則轉換後的金額，從而使您的會計軟件能夠準確跟踪外匯影響。
錯誤代碼如何為調試目的而構建？
錯誤使用標準 HTTP 狀態代碼以及包含特定錯誤類型和代碼的 JSON 主體返回。 例如，400 Bad Request 可能包含「invalid_cvv」的代碼，而 402 Payment Required 可能表示發卡機構的「card_declined」事件。
這種層次結構允許開發人員區分客戶端整合問題（例如缺少參數）和下游財務問題（例如資金不足），從而在用戶界面中實現自動化和特定的錯誤處理。
哪些安全措施可以保護 API 免受未經授權的訪問？
安全通過多層方法維護，從所有通信強制使用 TLS 1. 2 或更高版本開始。
身份驗證通過 API 密鑰管理，這些密鑰應限制為伺服器端調用，以防止在客戶端代碼中暴露。 此外，可以為敏感端點配置 IP 白名單，並且 Webhook 通常使用加密簽名進行簽名。
這允許商戶的伺服器驗證通知確實來自支付網關，並且在傳輸過程中未被篡改。
API 是否支援用於對賬的自定義元數據？
API 允許在支付和客戶資源中包含自定義元數據對象。 開發人員可以將內部標識符（例如發票號碼或來自外部 CRM 的客戶 ID）附加到交易記錄。
此元數據不會傳遞給卡方案，但會保留在網關和報告系統中的交易中。 這有助於自動對賬，因為這些標識符可以通過 API 檢索或包含在計劃的 CSV 結算導出中。