Chase Paymentech

API Version

Minimum required API version: 1.1.0

The following features require an API version higher than the minimum:

• 3DS 2.0 External requires API version 1.3.0

Payment Methods

Currencies

For charging a customer:
AED,AMD,ARS,AUD,AZN,BDT,BGN,BIF,BND,BOB,BRL,BWP,BYN,BZD,CAD,CHF,CLP,CNY,COP,CRC,CZK,DJF,DKK,DOP,DZD,EGP,ETB,EUR,GBP,GEL,GHS,GNF,GTQ,HKD,HNL,HUF,IDR,ILS,INR,ISK,JMD,JPY,KES,KGS,KHR,KMF,KRW,KZT,LBP,LKR,MAD,MDL,MGA,MOP,MUR,MXN,MYR,MZN,NAD,NGN,NIO,NOK,NPR,NZD,PAB,PEN,PHP,PKR,PLN,PYG,QAR,RON,RUB,RWF,SAR,SEK,SGD,SOS,THB,TOP,TRY,TTD,TWD,TZS,UAH,UGX,USD,UYU,UZS,VES,VND,XAF,XOF,YER,ZAR
Forsettlements:
AUD,CAD,EUR,GBP,USD

Features

The following table provides an overview of all supported and non-supported features.

Feature	Supported	Notes
3DS 2.0 External	Yes
3DS 2.0 PaymentsOS-handled	No
3DS 2.0 Provider-handled	No
3DS 2.0 Self-handled	No
Installments	No
Level 2 and 3 Data	Yes
Multi-seller Payments	No
Network Tokens	No
Payment Facilitator	No
PayU Risk	No
Pre-authorization	No
Retrieve Supported Payment Methods	No
Retrieve Supported Plans	No
Statement Soft Descriptor	Yes
Stored Credentials Flag	Yes
Transaction Processing without CVV	Yes	Transaction processing without CVV is not supported with VISA and DISCOVER.

Requests

The following table lists all supported requests for card-based transactions. Use the bodybuilder to create a sample request body for each request type.

Setup Procedures

The following table lists the setup procedures that are specific to this provider.

Response Data

In the response of a transaction request, you will also receive:

• The status of the CVV and AVS verification (if enabled in your Chase Paymentech account)

• An indication whether level 2 and 3 data was sent.

CVV and AVS Verification Response

In your Chase Paymentech account, you can enable CVV and AVS verification and determine whether a failed verification should cause the request to fail as well. If a CVV check is performed, you will receive the status of the verification in the CVV2RespCode field of the additional_information object in the request response data:

...
{
  "provider_data": {
    ...
    "additional_information": {
      "CVV2RespCode": "M"
      ...
    },
  }
},
...

The CVV2RespCode can be one of the following values:

• M: CVV Match
• N: CVV No Match Error
• P: Not processed
• S: Should have been present
• U: Unsupported by issuer/issuer unable to process request
• I: Invalid
• Y: Invalid
• blank: Not applicable (non-Visa)

If an AVS verification was done, you will receive the status of the verification in the avs_code field of the provider_data object:

...
{
  "provider_data": {
    ...
    "avs_code": "A"
    ...
  }
},
...

For an overview of possible AVS codes, see AVS Response Codes.

Level 2 and 3 Data Response

The response of a Create Autorization request indicates whether the card that was used for the payment supports sending level 2 and 3 data:

...
{
  "provider_data": {
    ...
    "additional_information": {
      "CTILevel3Eligible": "Y"
      ...
    },
  }
},
...

Level 2 and 3 data fields can then be sent in a Create Capture request (use the Bodybuilder to generate a sample Create Capture request that includes level 2 and 3 data). The response of the Create Capture request will let you know whether level 2 or 3 data was sent:

...
{
  "provider_data": {
    ...
    "additional_information": {
      "level_2_3_sent": "true" // true if sent; otherwise false
      ...
    },
  }
},
...

Identifying Rejected Refunds

There are rare cases in which a refund is rejected by the issuer, even though it was initially approved (this can happen, for example, if the customer’s bank account was closed). Since the refund was initially approved, its status in PaymentsOS will be Succeed. If you want to determine whether an approved approved was rejected by the issuer, you will have to do so manually by checking your transaction history and PTO/DFR reports in your Chase Paymentech account.

Testing

Follow the PaymentsOS recommended testing procedures.