Merchant Card Payment Engine

(1)

This document contains the proprietary information of PayPoint.net and may not be reproduced in any form or disclosed to any third

Merchant Card Payment Engine

“GATEWAY FREEDOM +IMA”

3D SECURE INTEGRATION SUPPLEMENT

(2)

PayPoint.net “Gateway Freedom +IMA” 3D Secure Supplement

1

st

_{June 2010}

Table of Figures

F i g u r e 1 : 3 D S e c u r e P a y m e n t P r o c e s s C o m p a r i s o n . . . 3 F i g u r e 2 : 3 D S e c u r e C a r d E n r o l m e n t – K e y R e q u e s t / R e s p o n s e D i f f e r e n c e s . . . 4 F i g u r e 3 : A d d i t i o n a l 3 D S e c u r e R e s p o n s e P a r a m e t e r s . . . 5 F i g u r e 4 : 3 D S e c u r e A u t h o r i s a t i o n R e s u m e P a r a m e t e r s . . . 5

(3)

1 Overview

This document assumes you have read “Gateway Freedom “Gateway Freedom “Gateway Freedom “Gateway Freedom +IMA+IMA+IMA+IMA”””” MCPE (Merchant Card Payment Engine) integration guide and are familiar with the purpose of 3D Authentication, summarised at http://www.paypoint.net/features/fraud/3d-secure/. 3D Secure Authentication is offered as part of an extended API for clients using “Gateway Freedom “Gateway Freedom “Gateway Freedom “Gateway Freedom +IMA+IMA+IMA”+IMA””” MCPE MCPE MCPE MCPE. It allows you to support the service without requiring a full integration with a dedicated 3D Secure provider and without lengthy testing. Implementing 3D Secure Authentication via “Freedom +IMA” MCPE requires that your integration with our payment gateway is extended to add support for the PayPoint.net 3D Secure API extensions, a handful of simple additional parameters.

Use of this extended API will result in an additional intermediate response/request, during any authorisation in which the cardholder is enrolled in the 3D Secure programme. All other payment requests simply proceed as normal.

Currently, chargeback liability shift exists for all 3D Secure requests, even where a card is not enrolled and is processed without 3D Secure. Responsibility is passed to the card issuer, since you as the Merchant are attempting to authenticate all customers.

2 Payment Process

For a normal “Freedom +IMA” MCPE integration, a payment request is received via your website or application, and a request is then submitted to the PayPoint.net secure payment gateway, resulting in an immediate authorisation response.

When your account is setup for 3D Secure via “Freedom +IMA” MCPE (see Appendix A) all authorisation requests are subject to a 3D Secure enrolment check. This verifies if a card has been setup for the service and can be authenticated.

In these cases an intermediate API response returns a Visa or MasterCard URL, allowing you to divert the customer to a card scheme authentication form. This form seeks to authenticate all 3D Secure enrolled cardholders before payment.

In all other cases where the card is not enrolled or the card issuer does not support 3D secure, the original authorisation request is processed as normal, such that the first response from the payment gateway is simply a transaction outcome.

Figure 1:_{3D Secure Payment Process Comparison}

Traditional Integration Traditional Integration Traditional Integration Traditional Integration

Integration with 3D Secure* Integration with 3D Secure* Integration with 3D Secure* Integration with 3D Secure*

*Only occurs with cards enrolled for 3D Secure For supported cardholders, the intermediate response contains a URL for the card-issuers ACS (access control server) and a few values identifying the transaction, which need to be POSTed as part of a redirect to this remote authentication procedure. When the cardholder is re-directed to the card issuer ACS, you also need to POST a URL to which the customer will be returned after authentication. This allows the payment process to continue without interruption after the 3D Secure check.

Where you need to persist some information about your customer to enable your systems to recognise them upon return from

Authorisation Request 3D Secure Response

Browser Redirect

HTTP HTTP

From MCPE From Card Scheme

Authorisation Request HTTP Authorisation Response

