a first data white paper payeezy.com security in apple … blog, developer support and the ability...

Unlike wallets of the past that saw weak consumer engagement, demand for Apple Pay is being driven directly by consumers. Today, developers are seeing the advantages of engaging in in-app development for Apple Pay and, in particular, coding apps using the Payeezy.com platform.

A First Data White Paper

Payeezy.com Security in Apple PayTM In-App Development

firstdata.com ©2014 First Data Corporation. All rights reserved. 2

A First Data White Paper Payeezy.com Security in Apple PayTM In-App Development

IntroductionNever before has the timing been so right to bring everyone together in the payments

ecosystem and open a new world of possibilities.

It’s an exciting time for consumers because convenient payment options are now built right

into Apple’s newest devices. Unlike previous attempts to introduce mobile payments/wallets,

Apple has taken a consumer-centric approach to address mobile payments that includes

participants from all over the ecosystem: card associations, banks, payments processors,

mobile carriers, and more.

What does this mean for consumers?

Ubiquity—and the expectation that merchants everywhere should start accepting

mobile payments.

It’s also an exciting time for developers. When Apple Pay™ debuted on October 20, 2014,

media hype concentrated mostly on in-store use with contactless terminals. However, in an

interview with the Wall Street Journal, Apple SVP Eddie Cue stated that they expect most

of their early transactions to be in-app.1

Apple Pay in-app payments don’t require the NFC chip that in-store Apple Pay payments

require. But in-app payments do require Apple’s TouchID. Consumers using in-app with

Apple Pay can pay for items by using a single touch on their device’s fingerprint sensor. This

alleviates the previous time-consuming processes that required users to create an account

and register a credit card.

Five companies originally partnered with Apple to provide the API and SDKs necessary to

develop in-app payment solutions for Apple Pay. First Data built an Apple Pay developer

portal on Payeezy.com and was the first of the five to launch.

Payeezy.com provides all the tools necessary to successfully incorporate payments in an

app, set up a merchant account on behalf of your client and swiftly get paid. To make that

happen, Payeezy.com provides the iOS SDK, RESTful API, sample code, a knowledge base,

developer blog, developer support and the ability to test and certify apps coded for Apple

Pay payment processing.

1 Wakabayashi, D. a. (2014, October 20). Apple Pay Rolls Out, With Limits. Wall Street Journal.



How Apple Pay In-App Payments WorkFor payment integrations that are created from APIs on the Payeezy.com site, or any of the other payment providers, the process of how in-app payment generally works is the same from Apple’s prospective:

Apple first receives encrypted transaction information and re-encrypts the information with a merchant-specific key before sending it to the merchant. Only anonymous transaction information is retained by Apple Pay. Even what the user is purchasing is not retained.

When an app requests a payment, it calls an API to determine information such as whether the device supports Apple Pay, if the user has credit cards that work on a payment network accepted by the merchant, and other pieces of information it needs to conduct the transaction. Next, the app requests iOS to present the Apple Pay payment sheet. The full set of information requested by the app isn’t provided until the user authorizes the payment with Touch ID or the device passcode. Once authorized, the information presented in the Apple Pay payment sheet will be transferred to the merchant.

The Apple Pay in-app payment process requires a cryptographic nonce which is different from the in-store payment process of obtaining a value returned by the NFC terminal. The app calls the Apple Pay Servers to obtain the cryptographic nonce. The nonce and other transaction data is passed to the Secure Element that generates a payment credential that will be encrypted with an Apple key.

The Secure Element then passes it to the Apple Pay Servers, which, in turn:

• decrypt the credential

• verify the nonce in the credential against the nonce sent by the Secure Element

• re-encrypt the payment credential with the merchant key associated with the Merchant ID.

• returns it to the device and the app via the API where the app sends it to the merchant system for processing.

The merchant can then use its private key to decrypt the payment credential for processing.



payment gateways including First Data with the TransArmor® solution. This type lets users put credit cards on file and can be referred to as “gateway-side” tokenization.

The defining characteristic of these tokens is that they’re scoped to a single merchant. They’re useful for a developer who wants to keep a credit card on file to enable low-friction transactions. But they don’t have the burden of securing and maintaining a database of PANs and the associated compliance issues.2

A New Standard in TokenizationGateway-Side TokenizationHowever, there are some differences between how in-app solutions have traditionally processed payments and a new standard in tokenization with Apple Pay that are important to understand

