CIT/MIT Compliance guide - Partner Software managed payment page REST API

To become CIT/MIT compliant when integrating the Worldpay for Platforms to accept card payments via our REST API JavaScript library, there are a number of changes additional fields that will be required to be supplied in the API request.

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

Partner Software managed payment page REST API - CIT/MIT compliant flowchart

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

• Partner managed payment page CIT-MIT (3DS not applicable).pdf

• Partner managed payment page CIT-MIT (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 to accept eCommerce subscription checkout for ongoing payments

• Original endpoint - POST Make a live tokenized card transaction will need to be updated to include:

  • Additional fields include:

    • CardAuthorizationType:

      • Possible values below:

        • RECURRING

        • INSTALMENT

        • UNSCHEDULED

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

  Process a transaction using saved card details, this will need to be updated to add an additional field

  • 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_PAY_STORED

        • MIT_PAYFAC_STORED

          • If transaction is merchant initiated, you must send MIT_PAYFAC_STORED

Detailed step-by-step API guide below:

1. POST - Make a live tokenized card transaction

   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

2. Allow up to 5 - 10 seconds to retrieve response and result of transaction request

3. 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

4. Most software services already contain the information regarding the Payer and when they are to be charged. In this case it is much simpler for the software to manage the schedule and send a request on the day required. You have 2 options:

   1. POST Process a transaction using saved card details

      1. Real-time payment request submission

      2. Real-time transaction result

         • Following the initial successful transaction of the first transaction, 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

           • 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

           • 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

   2. Schedule a single payment

      1. Processed and debited via banking system

      2. 2 business day result time

         • Schedule single or multiple payments:

           1. POST Schedule a single payment

           2. POST Schedule multiple future payments

         • Determine result of scheduled debit - GET Search for transaction status change

         • Remove transaction from data set - POST Acknowledge transaction status change

Test Card details

3DS Test Cards to test different cases

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

• CVC = Any 3 digit number

• Expiry Date = Any future date

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

How to simulate failed transactions?

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