Authentication Response Authentication Request

Authorisation Response Authorisation Resume

(4)

Upon performing the POST re-direct to the ACS, your customer is transferred in their web browser to either a Verified by Visa (VbV) or MasterCard SecureCode (McSC) authentication form , provided by Visa, MasterCard of the card issuer.

If the cardholder is enrolled but not yet registered for 3D Secure, they are invited to do so, but are also given the option to skip the procedure altogether. If the cardholder is already registered, they must complete authentication in order to proceed. When the customer is returned to your domain, the POST re-direct will include an authentication response. You simply supply this value as part of a second request to the MCPE payment gateway which effectively resumes payment authorisation. With the intermediate request/response mechanism completed, normal transaction processing with 3D Secure can then proceed and results in a traditional card authorisation response from our payment gateway, backed by 3D authentication.

3 Integration

Your extended integration must support the possibility of an alternate authorisation response – for intermediate 3D Secure authentication. This will occur for any card enrolled for the service. All other requests will be processed as normal.

Please note that 3D Secure will only operate on those “Freedom +IMA” MCPE integrations supplying a fltAPIVersion of 1.4 or higher. Please check your existing integration and review latest “Freedom +IMA” MCPE documentation.

Can I select which transactions to perform 3D Secure on? Can I select which transactions to perform 3D Secure on? Can I select which transactions to perform 3D Secure on? Can I select which transactions to perform 3D Secure on?

Yes! Although PayPoint.net recommends you perform 3D Secure on all payment transactions, the integration parameter fltAPIVersion, which is submitted with each “Freedom +IMA” MCPE transaction, can be used to specify whether 3D Secure should be supported or not.

By supplying a value of fltAPIVersion=1.4, 3D Secure will be used and an enrolment check will take place. Supply a lower value – typically 1.3 – and the transaction will be sent direct for bank authorisation without 3D Secure. This allows you to limit its use on specific transactions.

For enrolled cards we do not immediately proceed to payment: instead MCPE will respond to your request with the intTransID and strSecurityToken transaction references (traditionally supplied after authorisation) and a series of 3D Secure values:

• strTransTypestrTransTypestrTransTypestrTransType (the transaction type, in this case S3DVALIDATE)

• strS3DTransID strS3DTransID strS3DTransID strS3DTransID (a 20-digit 3D Secure transaction ID, not the same as the intTransID transaction ID)

• strS3DURLstrS3DURLstrS3DURLstrS3DURL (a URL from the card issuer, where cardholder needs to be re-directed to for authentication) • strS3DRequeststrS3DRequeststrS3DRequeststrS3DRequest (the payer authentication request, used by the card issuer to conduct authentication) • strS3DMerchantDatastrS3DMerchantDatastrS3DMerchantDatastrS3DMerchantData (some merchant data from our systems which is transmitted through the process)

Figure 2: 3D Secure Card Enrolment – Key Request/Response Differences

3D Secure 3D Secure 3D Secure

3D Secure –––– Card Not Enrolled Card Not Enrolled Card Not Enrolled Card Not Enrolled

*Equivalent to non-3D request/response

3D Secure 3D Secure 3D Secure

3D Secure –––– Card Enrolled Card Enrolled Card Enrolled Card Enrolled

Authorisation Request 3D Secure Response

Browser Redirect HTTP HTTP

Authentication Request Authentication Response

Authorisation Response Authorisation Resume

strTransType= strTransType= strTransType=

strTransType=S3DVALIDATES3DVALIDATES3DVALIDATE S3DVALIDATE intStatu intStatu intStatu intStatus=s=s=s=222 2 strTransType=PAYMENT strTransType=PAYMENT strTransType=PAYMENT strTransType=PAYMENT strTransType= strTransType=strTransType=

strTransType=S3DAUTHS3DAUTHS3DAUTHS3DAUTH

Authorisation Request HTTP Authorisation Response st

st st

strTransType=PAYMENTrTransType=PAYMENTrTransType=PAYMENT rTransType=PAYMENT intStatus=0

