Accept a mobile wallet payment

On this page

Apple Pay

Prerequisites

New gateway does not provide guidance for the frontend Apple Pay integration. Please refer to the Apple developer documentation links given below.

To pass payment request to gateway, the Partner/Merchant needs to generate a REST API key. The REST API key is used to generate SHA-256 hash of the JSON payload to be sent in the REST HTTP header message for each request.

You must use the Apple PassKit Framework, which is provided by Apple, to request the encrypted payment data from the device. This data can then be used in a gateway request.

Warning

Payer Authentication (3DS) is not required for Apple Pay authorizations, since Apple Pay provides Strong Customer Authentication.

Apple Pay integration

Apple Pay integration for iOS browser

The payment workflow for Apple Pay payments in the iOS Safari browser is very similar to payments in a mobile application.

You use the Apple Pay JavaScript to request the cardholder’s payment data from the device in the form of a PKPaymentToken structure, also known as a payload. The Secure Element of the Apple device creates the PKPaymentToken and sends it back to your application using the onpaymentauthorized call-back function.

The customer authentication for iPhone, iPad and MacBook Pro is provided via Touch ID / Face ID, or in the case of other Macs, Touch ID is provided with the customer's nearby iPhone, or Apple Watch that supports Apple Pay.

Process flow

The following diagram and description illustrate the high-level flow of an Apple Pay payment with gateway decryption option.

Steps involved in the process:

  1. Customer places an order using Apple mobile device or browser and confirms payment via TouchID or FaceID.
  2. Apple mobile device generates the payload and sends it to your server.
  3. You receive payload from the mobile device.
  4. You create a REST API request, using the payload as one ofthe request parameters and send the authorization request on dedicated Transacting MID.
  5. Gateway decodes the payload using the private key.
  6. Gateway creates an authorization request to the Banking network.
  7. Issuing Bank grants or declines authorization and sends response back to gateway.
  8. Gateway sends the response to your server.
  9. Your server sends the response to the customer’s Apple mobile device.

Apple Pay follow-on transactions workflow

Apple Pay follow-on acions are:

  • Authorization reversal
  • Capture
  • Void

These actions are the same as card payments transactions and do not require any additional fields. All transactions use the requestID parameter from the previous transaction.

Apple Pay profile configuration

To enable Apple Pay on your gateway MID:

  1. Log in to Enterprise Business Centre (EBC) and select Payment Configuration-> Digital Payment Solutions from the side bar menu.

  2. Click the CONFIGURE button next to Apple Pay.

  3. In the Apple Merchant ID input field, provide your Apple Merchant ID you registered in Certificates, Identifiers & Profiles of the Member Center on the Apple website and then click GENERATE NEW CERTIFICATE SIGNING REQUEST button.

If you are going to use gateway decryption, you need to download the Certificate Signing Request (CSR) and then submit it to Apple. Apple will provide you with an Apple Pay Certificate for your Apple Merchant ID.

The generated Certificate Signing Request (CSR) contains an identifier and a public key, which will be used to encrypt sensitive payment information on the customer device, before sending this information to your server. The private key is stored in Gateway Platform and used for decryption. You will not have access to this private key.

  1. Click on the Download icon to download text file with CSR.

Below is a CSR file example generated in EBC:

-----BEGIN CERTIFICATE REQUEST----- 
MIIBEzCBugIBADBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKV2FzaGluZ3RvbjENMAsGA1UEBww
EVklTQTENMAsGA1UECgwEVklTQTEYMBYGA1UECwwPQ3liZXJzb3VyY2UuY29tMFkwEwYHKoZIzj0
CAQYIKoZIzj0DAQcDQgAEw1X8GlV1LaNZqaxOSugx +D5Ids2XOHXz/6ylgxzFyh/eJcDzIDReT
yLkARolX613VyPVJnPDLyALstfC5XzzdDAKBggqhkjOPQQDAgNIADBFAiEA+nRaAHQYNp7QvY4u
UCUNaif2z+FZMMBbeFOM zT3pl1ICIGSmMdgzWsDzo/+cztZsMu9JLfoeLu/ltvgJDwqjeQCY 
-----END CERTIFICATE REQUEST----- 

The downloaded CSR will be in .txt format.

To create the payment processing certificate for Apple Pay,

  1. In your Apple developer account, select the appropriate Apple merchant identifier.
  2. Under Apple Pay Payment Processing Certificate, select Create Certificate and then choose file.
  3. Select the CSR downloaded from EBC2 to upload to Apple and click continue.

The payment processing certificate can now be downloaded for use.

If you are implementing Apple Pay for use in a browser, you will need to validate the domain of your web page. This involves registering the domain of your web page with Apple and hosting a Merchant Identity Certificate provided by Apple. You need the CSR to create the Merchant Identity Certificate.

Note

You will need different CSR files and certificates for Test and Live environments.

Google Pay

Google Pay is a simple, secure way to capture payment card details for in-app mobile and web applications. The Google Pay SDK services (provided by Google) are called to allow the customer to select their preferred card from their wallet.

Prerequisites

New gateway does not provide guidance for the frontend Google Pay integration. Please refer to the Google developer documentation links given below.

You must use the Google Pay SDK, which is provided by Google, to request the encrypted payment data from the device. This data can then be used in a gateway request.

To pass payment request to gateway, the Partner/Merchant needs to generate a REST API key. The REST API key is used to generate SHA-256 hash of the JSON payload to be sent in the REST HTTP header message for each request.

Google Pay integration

Process flow

The following diagram and description illustrate the high-level flow of a Google Pay payment with gateway decryption option.

Steps involved in the process:

  1. The customer chooses the Google Pay button. Using the Google API, your system initiates the Google Pay request identifying your payment gateway and your payment gateway merchant ID.
  2. The customer confirms the payment. The Google API contacts Google Pay services to retrieve the consumer’s payment parameters.
  3. If the customer selected payment credentials that are tokenized or are tokenizing new payment credentials, the Google Pay service contacts the appropriate payment network to retrieve the appropriate cryptogram.
  4. The payment network returns the appropriate token and cryptogram to the Google Pay service.
  5. Google creates encrypted payment data using the gateway-specific key that is supplied in the Wallet request and includes it in the Google API response.
  6. The Google Pay call back returns the encrypted payment data.
  7. Your system prepares the Google Pay response information for submission to gateway.
    1. Gateway sends the authorization request to the acquirer.
    2. The acquirer processes the request from gateway and creates the payment network authorization request.
    3. The payment network processes the request from the acquirer and creates the issuer authorization request.
    4. The issuer processes the request from the payment network. The issuer looks up the payment information and returns an approved or declined authorization message to the payment network.
    5. The payment network returns the authorization response to the acquirer.
    6. The acquirer returns the authorization response to gateway.
  8. Gateway sends the response to your server.
  9. Your system returns the authorization response to the payment application.
  10. The payment application displays the confirmation or decline message to the customer.
    1. The acquirer submits the settlement request to the issuer for funds.
    2. The issuer supplies the funds to the acquirer for the authorized transactions.

Google Pay follow-on transactions workflow

Google Pay follow-on actions are:

  • Authorization reversal
  • Capture
  • Void

These actions are the same as card payments transactions and do not require any additional fields. All transactions use the request ID parameter from the previous transaction.