中國金融積體電路（ic）卡規範(pboc3.0)
最近例行檢視交易流水中發現經常出現沖正的交易，有點不太尋常。經分析發現絕大多數是農業銀行，ic卡，插卡交易。
沖正：系統認為可能交易失敗時採取的補救手法。即一筆交易在終端已經置為成功標誌，但是傳送到主機的賬務交易包沒有得到響應，即終端交易超時，所以不確定該筆交易是否在主機端也成功完成，為了確保使用者的利益，終端重新向主機傳送請求，請求取消該筆交易的流水，如果主機端已經交易成功，則回滾交易，否則不處理，然後將處理結果返回給終端。
因此我們第一時間排查日誌，查詢渠道是否有成功應答。
經過我們多筆問題訂單跟蹤，發現渠道都有返回交易成功，沒有超時；
而且經過跟蹤確定資料已經發出去，到達終端。
因為我們自己沒有農業銀行卡，問題現象都是通過觀察管理後台流水資料分析。
如果說是網路異常導致posp應答訊號無法到達終端。那麼也不應該都碰到農業銀行卡上面，不可能有這麼巧的事情。
然後對比返回日誌中各個字段，也沒找出有和異常。然後問題卻一直存在。真是令人頭疼。
不行，還是得找一張農行卡，自己試試。
在技術群裡吼了一聲，沒過多久熱心的旺旺同學就帶著她的農行卡過來了。
刷了一筆，居然成功了？？？
後面認真一分析，開始刷的是揮卡，不行，還得測下插卡交易。
問題重現了，真令人開心。終端顯示「ic卡二次授權失敗」
原來是這個問題。汗，虧我們還一直猜測是終端沒有收到應答。
查到了問題，那麼接下來就好辦了。
後面經過和終端施工，技術大佬海波，了解到。
pboc標準中聯機交易完成後。
ic卡插卡交易時，還會傳送發卡行的授權認證碼給到終端卡片來認證發卡行身份。
這個只有個別卡片會做這個校驗。
然後我們posp系統沒有返回 這個資訊給到終端（也就是55域）導致終端返回認證失敗。
於是第二次交易就產生了沖正。
修改as_pos_sdk服務配置檔案as_pos_sdk.ini中開啟返回ic卡資訊給到終端。問題解決。
[transaction]
returniccarddata=1
聯機交易流程
紅框出來這裡就是上面說的發卡行認證
7.11.4.2 聯機響應
在聯機響應處理階段，終端接收來自發卡行主機的聯機響應，並決定是否應該進行發卡行認證：
——如果以下兩個條件同時滿足，終端將按照 7.11.4.3 描述進行發卡行認證。
● 聯機授權響應中包含發卡行認證資料；
● 應用互動特徵（aip）顯卡片支援發卡行認證。
——如果滿足以下任一條件，終端將進行交易結束處理。
● 聯機授權響應中不包括發卡行認證資料；
● 應用互動特徵（aip）表明卡片不支援發卡行認證。
終端應能正確讀取並處理收單行返回的資料：授權碼，授權響應**，發卡行認證資料，發卡行腳
本等。授權響應碼的處理：聯機成功後，收單行會在響應報文裡傳送發卡行的兩位元組授權響應碼，表示發
卡行對交易的授權結果，如批准交易、拒絕交易或發卡行要求的授權參考。
PBOC2 0 PBOC3 0主要差異
1 可儲存姓名 5f20標籤 長度增加 增加了9f0b標籤 但新的檢測標準不建議把姓名寫入卡中。2 增加qpboc非接擴充套件應用。3 增加了雙幣電子現金和雙幣qpboc應用。4 增加了ic卡網際網路終端應用。5 增加了電子現金交易日誌與qpboc交易日誌。6 刪除了電子錢包 電子存摺應用。7 增加...
置頂 qeephp3 0 發布了
qeephp 是乙個快速 靈活的開發框架。應用各種成熟的架構模式和創新的設計，幫助開發者提高開發效率 降低開發難度。主要目標是為開發者建立更複雜 更靈活 更大規模的 web 應用程式提供乙個基礎解決方案。在這之前,我們一直都在使用2.1,這個框架是如此的給力和美好,但是遺憾的是自從2.1之後框架由於...
Redis3 0 發布與訂閱
redis的發布與訂閱功能由publish subscribe psubscribe等命令組成。通過執行subscribe命令，客戶端可以訂閱乙個或多個頻道，從而成為這些頻道的訂閱者 每當有其他客戶端向被訂閱的頻道傳送訊息時，頻道的所有訂閱者都會收到這條訊息。除了訂閱頻道之外，客戶端還可以通過執行p...