Understanding Card Payments On The IRP

• Card Processing is available through Realex (https://www.globalpaymentsinc.com) or Worldpay (https://www.worldpay.com/uk).
• The IRP integrates with both through direct XML APIs.
• Payment Requests are posted by IRP and success / failure Responses are returned by the Payment Processor.
• Both Gateways are capable of handling 3D Secure Transactions for protection against fraud-related chargebacks.

• 3D Secure is an extra authentication step in the Card Payment process.
• It is more widely known as Verified by Visa, Mastercard SecureCode or American Express SafeKey.
• It allows merchants to verify identity of Customers by redirecting them to their bank's authentication page to enter a secure passphrase or to use two-factor authentication.
• Under correct conditions, 3D Secure provides protection for merchants in the event of fraud-related chargebacks.

1. The Customer enters their Card Details at the PAYMENT DETAILS stage of the checkout.
2. The Customer is redirected to the PLACE ORDER stage of the checkout where they are invited to click Place Order.
3. If 3D Secure is triggered based on the IRP rules:
   1. The Payment Processor performs an enrolment Check on the Customer's Card and Bank to ensure they are enrolled in 3D Secure – a 'Check3DSecureEnrolled' Transaction is added against the Order.
      1. If the Customer's Card and Bank are enrolled, the 'Check3DSecureEnrolled' Transaction is marked as Successful and the Customer is redirected to the VerifyPaymentMethod.aspx page which contains an embedded form (provided by the Issuing Bank) for authenticating their Payment Card.
      2. If the Customer's Card and Bank are non-enrolled, the 'Check3DSecureEnrolled' Transaction is marked as Unsuccessful and the Payment Processor will attempt to perform a standard Authorisation 'Auth' Transaction using the entered Card Details.
   2. The Customer verifies their chosen Payment Card by entering a passphrase or using two-factor authentication – a 'Verify3DSecureSignature' Transaction is added against the Order.
      1. If their Verification is Successful, the 'Verify3DSecureSignature' Transaction is marked as Successful, a further Authorisation or Capture request is made to capture the funds and the Customer is redirected to the ORDER CONFIRMATION page with a success message. This final step will be marked by an 'Auth' Transaction being added against the Order.
      2. If their Verification is Unsuccessful, the 'Verify3DSecureSignature' Transaction is marked as Unsuccessful, the Customer is returned to the Order Summary page, the Order is Deleted if the 'Keep 3D Secure Failed Orders' Application Setting is false and kept otherwise; and the Customer is invited to place their Order again.
4. If 3D Secure is not triggered based on the IRP rules, the Payment Processor simply performs a standard Authorisation 'Auth' Transaction using the entered Card Details.

For more information on how Card Payments work with 3D Secure, and what typical Payment Transactions look like for different scenarios, please see the following help topic in the IRP Knowledge Base: How To Understand Payment Transactions Using 3D Secure.

1. Cardholder's Enrolment is checked
   First, the Customer's card is checked for 3D Secure enrolment. The Issuing Bank of the card must support the protocol and have enrolled the customer. Realex or Worldpay queries the Enrolment Server and returns the status of the card.
   If the cardholder is enrolled, Realex or Worldpay return the URL of the Access Control Server (ACS). This is the web page of the Customer's Issuing Bank to facilitate authentication. Also returned in the enrolment check is an encoded PaReq value, which is used by the ACS to identify the cardholder and transaction.
   ** Verified by Visa and Mastercard SecureCode provide protection against customer chargebacks even when the cardholder is not enrolled for 3D Secure. If the response to the enrolment check returns false, then you can proceed directly to authorisation with the ECI and the XID included in the authorisation request. This does not apply with American Express SafeKey and non-enrolled cards do not qualify for chargeback protection.
2. Redirect the Cardholder to Authenticate the Transaction
   The encoded PaReq value from Step 1 is posted to the ACS URL provided, along with the TermUrl (contact your Account Manager for more information) to receive the response from the ACS. Also included in the data posted to the ACS URL is Merchant Data (MD), encrypted, then compressed and base64 encoded, containing the CustomerID, TransactionOrderID, Customer's GUID, their Card Number and the OrderID.
3. Verify the Cardholder's Authentication Result
   The response from the ACS will include a PaRes which is the encoded outcome of the cardholder's authentication. This returned PaRes is then sent back to Realex or Worldpay, decoded and checked for its validity and authenticity. The response to this request will indicate whether the cardholder successfully authenticated their transaction by entering the correct passphrase or successfully using two-factor authentication.
   3D Secure authentication provides protection against customer chargebacks under two scenarios:
   1. Where the Customer has successfully authenticated
   2. Where the Bank has acknowledged the attempt by the Customer
   If an Electronic Commerce Indicator (ECI) value is returned in the response to the Verification attempt, it is handled accordingly. In scenarios where an ECI value is not returned in the response, the 'status' (Realex) or 'lastEvent' (Worldpay) values can be used to determine success / failure.

   Visa/Amex/JCB	Mastercard	Description
   05	02	Cardholder and issuing bank are 3D Secure. 3DS Authentication successful.
   06	01	Either cardholder or issuing bank not registered for 3DS.
   07	00	Cardholder and issuing bank not registered for 3DS.

   ** ECI and CAVV values are not returned by default on Worldpay and should be enabled specifically via your Worldpay Account Manager.
4. Confirm Authorisation
   Based on whether the 3D Secure Verification was Successful, a final Authorisation or Capture Request is made and the Transaction is Successful.

3DS Settings are configurable on the Payment Processing > Card Processor Settings page in IRP Admin:

Enable 3D Secure
If unchecked, 3D Secure will not be attempted and only non-3DS enabled Card Processors will be used for Payment. If checked, and the other 3D Secure rules are met, only 3DS enabled Card Processors will be used for Payment and enrolment checks will be performed on every single card order.

3D Secure Order Value Threshold
Only Orders where the Order Totals match or exceed this value will be considered for 3D Secure.

Keep 3D Secure Failed Orders
If this setting is enabled, any Orders that have failed the Verification step for 3D Secure (i.e. incorrect password) will be kept in the 'New Awaiting Payment Authorisation' status. If this setting is disabled, Orders that fail will be deleted and an Audit Entry added to log the deletion. You may want to enable this setting when you initially turn on 3D Secure to monitor drop outs and so forth. However, unless you have the resources to manage these orders, we strongly recommend that you leave this setting disabled. If you do enable this setting, you should set up the Common Task called 'Delete Abandoned Card Orders' to periodically run and remove these failed orders. This Common Task will keep these orders clean, but we strongly suggest daily review of such orders and, if possible, a well-documented process to contact the customer to see if the order cannot be placed through other means e.g. Telesales.

Allow 3D Secure 'Unknown Status' Orders
If disabled, any 3D Secure Orders where the ECI value returned matches the Card Type's 'ECI Value for No Liability Shift' value will be rejected (Visa 07, Maestro/MasterCard/Switch 00). If enabled, Orders where the ECI value matches will be assumed to be valid.

Disable 3D Secure for Repeat Customers
If enabled, 3D Secure will not be attempted for Customers that have more than 1 Successful (i.e. not Cancelled / Marked as Fraud) non Guest Orders.

Supported Countries
Any Countries marked as 'Supported Countries' will be eligible for 3D Secure whereas it will not be attempted on 'Non-Supported Countries'.

Supported Card Types
Any Card Types marked as 'Supported Card Types' will be eligible for 3D Secure whereas it will not be attempted on 'Non-Supported Card Types'. This will need to tie in closely with the Payment Processor to ensure that 3D Secure enabled Card Types on the Payment Processor's Merchant Account match the enabled Card Types on your IRP.

An Order is inserted into the IRP database before Payment is attempted. Orders are initially inserted with the Status 'NewAwaitingPaymentAuthorisation'.

• If 3D Secure is not triggered, any Payment Failure will result in the Customer being returned to the Order Summary page and the inserted Order being deleted.
• If 3D Secure is triggered, the Order will remain at 'NewAwaitingPaymentAuthorisation' until Authentication is confirmed.

** Orders that proceed to the 3D Secure Verification page and are not completed will be marked as Pending and will appear in the 'Pending Payments' section of the IRP Admin. These Orders can be cleared out by enabling the 'Delete Abandoned Card Orders' Common Task which removes Card Orders still at 'NewAwaitingPaymentAuthorisation' older than 72 hours.

1. Incorrect Card Details entered
While the Card Details entered on the PAYMENT DETAILS stage of checkout may appear valid, when the Payment Processor attempts a Payment with incorrect details, the Customer will be redirected back to the PAYMENT DETAILS page, the initial Order object deleted and invited to re-enter their Card Details or to select an alternative method of Payment.

2. Poorly configured Merchant Environment
If the Realex or Worldpay back-end has not been set up correctly, Payment may fail. Configuration errors or omissions such as whitelisted IP Addresses or Card Type mismatches between the IRP and the Payment Processor can cause potential issues.

3. Poorly configured IRP Environment
Both Realex and Worldpay have specific credentials which are key to successful communication between their environment and the IRP and need to be 100% correct:

4. Incomplete 3D Secure Order
As discussed in detail above earlier in this topic, 3D Secure Orders that move to the Verification stage but are never Authenticated will remain in a Pending state unless cleared out by the 'Delete Abandoned Card Orders' Common Task.

5. Exception Thrown by Card Processor
Exception handling is built into the Realex and Worldpay implementation within the IRP. When making Payment Requests, if an unexpected Exception is thrown by the Payment Processor, these will be caught and logged by the IRP and the Payment will be marked as Unsuccessful.

6. Timeout in Communication with Card Processor
Both Realex and Worldpay implement a 120 second timeout period with all communications. This is as much for Customer experience than anything else. If an XML Request sent to the Payment Processor is not responded to within that time period, a timeout exception will be thrown and the Payment will be marked as Unsuccessful.

7. Refusal
Refusal can happen for numerous reasons, such as:

• Card Expired
• Fraud Suspicion
• Lost Card
• Invalid Security Code
• Restricted Card
• Rejected by Card Issuer
• Limit Exceeded

8. Error
An error with the Payment Request will result in an Error Response that will be caught and logged in the IRP Admin against Unsuccessful Payment Processor Transactions.

9. Fraud Suspicion
Both Realex and Worldpay have built-in Risk Management / Fraud Prevention tools. If these mechanisms deem a Transaction to be fraudulent or worthy of significant fraud suspicion, a Refused Response will be returned and the Payment will be marked as Unsuccessful.

** Risk Management settings can usually be configured within the Payment Processors back-end but should only be done so on the advice of an Account Manager.

10. Failed 3D Secure Authentication
If the Customer enters the incorrect 3D Secure passphrase or fails to enter the correct two-factor authentication details, Payments will be marked as Unsuccessful.

11. AVS PostCode and Address Check Failure
If the 'Live Charging Fail Transactions When AVS Fails' Application Setting is enabled and the Address Verification Service (AVS) Address Check and Post Code Check both fail, the Payment will be marked as Unsuccessful.

12. CVC / CVV Check Failure
If the Card Verification Code Check fails, the Payment will be marked as Unsuccessful.

Example Realex – Successful Authorisation Response

Example Worldpay – Successful Authorisation Response

Example Realex – Check 3D Secure Enrolment Response

Example Worldpay – Check 3D Secure Enrolment Response

Worldpay Payment Statuses