intStatus=0 intStatus=0

intStatus=0 or intStatus=1intStatus=1intStatus=1intStatus=1 strTransType=PAYMENT

strTransType=PAYMENTstrTransType=PAYMENT strTransType=PAYMENT

From MCPE From Card Scheme

strTransType=PAYMENT strTransType=PAYMENTstrTransType=PAYMENT strTransType=PAYMENT intStatus=0

intStatus=0intStatus=0

(5)

The easiest way for your handler to recognise this alternative intermediate 3D Secure response is by checking for an intStatus of 2 (rather than 0 or 1 used in authorisation responses). In such cases a strTransType of ‘S3DVALIDATE’ is also returned.

Figure 3: Additional 3D Secure Response Parameters

These last three fields listed above are URL encoded base64 data in our response. Your handler would therefore need to decode them, and then POST the cardholder in the browser to the strS3DURL, the authentication re-direct.

The re-direct should send the contents of strS3DRequest as a variable ‘PaReq’ and contents of strS3DMerchantData as a variable called ‘MD’. You should also send your own URL in ‘TermUrl’ to which the customer should be returned.

When the cardholder completes (or exits) authentication with their card issuer (they have the option to skip it) they will be POSTed back to the ‘TermUrl’ with a new value ‘PPPPaaaaResResResRes’ which contains the authentication response, and the ‘MDMDMD’ value. MD Your integration simply needs to resume card authorisation via “Freedom +IMA” MCPE using references provided in the previous gateway response, along with a new transaction type and an encoded card scheme authentication response.

• strTransTypestrTransTypestrTransTypestrTransType (the transaction type, in this case S3DAUTH)

• strS3DResponse strS3DResponse strS3DResponse strS3DResponse (the response from the card issuer, returned to you as the value ‘PaRes’, left encoded)

This second request to the PayPoint.net payment gateway will resume the original card authorisation request, with added 3D Secure protection as appropriate. Only cards failing 3D authentication will not be entitled to chargeback liability shift.

Figure 4:_{3D Secure Authorisation Resume Parameters} Field

Field Field

Field Type(Size)Type(Size) Type(Size)Type(Size) Required?Required?Required?Required? NotesNotesNotesNotes

intInstID int(6) Yes The MCPE unique identifier for the installation performing this transaction. fltAPIVersion float(2,1) Yes The version of MCPE you are using. Must be 1.4 or higher.

intTransID int(11) Yes The MCPE unique identifier for the transaction that is to be resumed. strSecurityToken char(32) Yes The value sent in the strSecurityToken field of the Secure 3D response. strTransType char(30) Yes To resume authorisation after 3D Secure, this field is always S3DAUTH. strS3DTransID char(20) Yes The MCPE unique identifier for the completed 3D Secure authentication. strS3DResponse blob (>1000) Yes The authentication response, returned with the cardholder to your domain. strS3DMerchantData blob (>1000) Yes Aggregated merchant data which is passed through the authentication.

When card authorisation is complete, the traditional payment response will be returned from the MCPE payment gateway, as detailed in ““““FreedomFreedomFreedomFreedom +IMA+IMA+IMA+IMA”””” MCPE integration guide. You use this response to provide confirmation & fulfillment.

You can optionally receive a parameter str3DSResultstr3DSResultstr3DSResult in the authorisation response containing the decoded outcome of the 3D str3DSResult Secure check based on the your supplied strS3DResponsestrS3DResponsestrS3DResponsestrS3DResponse. See the ‘Payment Request Response’ section of the MCPE guide.

For your reference, the Merchant Extranet will also show clearly where transactions have been either completed with 3D Secure or where an attempt has been made to authenticate the customer or check if their card is enrolled.

4 Testing

You may test extended 3D Secure integration via our traditional “Freedom +IMA” MCPE test mode. This is achieved by Field

Field Field

Field Type(Size)Type(Size) Type(Size)Type(Size) NotesNotesNotesNotes

