Author’s brief introduction

Yang Wei is the payment Native iOS group Leader of Ctrip Financial Payment Center. Currently, he is mainly responsible for the payment project function development and team management of The Chinese version of Ctrip APP and international version of Ctrip APP. Love life, love to explore.

Apple Pay is a new function supported by Apple in iOS8 released in 2014, and China union Pay card was supported in iOS9 in 2016. Apple Pay occupies a place in the domestic market by virtue of its payment security, simple and fast user experience, and easy development and access.

Ctrip was one of the first Chinese APP merchants to access Apple Pay and currently supports Apple Pay in its international APP. The international version of Apple Pay is still being expanded to include new national currencies and payment channels.

This article mainly starts from the perspective of iOS front-end client, summarizes and reviews some problems encountered in the in-app access and development of Apple Pay, hoping to bring inspiration and harvest to developers.

This paper will mainly include three parts:

The first is to sort out the payment process of Apple Pay, in which the roles of the client, the server, Apple and the payment provider are respectively played;

Second, how to support Apple Pay on the client: how to configure the development certificate and matters needing attention in the development;

Third, there are some differences between domestic and international Apple Pay access.

I. The overall process of Apple Pay

The following figure is a general process of Apple Pay access in China (UnionPay API mode), for reference only:

  

The whole process is as follows:

1. The client displays the Apple Pay payment control in the APP through Apple API.

2. Users use the Apple Pay payment control for biometric authentication (fingerprint or face recognition) or phone password authentication.

3. After the user passes the authentication, Apple will generate an encrypted data related to the PaymentToken of the user’s selected bank card. Apple Pay can only be carried out when there is a network, Apple needs to use the public key of the certificate to encrypt it from the developer website, and then return it to the client front end through API callback.

4. After obtaining the PaymentToken, the client sends a debit request to the server and waits for the payment result.

5. The server receives the PaymentToken sent by the client, decrypts the PaymentToken, extracts some key field information, and provides other order information, and then communicates with the payment provider (such as China UnionPay) to initiate payment deduction.

6. After receiving the result of payment deduction, the server will return the payment result to the mobile client and finally notify the user of the payment result.

Ii. How does Apple ensure security

1. Bind the Apple Pay card

In the Wallet app for iOS phones, users can bind a real bank card. During the binding process, you need to enter the security field of your bank card and verify your mobile phone number.

After binding successfully, we can check this card in our mobile Wallet, and we will see a device card number in the card details. The device card number is the virtual card number of the bank card. This virtual card number is the card number that can be obtained after decryption in the PaymentToken issued by Apple. This card number will be sent to the payment provider (such as China Union Pay) for deduction.

The virtual card number will not be fixed and will be re-generated and changed every time the bank card is re-bound. This ensures that no real bank card number will be transmitted over the network during any future Apple Pay payments, increasing security.

Apple will communicate and interact with different card issuers in the process of binding cards. When Apple Pay just entered China, we saw that some bank cards could be successfully bound and some could not, just because some channels were not stable.

In addition, we can find special apis on the Developer website of Apple Pay. Through these apis, some card issuer apps, such as some bank apps, can directly bind the card to the Wallet in the APP. These functions need to be submitted to Apple. Get a special authorization file, configure to the development project, to tune those apis. Relevant API can be found on the Internet, here is only for understanding, our general APP development will not use.

In the whole platform of Apple Pay, Apple has a set of security mechanisms in the process of dealing with card issuers, payment suppliers and client front-end. We can see how invested Apple is in Apple Pay and how serious it is. The Apple Pay API for iOS clients is also simple and easy to access. Specific usage can be found on the Apple Developer website.

2. Apple Pay data encryption

The PaymentToken in transit in Apple Pay has a very sophisticated cryptographic security mechanism.

ECC encryption is universally used in foreign countries, while RSA encryption is only used in China. For details, see the official PaymentToken description.

The PaymentToken data is a JSON data format that contains Apple’s encrypted payment information data.

PaymentToken sample

ECC is elliptic encryption algorithm, which is an asymmetric encryption method.

ECC encryption mode in PaymentToken format

