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

The flowcharts below demonstrates the typical API flow of both payment scenarios, eCommerce guest checkout and eCommerce with ongoing payments and is separated to distinguish integrations with or without 3D-Secure.

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_PAYFAC_STORED
      - MIT_PAYFAC_STORED
        
        If transaction is merchant initiated, you must send MIT_PAYFAC_STORED

Detailed step-by-step API guide below:

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
Allow up to 5 - 10 seconds to retrieve response and result of transaction request
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
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 your application will need to specify the CardStorageType to either CIT_PAYFAC_STORED (Customer-Initiated transaction) or MIT_PAYFAC_STORED (Merchant-Initiated transaction)in the request body.
      - Result of the transaction will be returned in the response:
        
        If successful, transaction statuscode: S - Successful
        
        Payment flow complete - Funds to be settled as per business rules
        
        If unsuccessful, transaction statuscode: F - Failed
        
        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

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

CVC = Any 3 digit number
Expiry Date = Any future date

Card Type	Card Number
`VISA`	4111111111111111
`Mastercard`	5353535353535351
`AMEX`	378282246310005

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:

Frictionless Success	Frictionless Fail	Challenge Required
4907639999909022	5283901906612672	4918914107195005
4016360000000010	4016360000000028	4016360000000093
5188340000000011	5188340000000029	5188340000000060

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