intTransID int(11) The MCPE unique identifier for this in-progress transaction.

strSecurityToken char(32) A secure identifier required in order to resume the transaction authorisation. strTransType char(30) For an intermediate 3D Secure response, this field is always S3DVALIDATE. intStatus int(1) For an intermediate 3D Secure response, this is always 2 (card is enrolled) strS3DURL blob (>1000) The authentication URL, to which the cardholder should be re-directed. strS3DTransID char(20) The MCPE unique identifier for this 3D Secure authentication. strS3DRequest blob (>1000) The authentication request, passed to the issuer in the re-direct. strS3DMerchantData blob (>1000) Aggregated merchant data which is passed through the authentication.

(6)

No enrolment check is performed (enrolment is assumed in order to test an ACS integration) and an S3DVALIDATE response is provided, containing an authentication redirect URL which passes the user to a simple PayPoint.net test page.

Upon re-directing the test customer to the PayPoint.net ACS, you will be confronted by a form which rather than seeking to authenticate the test user, will invite you to select whether to simulate a successful or failed 3D authentication.

In both cases the customer is returned to your server as part of a POST re-direct containing the return values required by your integration in order to resume authorisation via MCPE and complete the test transaction.

This second request to the PayPoint.net payment gateway should also include intTestMode=1 once again (in addition to the authentication response and Merchant Data) in order that a full 3D Secure test transaction is simulated by our systems. Since the real 3D Secure service requires interaction directly with the card schemes, using valid cards, testing of live 3D Secure transactions is only possible once this service has been enabled by your acquirer (see Appendix A).

Appendix A: Requesting & Setting Up 3D Secure

To have 3D Secure enabled on an existing PayPoint.net account, simply contact either your dedicated Account Manager or the PayPoint.net Merchant Support team via the ‘Support’ tab of your Merchant Extranet login, requesting this service.

A request will be made to your acquirer to enable 3D Secure on all your existing Merchant Account(s) (unless otherwise specified). This process may take up to a week or more for the acquirer to complete, but often much less.

For new Merchants, if applicable, the service can be enabled as part of the compliance process in obtaining your Merchant Account(s). Please select 3D Secure from product options during signup process for our “Freedom +IMA” service.

Appendix B: Alternative 3D Secure Providers

PayPoint.net strongly recommends our integrated 3D Secure service as it dramatically reduces time otherwise spent on a more complex integration with a third party, and removes the need for lengthy card-scheme Product Integration Testing.

The PayPoint.net 3D Secure service has passed Visa and MasterCard testing and is approved by both. It is also already certified for use through our acquirers. Any other solution would require several months testing before an acquirer would accept it. However, for your reference the following alternative service providers exist:

• GPayments (http://www.gpayments.com/products/activemerchant/activemerchant_standard.htm) • Cardinal Commerce (http://www.cardinalcommerce.com/)

• Modirum (http://www.modirum.com/)

• Trintech (http://www.trintech.com/PaymentGatewaySolutionMerchantPlugIn.html) • MPIware (http://www.mpiware.com/)

More providers can be found via: http://partnernetwork.visa.com/pf/3dsec/download/compliant_vendor_list.pdf

PayPoint.net cannot offer any support for integration involving third party 3D Secure solutions, but it is possible to request authorisation using the outcome of a 3D Secure authentication received from a third party service.

Assuming the existence of arbitrary values returned from the third party following authentication, in this example format:

• IDIDIDID (the 3D Secure Transaction ID)

• AVVAVVAVVAVV (the Cardholder Authentication Verification Value (CAVV / AVV) generated for successful authentication) • ECIECIECIECI (the Electronic Commerce Indicator; whether a card is registered for 3D, whether it was authenticated)

The following additional values can be added to a “Freedom +IMA” MCPE authorisation request to complete payment based on a 3D Secure authentication attempt (whether occurred or not) carried out using a third party service.

Merchant Card Payment Engine