Skip to main content
Skip table of contents

UK - Worldpay for Platforms HPP (Hosted Payment Page)

Introduction

This developer guide for implementing the Worldpay for Platforms hosted payment page will allow you to integrate our payments platform to start accepting eCommerce payments including Card and ApplePay / GooglePay. The HPP offers your platform the capability to accept eCommerce guest checkout payments and eCommerce payments with the ability to charge the account holder on an ongoing subscription type basis.


Worldpay for platforms HPP flowchart

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

Note:

  • 3DS is built into the Worldpay for Platforms HPP

    • No extra development required to enable 3DS from software integration

  • ApplePay/GooglePay is also available and built-in to the Worldpay for Platforms HPP

    • No extra development required, however ApplePay/GooglePay is not available as a payment method for ongoing payments 


API steps for one-off eCommerce guest checkout

The process for using the HPP token is simply:

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

    1. Minimum payer details:

      1. First name

      2. Last name

      3. Email address

    2. Redirect your customer to the URL you received in the response with the token.

  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.

Please note the token is valid for 20 minutes. You may wish to use a landing page to trigger this if the page will not be completed as part of the flow.

For example - if your application intends to supply the customer an email of an invoice with a payment link, you will need a landing page to trigger the HPP as the token is only valid for 20 minutes.


API steps for Ongoing Subscription Type checkout

The process for beginning the steps HPP token is the same as a one-off eCommerce guest checkout, however you will need to supply an extra property - savepayer = true.

  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

      4. Billing 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 3DS - 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 = CIT_PAYFAC_STORED which will trigger the mandatory 3DS requirement for Customer-Initiated-Transactions.

    1. If there is a 3DS challenge on the charge stored card request, re-direct the end user to redirectUrl to action 3DS completion and store the redirectID to allow your application to finalise the transaction and continue follow to step 6.

    2. If 3DS was a frictionless successful, transaction statuscode: S - Successful

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

    3. If 3DS was a frictionless unsuccessful, transaction statuscode: F - Failed

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

  6. When the end user has been re-directed to complete 3DS back to the callbackUrl you supplied, trigger your application to call POST ChargeStoredCard - 3D Secure Finalize Transaction

  7. Result of the 3DS 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:

Frictionless Success

Frictionless Fail

Challenge Required

4907639999909022

5283901906612672

4918914107195005

4016360000000010

4016360000000028

4016360000000093

5188340000000011

5188340000000029

5188340000000060

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


JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.