{ “data”:”H22hDxsaFP8JZCuLf6AYu99IB2rLvRbQaZ/NtuQB/vS++ctYSCqPYWUH69eCV59eUdpEcHSOnJPX+95FpFuyRxryb+xzG0EIO0T7fPwDHPyZcA1g ixgG/DD10oQgbTf6uWPWkB3z5E3ENsl4QKOTOpladzj4cLKPerlb28s9gjuJtXSylxbnSe5aRFBFwdqsus39hfXNdlIqRCJzYLiGrIFThxoKSv7kVK32u5UY jjAizMkH5tE0fvFbPjGvi3JLrGCozmJDytFWQUVjzba6ORLtd+ui0oe2PXzkVun8w0BNK2tsKh/Jfh4HdK/JD/TBbFLz06SkVa0T7OSjuyItln7NNh3PC+sA ltllUyAtjYnY3X76t/DnJ23GVbwZ4t1bUjieZ2loBg+j1w0adcB0dR9UA1Eh1fexrdZW737sd6wp6Edd+PoEW4G5hY0RM/F280q6SD/wWwr80rOkQmE=”, “header”: {

“ephemeralPublicKey”:”MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEBZITXjr/xw6fsaVQ2bHCJVwglJt9f9ikgFGtsCKun1Spbei/xi756rt/aTA13u gqNiI2ITk0QvivqV6PhwmrHQ==”, “publicKeyHash”:”KjwaMOiXIeoSDyLEz5TDPl3uXAVcwZ2f5/P/jGH+gMo=”,”transactionId”: “2e9d75661d1641d188d4e646901fe708836b5a5ac7c705c15915b27e23786488” }, “signature”:”MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCAMIID4jCCA4igAwIBAgIIJEPyqAad9XcwCgY IKoZIzj0EAwIwejEuMCwGA1UEAwwlQXBwbGUgQXBwbGljYXRpb24gSW50ZWdyYXRpb24gQ0EgLSBHMzEmMCQGA1UECwwdQXBwbGUgQ2VydGlmaWNhdGlvbiB BdXRob3JpdHkxEzARBgNVBAoMCkFwcGxlIEluYy4xCzAJBgNVBAYTAlVTMB4XDTE0MDkyNTIyMDYxMVoXDTE5MDkyNDIyMDYxMVowXzElMCMGA1UEAwwcZWN jLXNtcC1icm9rZXItc2lnbl9VQzQtUFJPRDEUSBBcHBsaWNhdGlvbiBJbnRlZ3JhdGlvbiBDQSAtIEczMSYwJAYDVQQLDB1BcHBsZSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTETMBEGA1UECgwKQXBwbGUgSW5jLjELMAkGA1UEBhMCVVMCCCRD8qgGnfV3MA0GCWCGSAFlAwQCAQUAoGkwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwNDA1MDQwOTE2WjAvBgkqhkiG9w0BCQQxIgQgmDfQVEEPlInbB9tQ/AQjni+COkvegoWmfwtpbwe7cuUwCgYI KoZIzj0EAwIERzBFAiB/4NnlUFbNkEqdJ6OGRtA78mZ30539P226OwsNRptycgIhAIzFEYsHH2xuMLVfxEiUmtQxcMdqgW1BgtL/AygaVaAhAAAAAAAA”, “version”:”EC_v1″}

After decrypting ECC encrypted data, see:

{   “applicationExpirationDate”: “190131”,   “applicationPrimaryAccountNumber”:”370295XXXXX5435″,    “currencyCode”:”840″,   “deviceManufacturerIdentifier”: “XXXXXXXXXX”,    “paymentData”:{        “emvData”:”nycBgJ82AgDCnyYIG2vuQydGkMafEAcGhgEDoLABXzQBAJUFgAABAACCAhzAnwMGAAAAAAAAnxoCCECaAxQQBJwBAJ83BLnvab4=”    },   “paymentDataType”: “EMV”,   “transactionAmount”: 100}

Domestic RSA encryption mode, PaymentToken format obtained:

