[day2]开发规格书阅读-不简单的数位金流API

在看规格书前，默默在想永丰消费支付类型的API只开放几只，是不是两三天就可以完成後端开发及串接的部分，剩下的是不是就只能专心开发网页!!结果看过才知道真的没有那麽容易!有很多细节要处理，整份文件55页，下面整理一些重点，也让自己多点概念，就一起来感受一下金流的程序吧!!

永丰银行数位金流API

永丰银行的消费支付API，让商店快速的整合金流服务，无需自行处理复杂作业流程即可安全收款。

如果我是需要收款的商家，最让人担心的主要是安全性及开发的便利性，现在只要规划好自己的网站并串接银行API，金流的部份让银行端来协助，这样的作法更令人放心。
目前看起来主要有三种模式:

• ATM或网路银行缴费:
  如果是以管理费的主题来看，以收缴管理费作为范例，这个缴费方式最为常见。
  
• 信用卡缴费:
  一般来说，管理费不适用於信用卡做缴费，不过能测试的就不要错过，还是来测试信用卡缴费自动化的功能。
  
• LinePay缴费服务:
  近几年来手机应用的主题越来越多，也越来越依赖Line，结合Linepay就更便民了，不过这次没有开放这项服务，只好以後有机会再来玩玩罗
  

API应用服务清单

其实支付行为不外乎就是

建立订单 => 线上付款 => 及时通知付款状况 => 完成订单 => 查询纪录

永丰消费支付API也一样，就包含四大项，其中第四项需要在网路上挂载服务让永丰银呼叫，提供使用端交易之即时讯息。
若没有开发此项，则必须改由网页或批次呼叫OrderQuery，以取得各订单之及时状态。

简易服务介接示意图

简单的呈现介接机制，其中的箭头包含大大小小的request，之後真的是关关难过呀!!!

交易安控设计

最复杂的东西来了，规格书中花了超过三分之一的篇幅介绍的加密过程，
规格书说明:

• 本规格交易安控设计依据「电子银行业务安全控管作业基准」之规范订定如下：
  1. 安全签章（Sign）：
     为确保交易不可否认生，发动交易请求时需完成讯息内文规则性杂凑及
     其他参数，在将杂凑後字串用 SHA256 Hash 产生出来。
  2. 内文加密机制（Message）：
     本规格采用 AES 演算 CBC 模式将讯息内文加密，来确保传送内文之机敏资
     料不外泄，反之於接收交易回应时，将收到的加密内文以相同规则作解密。

之前对於加密解密的经验不太多，这部份看得比较头疼，
预计先重现规格书加密的范例，再进行後端API的开发。
不过接下来即将进入程序开发的阶段了!!还是十分令人兴奋的!!
keep going~