导读: Apple Pay的应用内支付提供了一种全新的在线支付形式,如果将Apple Pay应用内支付自身的特点与App本身的产品形态相结合,用户的在线支付体验将得到大幅提升。ENJOY作为Apple Pay中国区首发的支持ApplePay应用内支付的App之一,在跟Apple Pay的接入时与产品功能做了深度集成,本文基于此对包括可用性、payment sheet、服务器解密、交易处理等在内的Apple Pay技术接入要点进行了经验上的深度分享。
Apple Pay已经在大陆地区正式上线,但大家的关注点大多集中在其线下支付的体验上。对于我们应用开发者而言,Apple Pay的应用内支付给我们提供了一种全新的在线支付形式。如果将Apple Pay应用内支付自身的特点跟App本身的产品形态相结合,用户的在线支付体验可以得到大幅提升。
在国内开发包含在线支付功能的应用,目前可用的选择就是接入第三方支付平台,比如支付宝或者微信支付。这些支付方式在接入方式上大同小异,就是在App中引入对应平台的SDK,在将支付信息组织好之后,调用对应第三方平台的SDK来完成支付。不同平台的SDK对支付的请求处理各不相同,总的来说完成支付有两种方式:调起对应的App或者打开一个网页。比如微信,就只支持打开微信App来进行支付这一种形式。
Apple Pay与现有第三方支付平台相比的优点有:
Apple Pay应用内支付的接入方式跟微信等第三方平台不一样。作为iOS系统原生支持的特性,Apple Pay的相关功能包含在系统的PassKit这个Framework里,不需要引入第三方SDK便可集成。
拿我们的产品ENJOY来说,作为Apple Pay中国区首发的支持Apple Pay应用内支付的App之一,在跟Apple Pay的接入时与产品功能做了深度集成。除了Apple Pay有着目前最短的支付路径这一特点,还有一个我们认为的最大优点,就是Apple Pay提供了系统级的由用户自行维护的个人信息。基于这些特点,与我们现有的用户系统和支付系统相结合,应用内支付体验有了很大提升。
ENJOY与Apple Pay集成后特点:
其中最有亮点的地方就是第一点,未登录用户可以直接购买商品。就目前的电商应用来说,用户只有在登录应用之后,才能购买商品。而ENJOY之所以能做到这一点,是因为对ENJOY来说,只要能够拿到用户的手机号,便可以与我们的用户体系相关联,并完成购买流程。正是利用了手机号可以由Apple Pay提供给应用的这一特性,ENJOY实现了未登录用户通过 Apple Pay可以直接购买商品这一功能(如图1所示)。
首先来看一下Apple Pay应用内支付的时序图(如图2所示)。
从时序图中可以清楚地看到,应用内支付流程分为以下几个步骤:
由上面的步骤可以看出,虽然实际使用时Apple Pay支付的时间很短,但App从显示payment sheet一直到支付成功,其中的过程还是很复杂的。在实际开发中,有很多需要注意的地方,下面具体说明一下。
应用如果显示Apple Pay按钮,需要先判断Apple Pay功能是否可用。这项实现需要结合PassKit Framework中PKPaymentAuthorizationViewController类的两个类函数才能完成判断,它们分别是:
class func canMakePayments() -> Bool
和
class func canMakePaymentsUsingNetworks(supportedNetworks: [String]) -> Bool
第一个函数返回值代表当前设备是否支持 Apple Pay,是用来判断设备硬件的。就目前来说,只有iPhone 6、iPhone 6 Plus、iPhone 6s和iPhone 6s Plus这四款设备支持Apple Pay。
第二个函数则是判断指定的支付网络是否支持。Apple Pay在国内的支付网络就是银联,所以需要传入PKPaymentNetworkChinaUnionPay这个值。
同时,需注意API的版本可用性,以上两个函数都是iOS 8才开始支持的API,其中 PKPaymentNetworkChinaUnionPay这个支付网络更是从iOS 9.2才开始支持,所以判断是否支持Apple Pay的最终代码是这样的:
if #available(iOS 9.2, *) {
if PKPaymentAuthorizationViewController.canMakePayments() && PKPaymentAuthorizationViewController.canMakePaymentsUsingNetworks([PKPaymentNetworkChinaUnionPay]) {
// TODO: 支持 Apple Pay
}
}
注意: 一定要把工程target设置的Capabilities里的Apple Pay选项打开,不然在真机调试的时候,以上代码判断结果肯定是不支持的。
Payment sheet也就是Apple Pay支付的UI,有不少地方是可以自定义的。想要自定义payment sheet,需要对类PKPaymentAuthorizationViewController的初始化参数paymentRequest做相应的设置。paymentRequest参数是一个PKPaymentRequest类型的对象(如图3所示)。
首先,初始化一个PKPaymentRequest对象,并设置必需内容:
let request = PKPaymentRequest()
request.merchantIdentifier = "merchant.xxxxx”
request.merchantCapabilities = [.Capability3DS, .CapabilityEMV, .CapabilityCredit, .CapabilityDebit]
request.countryCode = "CN"
request.currencyCode = "CNY"
request.supportedNetworks = [PKPaymentNetworkChinaUnionPay]
merchantIdentifier需要与苹果开发者后台的配置相对应。以上代码中还有一个必需属性 paymentSummaryItems没有设置,该属性代表在payment sheet中显示的价格列表,是一个PKPaymentSummaryItem类型的数组。该数组至少要有一个元素,并且最后一个元素所包含的价格,就是实际要支付的价格。如果需要显示手机号或者收货地址,则可以对 requiredShippingAddressFields这个属性做相应的设置。
设置完毕后,通过以下代码可以调起payment sheet:
let vc = PKPaymentAuthorizationViewController(paymentRequest: request)
vc.delegate = self
presentViewController(vc, animated: true, completion: nil)
关于payment sheet这个UI需要特别说明:这个UI的视图优先级相当高,连alert都会被盖住,App在处理这个UI的时候需要注意。当payment sheet显示和消失时,对应的App也相当于进入后台和切回前台,所以,系统通知和AppDelegate里的回调函数也都会有所响应。
在用户输入指纹和PIN码验证之后,回调函数func paymentAuthorizationViewController(_, didAuthorizePayment: completion: )将会被调用,其中参数didAuthorizePayment类型是 PKPayment, 里面包含两类信息。第一种是明文的用户信息,对应的是初始化payment sheet 时的设置。另外一种就是加密过的支付信息,PKPayment有一个token属性,该属性的类型是PKPaymentToken,其中的paymentData属性就是加密过的支付信息。paymentData的内容是一个JSON的二进制流,将其解析之后,结构如下:
{
data = "xxxxx";
header = {
publicKeyHash = "xxxxx";
transactionId = bce2f62f92cb1f5b16696f1ea3b1b375cbfe8fe45c9132ae381c77ed45202455;
wrappedKey = "xxxx";
};
signature = "xxx";
version = "RSA_v1";
}
使用signature字段对消息进行验签,防止信息被篡改。之后取出header.wrappedKey的内容,它是使用非对称加密算法加密过的对称秘钥。用在苹果开发者后台配置merchantID时的私钥进行解密,就能得到这个对称秘钥。然后,使用这个对称秘钥对data所包含的加密数据进行解密,取得Apple返回的支付信息。此支付信息是加密过的,包含了用户支付的卡号和 PIN码等信息,理论上只有银联才能解析出来真正的内容,对我们商户而言其内容是加密的。服务器端需要将这些解密过的信息组织成银联所需的报文内容,随后调用银联的扣款接口,完成扣款。
在调用银联的扣款接口后,有一点非常重要,就是要确保扣款结果是否成功。只有确切的知道了扣款结果,才能正确地设置自己平台的用户订单状态。银联的扣款接口设计是这样的,在调用接口之后,返回同时有同步和异步两种形式。如果同步结果返回成功,只是说明银联成功收到并开始处理扣款请求,并不代表扣款成功。扣款是否成功,是通过异步形式来通知的。而扣款不成功的原因有很多,比如卡被冻结、PIN码错误、余额不足等等。
我们采用的做法是这样的,调用扣款接口后,如果3秒内没有收到本次调用的异步回调,则通过使用同步结果返回的银联流水号,开始轮询银联的另外一个交易状态接口来确保拿到交易结果。
如果发生交易失败的情况,App需要做相应的UI处理。按照Apple的交互要求,以下几种失败情况,payment sheet不能退出,其余的情况则需要退出payment sheet后,由App负责通知给用户。
payment sheet的显示结果是由func paymentAuthorizationViewController(_, didAuthorizePayment: completion: )这个回调函数中的completion这个参数来控制的。该参数是一个closure,它的第一个参数类型是PKPaymentAuthorizationStatus的枚举,打开该枚举的定义,可以看到上面的情况已经由操作系统定义好了,对应起来分别是:
UI显示的细节:在调用completion后,如果传入的PKPaymentAuthorizationStatus值是Success 或者Failure,payment sheet在展示出相应的结果之后都会自动dismiss掉。而如果传入的是上面三个有关PIN码的值,则payment sheet并不会消失,用户可以继续选择银行卡,然后进行指纹验证等支付操作。
在payment sheet显示出来到消失的这段时间内的任意时刻,用户都可以通过点击payment sheet右上角的「取消」按钮来手动取消支付,那这就涉及到了交易撤销的问题。交易撤销是由服务器来完成的,那么App要做的首先是把用户取消的事件通知给服务器。由于整个支付过程步骤很多,总的来说,服务器撤销交易要面临以下三种情况:
第一种情况很容易处理,只要服务器之后不再调用银联扣款接口即可。第二种和第三种情况的处理方法一样,区别在于第二种情况的处理时机是在获取到扣款成功结果之后。如果是后两种情况,则调用银联的交易撤销接口,以撤销之前的交易,把已经扣除的用户款项返还给用户。
注意: 由于有些银行不支持交易撤销,所以调用交易撤销接口后需要判断一下返回结果,如果不支持,则还需调用退款接口来返回款项。
Apple Pay应用内支付的在技术上并不难,但所涉及的细节非常多,需要花费不少功夫处理好各种情况。如果对Apple Pay应用内支付定制化需求并不强,有不少第三方支付平台目前已经提供了自己封装的SDK来供开发者使用,比如银联的CUP SDK等。这些SDK屏蔽了支付过程中的很多细节,可以方便地接入到App中。但如果需要接入原生的Apple Pay来实现好的应用内支付体验,那么本文可以给你提供一些帮助。
关于:中科研拓
深圳市中科研拓科技有限公司专注提供软件外包、app开发、智能硬件开发、O2O电商平台、手机应用程序、大数据系统、物联网项目等开发外包服务,十年研发经验,上百成功案例,中科院软件外包合作企业。通过IT技术实现创造客户和社会的价值,致力于为用户提供很好的软件解决方案。联系电话400-0316-532,邮箱sales@zhongkerd.com,网址www.zhongkerd.com