CIT/MIT Compliance guide - Worldpay for Platforms HPP

To become CIT/MIT compliant when integrating the Worldpay for Platforms HPP, there are a couple of changes that will be required which include additional fields in a number of API requests depending on your payment flow.

• For one-off eCommerce guest checkout HPP payment flows, there is no change to your integration for CIT/MIT.

• The required additional fields are only required for Ongoing Subscription HPP integrations.

• The Worldpay for Platforms HPP can also apply 3DS for further security. Depending on your integrated payment flows it will require little or no development on your end.

To begin testing and development, your Sandbox account will need to be configured accordingly. Please reach out to your Partner manager to get started.

Worldpay for platforms CIT/MIT compliant HPP flowchart

This flowchart below demonstrates the typical API flow of both payment scenarios, eCommerce guest checkout and eCommerce with ongoing payments.

• Worldpay for Platforms HPP (3DS not applicable).pdf

• Worldpay for Platforms HPP (3DS applicable).pdf

Please note, additional fields required for 3DS including the CIT/MIT compliant additions, should you have 3DS enabled and applicable to your integration.

API steps for Ongoing Subscription Type checkout

Additional fields required in the API request for the following endpoints:

• POST Generate HPP Token

  • Additional field:

    • CardAuthorizationType:

      • Possible values below:

        • RECURRING

        • INSTALMENT

        • UNSCHEDULED

• If you have integrated the charge stored card endpoint, POST

  Process a transaction using saved card details, there is an additional field to include

  • Additional field in POST - Process a transaction using saved card details:

    • CardStorageType:

      • Possible values below:

        • CIT_PAYFAC_STORED

          • If transaction is customer initiated, you must send CIT_PAYFAC_STORED

        • MIT_PAYFAC_STORED

          • If transaction is merchant initiated, you must send MIT_PAYFAC_STORED

Detailed step-by-step API guide below:

1. Call the POST Generate HPP Token to obtain a token and a redirect URL.

   1. Set property ProcessType = COMPLETE to submit a $ value amount payment

   2. Set property ProcessType = VERIFY to submit a Zero-Dollar Authentication if you do not wish to take a $ value amount payment at the time or you a simply updating card details on file.

   3. Specify CardAuthorizationType:

      1. RECURRING

      2. INSTALMENT

      3. UNSCHEDULED

   4. Minimum payer details:

      1. First name

      2. Last name

      3. Email address

   5. Redirect your customer to the URL you received with the token.

   6. Set property SavePayer = true

2. After the end user has completed the form we will redirect them back to your website using the returnURL you provided when generating the token.

   1. This is the notification trigger for your software to identify that the page has been completed.

3. Call the Token Lookup API endpoint to obtain the result of the HPP transaction and token.

4. Following the initial successful transaction of the first HPP, your application will have the authority to charge the account holder as and when required by the business via the POST - Process a transaction using saved card details

5. When charging a saved card if the card information is stored in the secure PAYFAC vault, you will need to supply and set the property CardStorageType to either CIT_PAYFAC_STORED or MIT_PAYFAC_STORED

6. Result of the transaction will be returned in the response:

   1. If successful, transaction statuscode: S - Successful

      1. Payment flow complete - Funds to be settled as per business rules

   2. If unsuccessful, transaction statuscode: F - Failed

      1. Payment flow complete - Application to manage collection of failed attempt

Test Card details

Within the Sandbox environment, you can test card transactions using the card examples below:

• CVC = Any 3 digit number

• Expiry Date = Any future date

3DS Test Cards to test different cases

 When testing the 3DS supports a few different card numbers for triggering different scenarios:

How to test wallet payments (Apple Pay / Google Pay)

Your device will need to be linked to either Apple Pay or Google Pay in order for the type of wallet payment to be available to select on our Hosted Payment Page. Any transactions pushed through the Sandbox environment will not process / deduct funds from your account.

How to simulate failed transactions

A: When using the test API, the transaction amount gives you the ability to test both successful and failed payments. When the transaction amount has zero cents or a number of cents other than the ones listed below, the test transaction will always be successful. If you provide one of the following numbers for the number of cents you will receive a transaction failed response with the corresponding reason:

• 31 = Invalid Account

• 54 = Expired card - Card Only

• 51 = Declined

• 61 = Insufficient Funds

• 96 = Technical failure - Card Only