在爲網站開發信用卡交易頁面以將數據傳輸到支付網關時,我注意到許多輸入選項都可用。支付網關的退貨響應還包含大量數據。使用網站上的付款表格處理信用卡交易數據
下面列出了一些輸入字段其中,我認爲,可以在大多數的支付網關捕獲:
- 客戶的地址
- 客戶ID
- 客戶的IP地址
- 描述
- 電子郵件
- 名字和姓氏
- 發票號碼和訂單號碼
- 稅和免稅地位
- 事務ID
下面列出了一些響應領域我相信它,一般會回到網站:
- 整體迴應(接受,拒絕,錯誤,保持)
- 具體回覆(如地址驗證,卡CCV 驗證等)
- 響應的具體描述
- 散列(特有的商家賬戶)從輸入
- 數據以上
我想找出:
- 您可以在沒有發送到網關的情況下內部處理哪些數據?
- 在處理之前,您將通過網關路由哪些數據?
- 您將使用哪些答案進行進一步處理?
- 您將存儲哪些答案供將來參考,爲什麼?
我相信這個決策過程是Web開發人員在設置電子商務應用程序時通常遇到的。誰願意分享他/她的知識?
要啓動球滾動,讓我嘗試
- 你會在內部處理哪些數據,而不發送到網關?
電子郵件 - 我會通過直接從我的Web應用程序發送電子郵件通知客戶成功的交易。支付網關提供商不需要知道我的客戶的詳細信息。
是的,我明白這是PCI合規性要求。一種完全避免這種問題的方法是讓支付網關託管支付表單。我所要求的是假設我想要託管付款表單。我知道存儲完整的卡號和CCV是一個禁忌。無論如何,這不是我的問題。 –
我在想你的答案,並想知道如何處理這種情況。您是否認爲我應該將產生錯誤的所有事務以及錯誤代碼和事務ID存儲在單獨的表格中進行故障排除?如果客戶收回費用,您將如何處理?謝謝。 –
您可以將失敗的事務移動到單獨的表中。一開始它肯定是有用的。如果你這樣做,我會考慮將其作爲離線批處理任務來完成。對於退款,我創建了一個內部使用頁面,允許內部人員(通常是授權財務人員)通過系統發出扣款。這樣計數器交易就會被創建,並且仍然允許您執行任何您需要的收入確認處理。 –