嵌入式結帳
以轉換為重點的結帳體驗、APM支援和3DS優化，建基於我們的多收單夥伴網絡之上。
- 類別
- 結帳
- 功能
- 10
- 適用於
- 所有方案
Cardflo 的嵌入式結帳功能將支付處理直接無縫整合到您的網站或應用程式中。
此解決方案提供了一個安全、符合 PCI 標準的支付表單，該表單會顯示在您現有的頁面中，從而消除了重定向並保持了一致的用戶體驗。 它專為尋求直接整合而又不犧牲控制權或品牌形象的商家而設計。
結帳頁面根據您的客戶實際使用的卡片、錢包和本地支付方式的特定組合進行調整，3DS僅在有助於批准的情況下應用，而不是作為一個生硬的門檻。 結果是可衡量的更高轉化率，且沒有增加風險。
概述
嵌入式結帳是一種客戶端整合方法，其中支付輸入欄位由服務提供商 (PSP) 託管，但呈現在商家現有的網路架構中。
與需要瀏覽器重定向到外部網域的託管支付頁面不同，此模型利用 iFrame 或託管欄位來保持用戶在主網站上的存在。
數據流確保敏感的主帳號 (PAN) 數據永遠不會接觸商家伺服器，因為輸入欄位直接與收單機構的網關通信。 此機制顯著降低了 PCI-DSS 合規性的範圍，通常允許商家符合更簡單的 SAQ A 或 SAQ A-EP 評估。
通過保留對安全欄位周圍 DOM 的控制，企業可以管理視覺佈局和用戶旅程，同時將加密安全和代幣化流程委託給支付堆棧的基礎設施層。 這種方法平衡了品牌要求與強大的風險管理和技術安全性。
運作方式
客戶端腳本初始化
整合從將支付提供商的 JavaScript 庫加載到商家的結帳頁面開始。此腳本在特定的 DIV 元素中創建安全容器，確保關鍵支付輸入與頁面其餘代碼隔離，以防止跨站腳本漏洞或數據干擾。
安全欄位渲染
提供商為卡號、到期日期和 CVV 渲染單獨的 iFrame。這些欄位託管在符合 PCI 標準的環境中，但顯示為商家表單的一部分。這種分離確保商家只處理非敏感元數據，而實際持卡人數據直接傳輸到網關。
代幣化和驗證
當客戶輸入其詳細資訊時，系統會對 LUHN 檢查和 BIN 識別執行即時驗證。提交後，敏感數據會交換為安全保險庫令牌。此令牌代表支付工具，並且是唯一傳遞給商家後端以進行授權請求的憑證。
交易授權
商家將令牌發送到其伺服器，然後伺服器啟動對收單機構的授權呼叫。收單機構將此轉發給卡片組織和發卡機構。發卡機構返回響應，例如批准或拒絕代碼，然後商家將其顯示給用戶。
重要意義
轉換率優化
重定向通常會引入摩擦和延遲，這是導致購物車放棄的主要原因。通過在整個交易過程中將客戶保留在商家網域內，支付過程感覺像是用戶旅程的連續部分。這種一致性有助於保持信任，尤其是在高價值交易中，URL 的突然更改可能會導致用戶懷疑網絡釣魚嘗試或技術故障。
安全和合規負擔
管理原始卡片數據需要廣泛的安全協議和 PCI-DSS 1 級標準下的嚴格年度審計。嵌入式模型通過確保商家伺服器從不查看、處理或儲存敏感 PAN 數據來繞過這些要求。這種轉變降低了與數據洩露相關的操作開銷和責任，因為安全負擔轉移到服務提供商，其系統專為數據保護而構建。
使用案例
SaaS 平台訂閱
軟體提供商在帳戶設定期間使用嵌入式欄位收集支付詳細資訊。這使他們能夠捕獲支付方式並將其儲存為網絡令牌以進行定期計費，而不會中斷入職流程或引入外部網站重定向。
高流量電子商務網站
流量大的零售商使用嵌入式結帳來維護品牌完整性並最大程度地減少完成步驟。這對於移動商務尤其有效，在移動商務中，應用程式和瀏覽器之間的重定向可能導致會話超時或加載錯誤。
企業市場
涉及多個供應商的市場使用嵌入式欄位來標準化其平台上的支付體驗。這確保無論特定供應商如何，支付基礎設施都保持安全和一致，從而在後端促進複雜的拆分結算工作流程。
依據數字
行業研究表明，消除重定向可以顯著降低購物車放棄率，因為客戶在支付階段遇到技術摩擦或信任問題的可能性較小。
根據標準 PCI-DSS 評估基準，與處理原始卡片數據相比，使用託管欄位可以將商家每年必須審計的安全控制數量大幅減少。
與傳統的非響應式表單佈局相比，觸發原生鍵盤並提供即時驗證的優化嵌入式欄位通常可以縮短移動用戶的完成時間。
相關術語
與我們的團隊討論在我們收單合作夥伴的 rails 上進行即時部署。
{{title}} 的優勢 嵌入式結帳
- 透過隔離敏感支付數據，將 PCI-DSS 範圍縮小到 SAQ A 或 SAQ A-EP。
- 消除跨域重定向，以最大程度地減少結帳摩擦並提高客戶保留率。
- CSS 自訂功能，使支付表單與現有的品牌風格指南保持一致。
- 即時客戶端驗證，用於卡片格式、到期日期和 CVV 長度檢查。
- 直接將卡片詳細資訊代幣化，以確保安全傳輸到支付網關。
- 響應式移動輸入欄位，可適應各種螢幕尺寸和虛擬鍵盤佈局。
- 支援在嵌入式流程中直接進行 3-D Secure 身份驗證，以符合 SCA 標準。
- 自動 BIN 檢測，以識別卡片類型並立即應用相關處理邏輯。
- 與現代 JavaScript 框架（包括 React、Vue 和 Angular）兼容，以實現結構化整合。
- 結帳欄位支援本地化語言，以迎合全球客戶群。
A short scoping call, then a written plan for your MIDs.
關於 嵌入式結帳
嵌入式結帳與託管支付頁面在安全性方面有何不同？
託管支付頁面會將用戶重定向到由 PSP 管理的 URL，而嵌入式結帳則使用 iFrame 或託管欄位將用戶保留在商家網站上。 從安全角度來看，兩種方法都確保商家不處理敏感卡片數據，但嵌入式方法對用戶體驗提供了更多控制。
嵌入式方法通常比託管頁面需要稍微複雜的技術實施，但為最終用戶提供了顯著更好的轉換路徑。
使用嵌入式欄位是否需要特定的 PCI-DSS 認證級別？
使用嵌入式欄位的商家通常符合 SAQ A-EP 或 SAQ A，具體取決於欄位的實施方式。 由於敏感數據是在直接與 PSP 通信的 iFrame 中捕獲的，因此商家伺服器實際上已從持卡人數據流中移除。
與基於 API 的整合相比，這顯著降低了合規性要求，在基於 API 的整合中，商家伺服器可能會在代幣化之前暫時處理原始卡片數據。
我可以設定嵌入式欄位的樣式以符合我網站的特定字體和顏色嗎？
是的，大多數嵌入式欄位實施都允許 CSS 樣式設定。 雖然欄位本身託管在安全的 iFrame 中，但提供商的庫通常接受定義字體、顏色、填充和邊框屬性的樣式對象。
這使得支付欄位看起來像是商家頁面的原生元素，確保在最終結帳階段保持一致的美學，從而支持品牌信任。
如果客戶的卡片需要 3-D Secure 身份驗證，會發生什麼情況？
當需要 3-D Secure 進行強客戶身份驗證 (SCA) 時，嵌入式庫通常會觸發一個模態或疊加層。 客戶在此窗口中完成挑戰，一旦授權，焦點將返回到商家的結帳頁面。
此過程無需完整頁面重定向即可發生，從而保持會話並降低客戶在身份驗證過程中關閉選項卡的風險。
嵌入式結帳是否針對移動設備進行了優化？
行業標準的嵌入式結帳組件旨在響應式。 它們利用媒體查詢根據設備的螢幕尺寸調整輸入欄位的大小和佈局。
此外，它們還配置為在移動操作系統上觸發正確的數字鍵盤，這提高了客戶數據輸入的速度和準確性，從而提高了手持設備上的完成率。
嵌入式結帳是否支持數字錢包等替代支付方式？
嵌入式結帳通常可以配置為在傳統卡片輸入旁邊顯示數字錢包按鈕，例如 Apple Pay 或 Google Pay。 這些方法通常完全繞過卡片輸入欄位，使用錢包中儲存的憑證通過安全令牌授權交易。
這種多模式方法確保結帳對於各種消費者偏好保持靈活，同時保持單一整合點。