Card Processors

To add or edit a Realex Card Processor, follow these steps:

1. Go to Payment Processing > Card Processors on the left navigation.
2. To create a new Card Processor, click the Add New Card Processor button at the top of the page.
   To edit an existing Card Processor, click the Edit button at the right side of the Card Processor you wish to update.
3. Enter or edit the following details:

   Card Processor Details tab

   Setting	Description
   Card Processor Details
   Card Processor ID	The ID in the database associated with this Payment Processor. This is added automatically by the IRP.
   Active	Whether or not this Payment Processor is to actively process payments on the website. When enabled, the website will actively try to use this Processor for any payments which match the card and transaction details being processed. When disabled, the website ignores this Processor. However, you can still test it using the Test button on the previous page.
   Provider	Select the Payment Gateway Provider, in this case Realex Payments. This is the company you are using to provide online card payments for the website. Note that what you select here will change the settings that are available for you to configure on the rest of the screen.
   Admin Name	This is a reference you give to this Payment Provider within your IRP. It can be anything you wish.
   Merchant ID	Merchant ID is the overall account name you have with your Payment Gateway Provider. For example, with Realex Payments, this will be something like 'yourcompanyname'.
   Sub Account	The Sub Account is the name of the actual account under your Merchant ID that the payments go into. For example, with Realex Payments, the default value for this is 'internet'. However, you should fill in whatever your Payment Gateway Provider has given you.
   CurrencyISO	You should only set this if this Payment Processor account is going to be accepting payments from a single Currency only. In almost all circumstances, you can leave this at its default setting, 'All Unhandled Currencies'.
   Card Type	You should only set this if this Payment Processor account is going to be accepting payments for a single Card Type only. In almost all circumstances, you can leave this at its default setting, 'All Unassigned types'.
   3D Secure Enablement	Set the 3D Secure capabilities of this Card Processor: • 3D Secure and Non-3D Secure: This processor will process both 3DS and Non-3DS transactions (such as Telesales). Ensure that the '3D Secure Version' has been set in the drop-down below. • Non-3D Secure Only: This processor will only process non-3DS transactions, such as Telesales. Commonly known as a MOTO. • 3D Secure Only: This processor will only be used for 3DS transactions. Setting up a 3D Secure Only Processor usually coincides with an additional processor being used for Non-3D Secure Only transactions, such as Telesales.
   3D Secure Version	Select which version of 3D Secure is enabled for this processor (Version One or Version Two). Note: Contact Global Payments to ensure 3D Secure v2 and v1 are enabled on all your Merchant ID.
   Amount to Authorise if Out of Stock	This value is the amount the system will authorise on the Customer's card for when you are not charging for the Order at the time of purchase. It should be a very small value, usually one major currency unit, e.g £1, $1, etc.
   Shared Secret / Passwords
   Shared Secret	Shared Secret is the password given to you by your Payment Gateway Provider, usually over the phone, to enable you to process payments using this account.
   Rebate Password	Rebate password is given to you by your Payment Gateway Provider to enable you to process rebates. For example, with RealEx Payments, the default is 'refund'. It is highly recommended you change this with your Payment Gateway Provider.
   Refund Password	Refund password is given to you by your Payment Gateway Provider to enable you to process refunds. For example, with Realex Payments, the default is 'refund'. It is highly recommended you change this with your Payment Gateway Provider.
   XML Posting URLs
   Post Url	The standard URL your Payment Gateway Provider uses to accept the messages from the website. You should only change this if your Payment Gateway Provider has informed you this URL has changed.
   Post Url (3DSecure)	The URL your Payment Gateway Provider uses to accept messages specifically about 3D Secure transactions. You should only change this if your Payment Gateway Provider has informed you this URL has changed.
   Post Url (Redirect)	The URL your Payment Gateway Provider uses to accept messages specifically when you are using a 'Redirect' payment option. A 'Redirect' option means that the website does not actually take the credit card details from the customer when they are paying, but sends them to a page hosted with the Payment Gateway Provider. You should only change this if your Payment Gateway Provider has informed you this URL has changed.
   Post Url (Tokens)	The URL your Payment Gateway Provider uses to accept messages specifically about transactions dealing with tokenized payments. Tokenized payments mean that the Payment Gateway Provider is accepting responsibility for storing the card details, and the IRP simply stores 'tokens' which represent the details in the Provider's systems. This is more secure for your own systems. For example, Realex Payments solution for this is called RealVault. You should only change this if your Payment Gateway Provider has informed you this URL has changed.

   Digital Wallets tab – Apple Pay tab

   Setting	Description
   Apple Pay Details
   Apple Pay Enabled	Check this box to enable Apple Pay on this Card Processor. If checked, and if on an Apple Pay-enabled browser, an Apple Pay button will appear for this Card Processor if the Merchant Identity Certificate validates against your Domain.
   Merchant Identifier	Enter the Plain Text Apple Pay Merchant Identifier for this Card Processor - this is different to the value stored in your Apple Pay Merchant Identity Certificate, for example: merchant.website.com. (Your Account Manager or IRP Partner & Agency Manager can assist you with this information.)
   Domain Verification	Apple Pay requires a Domain to be checked by uploading a .txt to the root directory of your website - use the adjacent file uploader to upload this domain verification file to your IRP. Click the Click to Download button to download the Current Apple Pay Domain Verification File. (Your Account Manager or IRP Partner & Agency Manager can assist you with this information.)
   Allowed IP Addresses	When testing, you may wish to enable this Card Processor with Apple Pay for a set of IP Addresses. If so, add a comma-delimited list of IP Addresses you wish the Apple Pay button to be visible for. If you want this Card Processor to be Apple Pay enabled for everyone, leave this text box empty.
   Run in Test Mode	When this box is checked, Transactions will be sent to the Payment Processor with a Transaction Order ID of 'TEST-{unique value}'. This is so that Test Transactions can be easily identified in your Card Processor account. Test Transactions will only use the specified Test Amounts unless specifically set from the Simulator page.
   Merchant Identity Certificate
   Upload	Upload your Apple Pay Merchant Identify Certificate (.p12 file) here. This should be generated from a Mac with Keychain Access. (Your Account Manager or IRP Partner & Agency Manager can assist you with this information.)
   Current	This shows the current Merchant Identity Certificate (.p12 file) uploaded against this Card Processor.
   Password	The password (if any) attached to the Merchant Identity (.p12 file) Certificate. Leave blank if this certificate does not have a password. Click the Validate Certificate button to validate the certificate. (Your Account Manager or IRP Partner & Agency Manager can assist you with this information.)

   Digital Wallets tab – Google Pay tab

   Setting	Description
   Apple Pay Details
   Google Pay Enabled	Check this box to enable Google Pay on this Card Processor. If checked, and if on an Google Pay-enabled browser, a Google Pay button will appear for this Card Processor.
   Merchant Identifier	Enter the Merchant Identifier (from Google) for this Card Processor. Note that in Test Mode, this value will always be blank.
   Allowed IP Addresses	When testing, you may wish to enable this Card Processor with Google Pay for a set of IP Addresses. If so, add a comma-delimited list of IP Addresses you wish the Google Pay button to be visible for. If you want this Card Processor to be Google Pay enabled for everyone, leave this text box empty.
   Run in Test Mode	When set to true, Transactions will be sent to the Payment Processor with a Transaction Order ID of 'TEST-{unique value}'. This is so Test Transactions can be easily identifier in your Card Processor account. Test Transactions will only use the specified Test Amounts unless specifically set from the Simulator page.