{“data” :”juTLgE+0gQPg3RSe5DdJj1/w4amEvJOWSIka+nHNGFmFVd028omhkwMNNqG0exHgT39DAXnKqVNBh4ExGvIEgO7yi97JhDOmwq0nTyvPF/U393wgizrmoe 8zX1FpUzI7e2co8PIYCJLkC6uTIuuumsE//503nDhvnz9frzmiMYVhdquf56couB028QBhJiQAupLM+NawVJ41i7e7WJIfyVhYEEn1Qw0TKZKy+Y65PkhAgd wlUGkKUI6r2IpHCc/l4EWvpn1tcVQvVeoG6qJxUdszgL6qrJBLtaT+/8teg9/jfn0iQwipEgYfTjalgHwXx3nop0dK2ZxzcOzdclfTY3uguM6HBNK6rK3hL2 B/LnidAuWE0EWMp5/kqNunDJsSXsUM4+g6zg7ceVjlndZ0YLrQozxRkhPkgHHGtjFxn01PpeGSMMdoAVc8iOgpGKrjx/AAIp2jNY1fZZ1G4cYzW+gsJo5Prm PV7gGxA+M+HG5xdwMVfa9/cxS0qVU2eMw92OB7hdgaIW6cwONETgrd0Y2vF/oHiw7AbRiX/3GxkOJfJ9/5S0P6cxJF4JsvVHkrgit6gZPMCMXFQxDQsK8Dlm Q9YxzDRIJCb9jxKE0=”, “header” : {“publicKeyHash”: “YcmdtTV209LCGVZV99T0lNab3yo0KnudAyBKQPo+5e8=”, “transactionId”:”41a6eb8dd8602def5f41463ad314e484289258df71ab17b50204ea4795a3db52″,”wrappedKey” :”l6w4oBmvLF/f/6Gj7idhO5aIFlwZ5qZrqSLxR+mLqsjJqHLf2OUTObn+UOO/Iaupc+nc6Kuz1ZTQbBMG2w6/KC8F07lZTPnCOcHVxxBP03UQn6gNkNV8DL NNqJ9GoBDzbGy/dWgKBBPNEdgA59jKY+8H/XQzvNuZqiFDM4LTr+O3/FdqGy6PxfFHRwRNV15WoKtsfQ91xPf++MI4GoTZSdxpc63ewm/8l5Q81AqnZMH03P MRyu8POT92tl10tg8GRmQFCXMgBm7GM+6nz0tebOoLndspqHbe9xtAGmxzseuFCi4A2q8WaqzPgnQ917bvuUnxNHAkXoPTVIUCsXzxXA==” },”signature”:”MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCAMIIEtTCCBFugAwIBAgIIEVmL4CjCUF8wC gYIKoZIzj0EAwIwejEuMCwGA1UEAwwlQXBwbGUgQXBwbGljYXRpb24gSW50ZWdyYXRpb24gQ0EgLSBHMzEmMCQGA1UECwwdQXBwbGUgQ2VydGlmaWNhdGlvb iBBdXRob3JpdHkxEzARBgNVBAoMCkFwcGxlIEluYy4xCzAJBgNVBAYTAlVTMB4XDTE0MTIwMzAxMDAyNloXDTE5MTIwMjAxMDAyNlowZzEtMCsGA1UEAwwkZ WNjLXNtcC1icm9rZXItc2lnbl9VQzQtUFJPRF9LcnlwQ8XDTE2MTEwMjEyMzg0OFowLwYJKoZIhvcNAQkEMSIEIP+1yZ0K5+XsvQRPOcudpBElpvl64hJ2pE 0PryWNhFSlMA0GCSqGSIb3DQEBAQUABIIBAHuOnvaNlq/1oBGLGyi/+6BmUJLAZjtArsHnpMArgEcmW8qy1oObVeSF7puBjhsnnoWsGnSr+c0/jxYgxKk10R uzLdxdITbx2DJab+3AzQ4gCatfKuzlzPAdqYaumZLnr/6pJ+CPLaTlWZJZhrPY7GNiqdN2v22tXZQae6fHLwXXqNzjdVOsHNYRRReZA9jbQ46haaI/3HpYuQ pRhLu5EAkReaYZZKuOhpyxxUeatFtRFwo/vH3yOU5eG07VASCGB33SZqgjJNMZWACIF3FRKK9W8yL50ywEZzDCpCV3/6Jk9yZB1h/jU7qu3iTBXo8jU6lGRc oKjl0DzkiIEQVHB+kAAAAAAAA=”,

“version” :”RSA_v1″

The encryption method of Apple Pay in China is RSA + AES. RSA is asymmetric encryption, and AES is symmetric encryption. The above data is actually obtained by AES encryption. The AES key is hidden in the wrappedKey inside the Header and is protected by RSA encryption.

Decryption of domestic encrypted data, as follows:

{ “applicationPrimaryAccountNumber”:”62583300888880215″, “applicationExpirationDate”: “270101”, “currencyCode”: “156”, “transactionAmount”: 0, “deviceManufacturerIdentifier”: “062010011111”, “paymentDataType”: “EMV”, “paymentData”: { “emvData”:”nyYItis3L6CiQbufNgIACYECAE2DgZCgujJqvZh6gtCOicVyx2tOh1ncXHOQ9bhYMObxz+IHR5a4PD93thtwu7RKyIFb2zab3wkj0oMcra5Cf +J+JbXdk0FxxxxxxxxxxT56HVqNMBp4M/7Uh36lblsiLkvW0H3rwLVWE/CV4/h0=” }}

We all can see deviceManufacturerIdentifier after decryption is mobile Wallet inside binding bank card virtual card number, this is for to pay the supplier by use of deductions.

Iii. Payment to suppliers

Payment suppliers are mainly merchants that provide payment and deduction channels, such as China’s UnionPay and foreign Adyen. You can refer to payment suppliers supported by Apple. The payment provider is mainly responsible for interacting with the card issuer to initiate the deduction.

Iv. Client development of Apple Pay

The work of client development mainly includes:

1. Certificate preparation;

2. APP engineering configuration and certificate use;

3. API call;

A certificate to

Developers need to submit Apple Pay certificates on the Apple Developer website.

Generate Apple Pay certificate need to prepare a CSR file first, through the MAC computers can quickly generate key string, the CSR file is a text file CertificateSigningRequest. CertSigningRequest.

You need to upload this CSR file to the Apple Developer website:

Do iOS development more understanding, Apple’s various development certificates are generated through this form.

Note the following when generating the CSR file of the Apple Pay certificate: RSA encryption is required when generating the CSR file in China. ECC encryption is required for CSR generation in non-China regions.

The CSR contains public key information, and the corresponding private key is generated in the MAC keychain application at the same time. After uploading the CSR to the Apple Developer website to generate the certificate, download it and install it on the MAC. You can see the private key in the Keychain application and export the private key for decryption.

The ApplePay certificate generation process is described on the official website and the website.

Engineering configuration and certificate use

As can be seen on the Website of Apple Developer account, each Apple Pay certificate corresponds to and is associated with a MerchantId, and each Apple Pay certificate corresponds to a set of key and a set of payment and deduction channels in the actual use process. When the PaymentToken encryption is issued by Apple, it is found the corresponding MerchantId public key for encryption according to the APP calling API.

When a client calls ApplePay API, it needs to specify the MerchantId certificate. It is recommended not to write the client dead locally, preferably delivered by the server, to make it flexible and configurable, so that the payment channel can be switched.

After the certificate is generated, you need to enable Apple Pay in the Targets Capability of the Xcode project file, and select MerchantId corresponding to the certificate. Otherwise, the IPA of the APP installation package displayed cannot call up the Payment page of Apple Pay.

The location of the option is shown in the figure below:

The Apple Pay certificate is time-sensitive and will expire after two years. You need to change the key. For details about how to handle certificate expiration, see the Apple Developer website.

When you replace the certificate on the page shown in the following figure, bind a new CSR to generate a new certificate, Activate, and switch to the new certificate mode.

Revoke the old certificate after verifying that the certificate is ok online.

During the certificate update process, the online APP client does not need to adjust, and the certificate keys are configured on the server. In order not to affect the user payment process, the APP server needs to temporarily disable Apple Pay during the certificate replacement, and then enable it after the new certificate key takes effect.

5. Some differences and precautions between domestic and international ApplePay access

Ctrip Pay was the first to access The Apple Pay channel of China UnionPay, using unionPay SDK mode.

This SDK mode means that China UnionPay pays for the APP using Apple Pay by providing SDK externally. The specific SDK and instructions can be downloaded from the Development website of China Unionpay.

The advantage of using SDK is that the client access is simple, just call the INTERFACE of SDK to handle the callback of payment results, and the client does not need to deal with various exceptions. When UnionPay SDK calls, a TN number needs to be passed, which is generated by UnionPay. This TN number corresponds to a transaction, and must be passed when APP calls UnionPay SDK.

The disadvantages of using SDK mode are:

1. The IPA installation file packaged by APP has a great impact. For Ctrip APP, which has a high requirement on size, the size of UnionPay SDK accounted for a large proportion of payment. The reason should be the SDK of UnionPay, which also contains its own communication and other frameworks.

2. When the whole APP requires SPECIAL support such as Https or ipv6, the APP relies heavily on unionPay SDK, so it needs to communicate and confirm with UnionPay to ensure that the SDK supports UnionPay.

3. In SDK mode, both certificate and key are generated by UnionPay. APP development generates Apple Pay certificate with CSR file provided by UnionPay and binds it.

4. The page display of Apple Pay is completely controlled by unionPay SDK. When adding display items, it is necessary to seek external support from UnionPay SDK.

Later, Ctrip Pay changed its access mode and used API mode instead of SDK mode to access UnionPay Apple Pay. In this way, for access merchants, certificates and keys are managed by access merchants themselves, and they no longer rely on payment suppliers. Client and server development are more flexible.

In this way, iOS developers need to control and handle the UI display and interaction of Apple Pay themselves, and deal with the following exceptions:

1. In some scenarios, the user clicks the cancel button to cancel the Apple Pay operation when the user is sending the deduction request after verification. In this scenario, certain schemes and strategies should be adopted to avoid overcharging the user.

2. As with other payment methods, consider how to deal with the problem of duplicate order submission under unusual circumstances.

More security checks: In the actual project, after decrypting the data of Apple Pay, we did not see the amount, so we tried to give random discount to the user directly. When the payment amount submitted to the UnionPay server was inconsistent with the amount shown to the user in the APP, we found that the payment could not be deducted successfully, so we can conclude that: There must be a checksum mechanism between Apple and the payment suppliers. The APP cannot deduct any amount over the user’s head, and must display the amount on the Apple Pay page.

In the subsequent international Apple Pay access, Ctrip connected Adyen and SoftBank Payment Service respectively. The Apple Pay certificates required by these two channels are ECC encryption, which is different from China UnionPay.

In addition, when Adyen is connected, the certificate is generated by Adyen, and encryption and decryption are processed by Adyen. SoftBank’s certificate generation, encryption and decryption need to be completed by Ctrip Pay itself, so Ctrip Pay needs to do different processing for different payment channels after obtaining the PaymentToken.

When the international version of Apple Pay is actually called, the APP server uses different payment channels according to different currencies. The API of Apple Pay supports the specified certificate MerchantId, when entering the payment, The APP client calls Apple Pay according to MerchantId delivered by the server. In this way, you can make payments in different currencies using different certificate channels.

In addition to the certificate channel being configured for service delivery, the international Version of Apple Pay is more complex than the Chinese version. Different business scenarios require different bank channels to be supported. In a similar way, APP controls the support and display of Apple Pay according to the card channels issued by server control, such as Visa and MasterCard.

Six, summarized

In iOS development, access to Apple Pay is not just a simple API call and display, but also needs to consider some behaviors and interactions of users. Any payment process is the same, and should be responsible for user experience and property. In order to fully consider all possible anomalies and how to avoid and solve them, a more comprehensive design is needed on the whole.

Apple Pay requires close cooperation between clients, servers, card issuers, payment providers and Apple. Through my participation in the development of Apple Pay and my in-depth understanding of the security of Apple Pay, I can find that Apple really pays attention to details and has many ideas and designs worth learning. In the payment process, how to ensure security and give users an extremely simple experience, Apple really did.

【 Recommended reading 】

  • “Guess what you think, answer what you ask”, Ctrip intelligent customer service algorithm practice

  • Data prediction and monitoring in the eyes of a data analyst

  • Application of the idea of alignment with business logic in interface testing

  • In ctrip internationalization process, is how to do site multi-language processing?

  • Architecture and practice of Meteor real-time computing platform