Most eCommerce developers are familiar with the concept of credit card vaults, which receive the PAN and replace it with a token to use instead. Many of the most popular providers use these vaults in their

Here’s the authorization flow when a gateway-side token is used:

App Site

$10 Sale $10 Sale $10 Sale

$10 Sale

Token

Token Vault

Token

PAN

PAN

PAN

PAN

Gateway AquirerProcesser

Payment Network

Issuer Platform

Gateway-Side Tokenization

First Data has participated in gateway-side tokenization for years, not only for TransArmor, but also in how the company processes most web- and mobile-type transactions.

2 Beatty, J. (2014, September 9). How Apple Pay works and why it matters for developers. Clover Developers Blog. Retrieved from http://clover-developers.blogspot.com/2014/09/apple-pay.html



Network-Level TokenizationWith the onset of Apple Pay, a new form of tokenization emerged; one that is closely associated with EMVTM, and that payment networks such as Visa®, MasterCard®, American Express®, etc. built. This new form is referred to as “network-level” tokenization.

More on EMVCo specifications can be downloaded here: EMV Payment Tokenisation Specification – Technical Framework.3

Here’s the authorization flow when a network-side token is used:

Network-Side TokenizationFirst Data, through its partnership with Apple in the launch of Apple Pay, is intricately involved with network-level tokenization. Payeezy.com and, as a result, any developer coding in-app solutions on the Payeezy.com platform uses network-level tokenization.

Network-level tokens are very different. They are essentially aliases for PANs that are exchanged during an authorization by the network. These tokens are provisioned (see below) into the secure element on the iPhone 6 and used in authorization flows (further protected with 3-D Secure — see above).4

3 EMVCo. (2014). EMV® Payment Tokenisation Specification - Technical Framework. EMVCo.4 Beatty, J. (2014, September 9). How Apple Pay works and why it matters for developers. Clover Developers Blog. Retrieved from http://clover-

developers.blogspot.com/2014/09/apple-pay.html

App Site

$10 Sale $10 Sale $10 Sale

$10 Sale

Token

Token Vault

Token Service Provider

Token

Token

PAN

Token

PAN

Gateway AquirerProcesser

Payment Network

Issuer Platform



Key Takeaways for Network-Side Tokenization

They look like standard PANs -- e.g. they’re 16 digits. They’re mostly compatible with the existing payment processing infrastructure.

The tokens are issued within a special BIN in the network’s routing tables that flag it as a token rather than standard PAN.

They are exchanged via the network by Token Service Providers, a new role in the ecosystem.

They are provisioned via a Token into a secure element of a mobile device or some other “secure enough” storage (perhaps Android HCE), facilitated by the issuing bank.

This is the typical way that a developer would provision a token:

Token Provisioning

Site or App

PAN, Exp, CVV, AVS PAN

TokenToken Vault

Token

Payment Gateway

Payment Network

Validate Card

As network-level tokenization evolves to other development outside theApple Pay ecosystem, First Data will continue to be a leader.

For more on tokenization, refer to: A Primer on Payment Security Technologies: Encryption and Tokenization5

5 McMillon, T. H. (2011). A Primer on Payment Security Technologies: Encryption and Tokenization. First Data.

Key Takeaways for Network-Side Tokenization



3-D Secure3-D Secure™ is the way network-level and EMV tokenization is supported on Payeezy.com.

3-D Secure is an XML-based protocol developed by Visa and marketed as Verified by Visa. A version was adopted by MasterCard under MasterCard® SecureCode™, by JCB International as J/Secure™, Diners Club as ProtectBuySM and American Express as AMEX SafeKey®. It is the on-line counterpart to in-store EMV solutions to prevent fraud.

On Payeezy.com, 3-D Secure provides authentication from the issuing bank to use the token that has been provisioned onto the iPhone. To explain, the JSON Dictionary holds encrypted payment information including:

• TypeAwhichspecifiesanApplePaytransaction

• Thepublickeycertificatecorrespondingto the merchantIdentifier set on the original PKPaymentRequest Refer to Apple Pay™ documentation.

• Thecryptographicalgorithmsusedtosignand encrypt the payload. Refer to Apple Pay™ documentation

• Additionalinformationneededtodecryptandverify the payment.