4. Once you have entered all of these details, click the Insert Card Processor button or the Update Card Processor button to save the Card Processor.

Now that all of the required information has been entered, you should test the Card Processor connection. This is described in the How To Test a Card Processor guide.

To add or edit a Worldpay Card Processor, follow these steps:

1. Go to Payment Processing > Card Processors on the left navigation.
2. To create a new Card Processor, click the Add New Card Processor button at the top of the page.
   To edit an existing Card Processor, click the Edit button at the right side of the Card Processor you wish to update.
3. Enter or edit the following details:

   Card Processor Details tab

   Setting	Description
   Card Processor Details
   Card Processor ID	The ID in the database associated with this Payment Processor. This is added automatically by the IRP.
   Active	Whether or not this Payment Processor is to actively process payments on the website. When enabled, the website will actively try to use this Processor for any payments which match the card and transaction details being processed. When disabled, the website ignores this Processor. However, you can still test it using the Test button on the previous page.
   Provider	Select the Payment Gateway Provider, in this case Worldpay. This is the company you are using to provide online card payments for the website. Note that what you select here will change the settings that are available for you to configure on the rest of the screen.
   Admin Name	This is a reference you give to this Payment Provider within your IRP. It can be anything you wish, for example 'Worldpay - 3DS Enabled'.
   Merchant Code	This will be provided by your Worldpay Account Manager.
   Admin Code	This will be provided by your Worldpay Account Manager.
   Can Process 3D Secure	Determine whether this Card Processor is able to process 3D Secure transactions. For Worldpay, if you want to use 3D Secure, you must set up a 3DS Merchant Code as well as a non-3DS Merchant Code. The non-3DS Merchant Code will allow you to perform back-end charges in the IRP. Also you must ensure that the ECI and CAVV values are being returned in the Worldpay response XML. These values are particularly important for determining Fraud Scores.
   XML Posting URLs
   Post Url	The standard URL your Payment Gateway Provider uses to accept the messages from the website. You should only change this if your Payment Gateway Provider has informed you this URL has changed.
   XML Credentials
   XML Username	This will be provided by your Worldpay Account Manager.
   XML Password	This will be provided by your Worldpay Account Manager.
   Advanced Settings
   CurrencyISO	You should only set this if this Payment Processor account is going to be accepting payments from a single Currency only. In almost all circumstances, you can leave this at its default setting, 'All Unhandled Currencies'.
   Card Type	You should only set this if this Payment Processor account is going to be accepting payments for a single Card Type only. In almost all circumstances, you can leave this at its default setting, 'All Unassigned types'.
   Amount to Authorise if Out of Stock	This value is the amount the system will authorise on the Customer's card for when you are not charging for the Order at the time of purchase. It should be a very small value, usually one major currency unit, e.g £1, $1, etc. Note that for WorldPay Payment Processors this should be set to 0.00.

