Apple Pay on Payeezy Gateway Hosted Checkout


This guide takes you through the process of setting up Apple Pay on a Hosted Checkout Payment Page.

Apple Pay allows an HCO Payment Page to use the payment details that your customers have stored in their Apple Wallet to perform online payments.


If your customers are using Safari on their Mac, iPhone or iPad and they select the Apple Pay button on the HCO Payment Page, they will see Apple’s payment sheet. From a Mac using Safari, their iPhone or Apple Watch will ask them to authorize the payment. A Mac with Touch Bar allows customers to directly use the Touch ID to make payments, instead of having a device in range. If you are a Payeezy Gateway merchant, the underlying advantage of this Apple Pay integration is that a single HCO Payment Page will allow you to offer Apple Pay on the Web as well as other payment methods to your customers.


Before using this feature, please review and ensure compliance with the Apple Pay Platform

Web Merchant Terms and Conditions:


Apple Pay Data Flow for HCO


Enabling Apple Pay on a Payment Page

An RPM user with the Merchant Admin role has the option to enable Apple Pay in the Payment Types section of the Payment Page Settings. By default, the feature is disabled. The “Apple Pay Platform Web Merchant Terms and Conditions” must be reviewed and accepted for the feature to be enabled.


The following screenshot from the Payment Page Settings shows the check marks that a Merchant Admin would have to accept in order to be able to use Apple Pay:


Please note that when Apple Pay is enabled on the Payment Page Settings, the Apple Pay button will not be visible on a preview of the Payment Page unless the RPM user follows the requirements described in the section below.


Testing using Payeezy Gateway Demo environment

The Payeezy Gateway Demo environment is connected to Apple Pay Sandbox and can be used to test the Apple Pay feature.

The tester should have the following setup:


Please refer to Apple Pay Sandbox documentation on how to prepare for testing and add Test cards.

Setup and requirements to be met by the cardholder 

Assuming that Apple Pay is correctly set up to be used with an HCO Payment Page by the merchant, a cardholder will be able to perform a payment transaction with the Apple Pay button on an HCO Payment Page only if all of the following conditions are met:

  • A supported Apple device is used (supported devices).
  • A valid Apple ID is used to sign in to the Apple device (signing in to iCloud).
  • An Apple Pay compatible version of the Safari browser is used by the cardholder and it is compatible with the merchant’s website.
  • A supported version of an Apple Operating System is correctly installed in the Apple device (iOS, watchOS, macOS).
  • A credit card from a supported card issuer is successfully added to the Apple Wallet and can be used for the transaction (supported card issuers). In case there is no card added to the Apple Wallet, the customer is then given the option to add a new card.

To know more about Apple Pay setup process for the cardholder, please refer to:


Cardholder payment processing flow via an HCO Payment Page

If Apple Pay is correctly set up to be used with an HCO Payment Page by the merchant and if the cardholder meets the technical requirements listed above, he/she will be able to select the Apple Pay radio button. If the Apple Pay button is not visible when it should, then it means one or several technical requirements are not being met by the merchant, the cardholder or both.


After the Apple Pay radio button is selected, a new Apple Pay button will appear on the HCO Payment Page:


If the cardholder clicks on the new Apple Pay button, he/she will be presented with the Apple Pay sheet, which appears on top of the Payment Page and where it is possible to select or add a credit card, as well as to select or add a billing address


If the transaction is canceled, the cardholder will return to the HCO page. If the cardholder authorizes the transaction, this will be processed and the rest of the screen/receipt flow will be the same as it is for regular credit card transactions (i.e., it will be defined by the merchant integration options on the HCO Payment Page Settings; for more information, please refer to the Hosted Checkout Payment Pages Integration Manual).

Real Time Payment Manager (RPM) Transaction Details

In the RPM transaction details, an APM (Alternative Payment Method) column can be used to easily identify Apple Pay transactions. You can turn the APM column on within the Transactions Tab, Sub-Tab Preferences. Select APM and use the left arrow (←) to move the APM to the “Columns To Show” then click on “Save”.


In the RPM Transaction Details, a new row of information has been added to describe the APM used in the transaction, including the name of the APM and its ID.



Notes on the card number and the cardholder name of an Apple Pay transaction


Apple Wallet uses a tokenized version of the cardholder’s credit card to perform payments. This token is a 16-digit number called the “DPAN” (Device Primary Account Number). One consequence of this is  that the last four digits of the DPAN used in an Apple Pay transaction in the RPM transaction list will most probably not correspond to the actual last four digits of the cardholder’s credit card. Besides, since the DPAN is related to the device, the same credit card will generate a different DPAN in each Apple device.

Apple Pay can provide the card holder’s first and last name for a transaction if this data is available in the Apple Wallet. If it is not, the cardholder name used for the transaction will be the content of the x_first_name and x_last_name fields sent by the merchant in the HCO Payment Form. If this information is also missing, a generic cardholder name will be used for the transaction.


Compatibility of Fraud Filters with Apple Pay


Apple Pay is compatible with Payeezy Gateway Fraud Filters. However, it is important to mention that, in order to work along with Apple Pay, Fraud Filters must use the corresponding DPAN, not the actual credit card number. For example, an existing negative fraud filter created using a regular credit card number will not work with Apple Pay; it would have to be recreated through the transaction list of RPM (which will use the DPAN).

Powered by Zendesk