The code below shows you what a transaction message to a gateway looks like before 3-D Secure and after 3-D Secure:

Without 3-D Secure

{

“merchant_ref”: “Astonishing-Sale”,

“transaction_type”: “purchase”,

“method”: “credit_card”,

“amount”: “1299”,

“currency_code”: “USD”,

“credit_card”: {

“type”: “visa”,

“cardholder_name”: “John Smith”,

“card_number”: “4788250000028291”,

“exp_date”: “1014”,

“cvv”: “123”

}

}

{

“merchant_ref”:”merchant-specific-info (This is optional)”,

“transaction_type”: “purchase”,

“method”: “3DS”,

“3DS”: {

“type”: “A”,

“version”: “EC_v1”,

“merchantIdentifier”: “mock-1”,

“applicationData”: “VGhpcyBpcyBzb21lIHRlc3QgZGF0YS4gIDAxMjM0NTY3ODk=”,

“data”: “v6cqGDrjcJUCLdpRkSQIt...”,

“signature”: “AKCAMIIBoTCCAUgCAQEwCQYHTBFMQswCQYDVQQGEwJVUzE...”,

“header”: {

“applicationDataHash”: “4b5745dd55d72886c06a2c65bb05...”,

“ephemeralPublicKey”: “MFkwEwYHKoZIzj0CAQYIKoZIzj0D...”,

“publicKeyHash”: “YmSWN7lj4+A6fVJVPicP8TgS7gI7oug...”,

“transactionId”: “34303833303938”

}

With 3-D Secure



Certifying an App On Payeezy.comThere are three levels of developer engagement on the developer portion of Payeezy.com:

1. Anonymous

2. Registered

3. Certified

At each level, developers gain increasingly more access and capability.

AnonymousAnonymous is just like it sounds. Developers at this level have an un-registered, anonymous account with the following resources:

The Apple Pay SDK Starter Kit:

Downloadable files and code needed to start creating an app

Sample Project Access a sample project (named SampleCharge) in XCode to get hands-on familiarity with the code that drives Apple Pay and Payeezy.

Frameworks First Data provides two frameworks that you can drop into your project to start accepting Apple Pay transactions:

• InAppSDK.framework—EnablesyourapptocommunicatewiththeiOS device. Masks the complexity of dealing with Apple APIs.

• PayeezyClient.framework—iOSclientfortheAPI.Enablesthehandshake with First Data through HTTP calls to the Payeezy API

Developers at the anonymous level also have full access to Payeezy.com support, forums, FAQ area and the Payeeyz.com blog. This includes the ability to ask questions, get answers, get tips, see what’s new with Payeezy and Apple Pay and learn about upcoming events.



Registered

For more functionality including the ability to test accounts, a developer has to move to the registered level. This is provided through the “Register Now” link on the developer.payeezy.com site. This level requires developers to provide a name and email address.

Once the account is set up, three of the four credentials needed to get started developing an Apple Pay-enabled app are provided: an API Key, an API Secret and a Merchant Token. These credentials allow the developer to set-up a test account by clicking on “My APIs”.

Payeezy.com Sandbox*Registered Payeezy.com developers can access the sandbox, which mimics a live Apple Pay production environment

Create a set of test accounts

Format your Payeezy API requests using your API Key, API Secret, Merchant

Token and Apple Pay Merchant ID

Run tests against the Payeezy API

Review the responses and modify your code as necessary

The fourth credential, an Apple Merchant ID, allows the ability to generate the Certificate Signing Request that Apple requires. This step can be complete only after registering on developer.payeezy.com.

To obtain an Apple Merchant ID:

1. Go to developer.apple.com and log into your developer account.

2. From the Member Center, navigate to Certificates, Identifiers & Profiles.

3. Go to the Register Merchant IDs section. Your Merchant ID is located in the Identifier field.

4. Click Done

At this point, the developer has full ability to code, create and test an Apple Pay-enabled app.



Certified

Developers should fully test their app to determine that it is working and bug-free before moving to the self-certification step. Then it is time to certify the app and start boarding merchants.

To Certify an App on Payeezy.com

1. Log in to developer.payeezy.com

2. Navigate to “Get Certified”

3. Complete the form

4. First Data will validate the app’s transactions and identify any issues

5. If everything is performing properly, certification is issued

After a developer certifies an app, there are three steps that need to be taken before payments can start being accepted on the Apple Pay payment platform.

1. Add Merchants

2. Generate a Certificate Signing Request

3. Submit the Certificate Signing Request to Apple



These steps are outlined below:

To Add Merchants on Payeezy.com

1. Log in to developer.payeezy.com.

2. Navigate to “Add Merchants”

3. Answer the question “Are you the Merchant?” If you are acting as a merchant select “Yes”. If you will be adding merchants who will use your app, select “No, I’m adding other Merchants”

4. If you plan to use Apple Pay in your app, check the “Enable this Merchant for Apple Pay” checkbox

5. Select “Submit” and you will be taken to the Notify Merchant screen

6. Enter the contact information about your Merchant and the captcha and select “Notify Merchant”. This will invite your Merchant to create a Merchant Account. You will be notified when your Merchant has completed the process. Log in to developer.payeezy.com.

Generate a Certificate Signing Request (CSR)

1. Log in to developer.payeezy.com.

2. Click on “My Merchants” from the top menu

3. If you have only completed the ‘lite’ registration, you will see the CSR as part of your test merchant account on the sandbox tab. If you have completed full registration/certification and are looking for the CSR for your specific merchant(s), select the “Live” tab. You will need the CSR to transact in either case (in sandbox or live)

4. Once you have identified the CSR you want to download, right click on it and select “Save As” and save the .pem file to your desktop where you can easily get to it later in the process

Submitting your Merchant Certificate Signing Request (CSR) to Apple

1. Login to your apple developer account

2. Go to “Certificates, Identifiers & Profiles” from the Member Center

3. Click “Edit” on the Merchant ID page and select “Create Certificate”

4. Follow the instructions on screen to upload and submit your CSR



CONCLUSION

In the context of the US market’s development, Apple Pay has arrived at a better time than Google Wallet and has a much better chance of wide-spread adoption.

New tokenization standards and the adoption of 3-D Secure technology are making the advantages of using Apple Pay clear in terms of security. With Apple Pay, the retailer only sees a token, but not which card or bank has been used. The retailer can’t store bank card details, email addresses or passwords because it simply does not get them in the first place. Companies like First Data, through their developer portal on Payeezy.com, are paving the way in creating cutting edge environments that utilize new security standards such as network-level tokenization and more.

Unlike wallets of the past that saw weak consumer engagement, demand for Apple Pay is being driven directly from the consumer level. Increased privacy and better fraud control have great appeal to a market shell-shocked by repeated news of data security breaches at major retailers.

Uncertainties do exist, with disadvantages voiced by some of the larger retailers as well as from companies like Google. Concerns about the inability to track purchases or the use of loyalty card solutions top the list. They point to Apple Pay’s lack of global availability. Though alternative contactless systems have long since been adopted in other parts of the world, Apple Pay isn’t scheduled to work outside the United States until 2015. As a result, some experts and research firms, such as Juniper, predict that Apple Pay will only have a small share of the market by 2019.

However, developers are seeing the advantages of engaging in in-app development for Apple Pay and, in particular, coding apps using the Payeezy.com platform. Driven by an exploding app market - app analytics firm Distimo states in-app purchases represents 92% of the $10 billion consumers spent in the Apple App Store in 2013 - developers are rushing to engage with companies such as First Data who are seen as leading the way in enabling the creation of in-app solutions on Apple Pay.

For more information, contact your First Data Representative or visit firstdata.com

152

00

12

14

6 Agten, T. v. (2013). Games: King of the mobile eco-system. Distimo.

This White Paper is for informational purposes only. FIRST DATA MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS WHITE PAPER. First Data cannot be responsible for errors in typography or photography.

First Data, Payeezy, and Payeezy.com are trademarks of First Data Corporation. All trademarks, service marks and trade names reference in this material are the property of their respective owners EMVTM is owned by EMVCO LLC. Apple and iPhone are trademarks of Apple Inc., registered in the U.S. and other countries. Apple Pay is a trademark of Apple Inc. EMVTM is a trademark owned by EMVCo LLC.

Other trademarks and trade names may be used in this document to refer to either the entities claiming the marks and names or their products. First Data disclaims proprietary interest in the marks and names of others.

Information in this document is subject to change without notice.

a first data white paper payeezy.com security in apple … blog, developer support and the ability...

Documents