4. Once you have entered all of these details, click the Insert Card Processor button or the Update Card Processor button to save the Card Processor.

Now that all of the required information has been entered, you should test the Card Processor connection. This is described in the How To Test a Card Processor guide.

If you are testing a test connection, the Payment Gateway will be able to provide test card details. We advise that you perform tests for all card types enabled in the Card Types section.

If you are testing a live connection, you can use a personal/business card. We advise that you perform this test while speaking with your Payment Gateway Account Manager. This way they can monitor the payment traffic to determine success or failure.

Standard Card Test Transactions

To initiate a test for standard card test transactions, follow these steps:

1. Go to Payment Processing > Card Processors In the IRP Admin left navigation menu.
2. Click the Test button at the right side of the Card Processor that you wish to test. Note that you must first add a Card Processor as described in the How To articles.
3. Select the Standard Card Test Transactions tab.
4. Enter the following details:

   Setting	Description
   Card Processor	Select the Payment Processor to use when attempting a Standard Card Authorisation Transaction.
   Amount	Enter the Amount for this Standard Card Authorisation Transaction.
   Card Holder Name	The Name on the Card. For a Test Card, this can be any text string, e.g. test, your Name, your business, etc. For a Personal/Business Card, input the Name as printed on card.
   Card Number	Valid test/personal/business Card Number. For test transactions when your account is in test mode, generally certain card numbers will be reserved by your Payment Gateway Provider to trigger certain responses for the various card types. In other words, there will be card numbers for successful transactions, card numbers for declined transaction, etc.
   Card Type	Select the Card Type of the Card you are using.
   Expiry Date	The expiry date as printed on the card. For test transactions when your account is in test mode, you should set this to a date in the future.
   Security Digits	The card's three-digit CVV as printed on the back of the card. For test transactions when your account is in test mode, you can set this to any valid value for the card type you have chosen, usually 3 digits.

5. Click the Attempt Standard Card Test Transaction button at the bottom of the page to initiate the test. (The Currency of the Payment Processor being tested is sent along with the Request.) If the details you have entered are valid, you will receive one of two responses:
   
   If you have used a test card, the result will depend on the number you have used. Click on the ‘Click this link to view the response’ link to open the XML response in a new tab. Check that the <message> and <result> tags contain the expected results.
   
   The <message> tag result should correlate to the test card number used, e.g. Successful, Declined, Comms Error, etc. If using a Personal/Business Card, you should receive a Successful response.
   The RealAuth Response Codes document contains a list of result values and their associated meanings for the <result> tag.
6. A list of past transactions are displayed in the Test Transactions section. You can also view the XML responses for these transactions by clicking the View Response button at the right hand side of the transaction you wish to view the XML Response for.

Digital Wallet Test Transactions

To initiate a test for digital wallet transactions (Apple Pay and Google Pay), follow these steps:

1. Go to Payment Processing > Card Processors In the IRP Admin left navigation menu.
2. Click the Test button at the right side of the Card Processor that you wish to test. Note that you must first add a Card Processor as described in the How To articles.
3. Select the Digital Wallet Transactions tab.
4. Enter the following details:

   Setting	Description
   Type	Select Apple Pay or Google Pay.
   Card Processor	Select the Card Processor to use for the Digital Wallet Test Transaction.

