標籤: 第三方支付

Delphi 連接 SSL TLS 1.2 第三方支付金流問題

台灣最近銀行與第三方支付、行動支付發展越來越快，而Delphi使用indy元件時，如果處理SSL網站時不是很容易。
後來找到了ipwork的元件還不錯用。
列一下關鍵的程式

  ipwhttp1 := Tipwhttp.Create(Application);
 ipwhttp1.Config('CodePage=65001');
 posturl:=posturl+'barcode='+sBarcode;
 ipwhttp1.Post(sPaymentURL+'?'+posturl); 
 result:=UTF8ToString(ipwhttp1.TransferredData);
  ipwhttp1.free;

另外處理像SHA/AES等加解密也很方便

function GetTokenKey(s:String):String;
var ipcHash1: TipcHash;
begin
  ipcHash1 := TipcHash.Create(Application);
  ipcHash1.Reset();
  ipcHash1.Algorithm := TipcHashAlgorithms(haSHA256);
  ipcHash1.InputMessage := s;    
  ipcHash1.ComputeHash();
  result :=lowercase(ipcHash1.HashValue);
  ipcHash1.Free;
end;

玉山銀行支付寶串接系統面臨的一些問題分享

今年政府允許了玉山銀行與大陸最大的第三方支付「支付寶」合作後，就協助做與店家串接服務的工作。

一開始就把它當做是信用卡、悠遊卡、一卡通、ePay這類的服務做串接，倒也還好，只是介接支付寶到後面發現奇摩子很不爽…….

整個介接過程一直被當合作伙伴(ㄅㄞˊㄌㄠˇㄕㄨˇ)，為什麼知道呢？因為每次介接程式做好要測試，就發現它們的DEV環境又修改了東西。然後出現了各式錯誤訊息~接著就要寫信給工程師等待回應。
1448109439374

1448109430016

1448109415636

1448109402120

image001 (1)

1448109298136

昨天開始正式環境時，又出現了相關的訊息~眼尖會發現系統是接收sdk所回傳的訊息。不過突然玉山竟然說是程式的問題~因為不相信之前測試完成是有問題的，就請對方把當初的測試機搬上去，測試後發現測試機沒問題，正式機有問題後，這下就知道問題不在程式了。接著回應是

13:33 玉 SRY，目前這個Config檔，仍然是先連線到測試機
13:35 玉 我們正式環境的LOAD BANANCE主機，今天還在調整
13:35 玉 問到了，DEV(測試機)工程師今天有動到資料庫
13:36 玉 剛剛的ERROR應該是Mapping不到，造成初始化失敗

一開始覺得還好，不過人真的很重視的是奇摩子。尤其是一開始被咬定是程式問題時~就覺得超級不爽

1448109366309

POS系統結合iPASS一卡通範例

12219570_10153067567121541_5370508928219483252_n
12208306_10153067535151541_1778219125832501158_n
一卡通(iPASS)是與悠遊卡(EasyCard)都是台灣的電子票證智慧卡，二者都是使用RFID(菲利浦的MIFARE)技術。今天來分享大致的技術~
首先，您得先到一卡通官方網站中的”加入特約商店“，提供相關資料向一卡通票證公司申請，並向一卡通公司申請測試機器及卡片。
審核通過後，iPASS一卡通公司會提供一台一卡通的測試機器，以及相關的文件及SDK。SDK與之前刷卡系統神似~
主要是輸入長度62的in.txt;輸出的out.txt則為109~928(有無交易記錄)。
1447167886093