5. Click the Apple Pay or Google Pay button to perform the test. The results will be shown at the bottom of the page in the Digital Wallet Test Transactions section. Click the More Details button to view a breakdown of the transaction.
6. You can enter the email address to which the Mobile Digital Wallet Simulator Link should be sent.

Apple Pay provides your customers with an easy, secure and private way to pay on your website. It is one of the newest and fastest forms of making payments.

Note: Currently Apple Pay is available only to Global Payments (Realex) customers.

For more information, visit the Apple Pay website. Also see the Apple Pay for merchants page.

Setting up Apple Pay

Setting up Apple Pay involves the following steps:

1. Before you start, work with your Account Manager and IRP Partner & Agency Manager to ensure that you have the necessary information to hand to complete the setup process, including the Merchant Identity Certificate and Password and Domain Verification file. Such information will be needed for Realex and for IRP Admin.
2. Switch on the feature in IRP Admin using the 'Enable Payment By Apple Pay' Application Setting (in the 'Payment' grouping).
3. Configure the Apple Pay settings on the PaymentProcessorEdit.aspx page. Note: You can use Apple Pay only if you have one or more active Global Payments (Realex) Card Processor(s). See How To Add or Edit a Realex Card Processor.
4. Check/confirm the value of the 'Apple Pay Supported Network' setting on the CardTypeEdit.aspx page. This value will be based on the Realex code and will be added to your system automatically. For example, for a Visa card, this value will be 'visa', for Amex, it will be 'amex' and so forth. See Card Types for more information.
5. Test the setup using the PaymentProcessorTestTransaction.aspx page and view transaction details on the PaymentProcessorTransactionDetails.aspx page. See How To Test a Card Processor.
6. Confirm how Apple Pay works on the Basket page (desktop & mobile) and on each of the other pages of the checkout (payment details, order summary, etc.). See the IRP Checkout Overview help topic for more information.
   NOTE: You will only be able to see the Apple Pay option in checkout if you are using an appropriate Apple device with a payment card in the wallet. According to the Apple Pay website, “When you're making purchases on the web in Safari on your iPhone, iPad or Mac, you can use Apple Pay without having to create an account, enter card details or fill out lengthy forms. Millions of merchants accept Apple Pay online. And with Touch ID on MacBook Air and MacBook Pro, paying takes just a touch and is quicker, easier and more secure than ever before.”
7. View order details on the Orders.aspx and OrderManage.aspx pages. You can use the 'Payment Method' search option with the 'Card - Apple Pay' filter to find the orders:
   
   See the Orders help topic for more information.

Google Pay 'opens up your business for more business'. Google Pay is a fast, simple way for customers to pay on your website and in store using the cards saved to their Google account. It protects the customer's payment information with multiple layers of security using one of the world's most advanced security infrastructures to help keep accounts safe.

Note: Currently Google Pay is available only to Global Payments (Realex) customers.

For more information, visit the Google Pay website.

Setting up Google Pay

Setting up Google Pay involves the following steps:

1. Register your domain with Google Pay and ensure you have a Merchant ID which you should send to IRP Commerce. For more information, see How to Register Your Domain with Google Pay below.
2. Ensure that Google Pay is enabled on all Realex accounts.
3. Switch on the feature in IRP Admin using the 'Enable Payment By Google Pay' Application Setting (in the 'Payment' grouping).
4. Configure the Google Pay settings on the PaymentProcessorEdit.aspx page. See How To Add or Edit a Realex Card Processor.
5. Check/confirm the value of the 'Google Pay Supported Network' setting on the CardTypeEdit.aspx page. This value will be based on the Realex code and will be added to your system automatically. For example, for a Visa card, this value will be 'visa', for Amex, it will be 'amex' and so forth. See Card Types for more information.
6. Test the setup using the PaymentProcessorTestTransaction.aspx page and view transaction details on the PaymentProcessorTransactionDetails.aspx page. See How To Test a Card Processor.
7. Confirm how Google Pay works on the Basket page (desktop & mobile) and on each of the other pages of the checkout (payment details, order summary, etc.). See the IRP Checkout Overview help topic for more information.
8. View order details on the Orders.aspx and OrderManage.aspx pages. You can use the 'Payment Method' search option with the 'Card - Google Pay' filter to find the orders:
   
   See the Orders help topic for more information.

How to Register Your Domain with Google Pay

To register your domain, proceed as follows:

1. Make sure you have a Google account with an associated email address. IRP Commerce collects a Google email address for each IRP customer using Google Pay. If you are in any doubt that you have a Google account associated with your email, you can link your existing email address with a Google account via this link. IRP Commerce provides Google with each Google email address for each IRP customer. Google will whitelist each provided Google email address for each customer and update the status to 'whitelisted'.
2. As a 'whitelisted' customer you should then complete the following steps:
   1. Log in to your whitelisted Google account.
   2. Access the Google Pay Developer Profile: https://payments.developers.google.com/signup.
   3. Complete registration.
   4. Register the domains that will call the Google Pay API in the 'Enable Websites' section.
3. Inform IRP Commerce when registration is complete and when your domain is registered. Make sure that you provide IRP Commerce with your specific Merchant ID value – see the following section.

Getting the Merchant ID

Proceed as follows:

1. Go to https://developers.google.com/pay/api/support.
2. In the 'Web Developers' section, click the link called 'Web documentation'.
3. In the 'Get started' section, click the link called 'Request production access to the Google Pay API' (Step 5).
4. Complete the form as required. Note the following specifics:
   1. For 'Tokenization Method', select Gateway.
   2. For 'Payment processor', select Global Payments (Realex).
   3. For 'Integration Platform Details', enter your website URL.
   4. For 'Merchant Name', use the name in IRP Admin.
   5. There is no requirement to add comments or to attach documents.
5. Click 'I accept'.

The AMEX configuration on the IRP side is dependent on how it is configured with RealEx. These are the key questions you need to ask RealEx regarding AMEX, as sub accounts must be set up for each account / currency combination:

1. In which currencies can I process AMEX transactions?
   1. GBP?
   2. EUR?
   3. USD?
   4. Others?
2. For each of the above currencies that I can transact in, what is the name of the sub account that I need to use?
3. For each sub account, please provide me with the following details (this is likely to occur over the phone):
   1. Shared Secret
   2. Rebate password
   3. Refund password

The following things should be in place in general:

1. If AMEX is accepted, there are usually at least two Payment Processors set up, one for standard cards, the other specifically for AMEX.
   1. In Payment Processing > Card Processors, the one for AMEX will usually have the column Currency as 'All Unhandled Currencies' and Card Type for 'American Express'.
   2. There should always be the default processor for all other cards which is Currency as 'All Unhandled Currencies', and Card Type as 'All Unassigned Types' – this processes payments in the site's default currency.
2. If there are other accounts set up to process different currencies for AMEX, there should be at least the following processors:
   1. Any currency not charging in (Default Site Currency), any card type nor specifically handled:
      1. Currency = All Unhandled Currencies, Card Type = All Unassigned Types
   2. Any currency not charging in (Default Site Currency), American Express card type:
      1. Currency = All Unhandled Currencies, Card Type = American Express
   3. Charging in USD, American Express card type:
      1. Currency = USD, Card Type = American Express
   4. This is then repeated for each currency that RealEx is configured to accept payments in.

(Point 1 is usually because it doesn't have to be if RealEx is set up to determine the right sub account for you in the background.)

Should a client have 3D Secure enabled, Payment Transactions against orders will look slightly different to clients without 3D Secure enabled. Instead of the 1 Auth Transaction, they will potentially have three Transactions.

Successful 3DS Orders go through the following process in the IRP:

Step 1: Determines Card is Enrolled in 3DS
Step 2: Verifies 3DS Password / Passcode Entry
Step 3: Processes Authorisation

A successful 3DS Order is illustrated by the example below:

Sometimes, if the customer is redirected to the Verification page, they will close their browser and not complete the Transaction. The order is therefore not completed and will sit in the New Awaiting Payment Authorization status – these Orders can be cleared out periodically by enabling the Delete Abandoned Card Orders Common Task Type. An illustration of this example in terms of Payment Transactions can be seen below:

If a Customer enters an incorrect password / passcode on the Verification page, the Verification Transaction will be false, the order will not be completed and will sit in the New Awaiting Payment Authorization status – again these orders can be cleared out periodically be enabling the Delete Abandoned Card Orders Common Task Type. An illustration of this example in terms of Payment Transactions can be seen below:

In other cases, if the customer's card is not enrolled in 3DS, the Check Transaction will be false and the system will attempt to put through a standard Authorisation Transaction. The Success / Failure of the Authorisation Transaction is determined by the Payment Processor and not the IRP.

Please Note, the Delete Abandoned Card Orders Common Task Type gets any order in the 'New Awaiting Payment Authorization' status that is older than 72 hours and removes it from the system – it also returns any stock to the Website Stock Level and adds an AuditOrder entry stating that the order has been deleted as part of the Common Task process.