Home > Aria Crescendo Documentation > Account Management > Payments and Credits > Payments > Payment Gateways > Supported Payment Gateways > Chase Paymentech

Chase Paymentech

Chase-Paymentech-150.gif

Supported Features:

Batch Account Updater

Account updater automatically updates your account holders’ card information. This feature is available for Visa and MasterCard transactions in North America. To utilize this feature with Chase Paymentech, you will need to set up a separate merchant account with Chase.  Once set up, this configuration lies within the collection groups and payment gateways tab in the UI (Configuration > Payments).

Chase_BAU_B_0501.jpg

Fraud Protection

Chase allows fraud scoring and filtering protection. To use these features with Aria you will need to enable them with Chase Paymentech. In addition, you will need to use the applicable fraud merchant ID and division code for the fraud protection features you need.  These values should be inserted in the applicable fields within the UI at both the payment gateway and collection group levels. At the payment gateway and collection group levels, the below fraud options are available for selection. Each option has a corresponding tool tip to assist in your selections.

Chase_Fraud_B_0501.jpg

For improved fraud scoring, we recommend that you send the below data to Chase when you create or update an account:

  • Customer_ip_address
  • Customer_browser
  • Fraud_merchant_id
  • Customer_gender

These fields are normally passed via the API however they can be set in the UI under field options at the payment gateway level and advanced options at the collection group level.

If you are using direct post, fraud scoring and filter options should be set at the USS Reg Configuration level. Each option has a corresponding tool tip to assist in your selections. Based on your selected fraud options and your configuration in Chase the specified actions will be taken on accounts handled by your applications that use Direct Post.

Your Chase Paymentech representative will provide more information and additional documentation if needed.

Payment Methods

The following payment methods are accepted with the Chase Paymentech /Aria integration:

Traditional Payment Methods Cards
Credit Card Visa
ACH (Electronic Check) MasterCard
Tokenized Credit Card American Express
Direct Debit Discover
  Diners Club/ Carte Blanche
  Maestro
  International Maestro
  JCB
  Dankort

These are listed on Developer Central along with the UI for the accepted payment methods at the payment gateway level:

Chase_Processor_Details_B2_0504.jpg

Cardholder-Initiated Transactions (CIT) and Merchant-Initiated Transactions (MIT) for Visa, MasterCard and Discover

This feature sends flags distinguishing cardholder-initiated transactions (CIT) and merchant-initiated transactions (MIT) within the <recurring_processing_model_ind> parameter of the following API calls:

The input values for the <recurring_processing_model_ind> are the following:

  • 0:  Cardholder-Initiated Transaction—Credentials on File: a credit card transaction initiated by the cardholder for a new order or a plan upgrade that uses a credit card that is currently stored in Aria. (Default)
  • 1:  Cardholder-Initiated Transaction—a credit card transaction initiated by the cardholder for a new account or creating an order that uses an alternate credit card that is not currently stored in Aria.
  • 2Merchant-Initiated Transaction—Standing Instruction – Recurring: a credit card transaction initiated by Aria’s clients for a recurring charge that uses a credit card that is currently stored in Aria.
  • 3: Merchant-Initiated Transaction—Unscheduled Credentials on File: a credit card transaction initiated by Aria’s clients for a non-recurring charge (one-time order or plan upgrade) that uses a credit card that is currently stored in Aria.

The output field of this call is <proc_initial_auth_txn_id>.

Level 2 and 3 Data

When applicable, Aria will send Level 2 and 3 data to Chase Paymentech, resulting in savings on transaction fees. Level 3 data includes invoice line item details that allow for lower transactional fees than level 2 data.

Soft Descriptors

The soft descriptor configuration allows for a transaction description to be shown on the buyer’s credit card statement. This field allows for a 22 alphanumeric character item description when paying by credit card and up to 15 when paying by electronic check. These fields are normally passed via the API; however, they can be set in the UI at the payment gateway or collection group level.

Chase_Soft_Descriptor_B_0504.jpg

  • Soft_descriptor: Transaction description shown on the buyer's statement that displays a Merchant Name or Item Description.
  • Soft_descriptor_customer_service: City or customer service phone number that appears on the account holder's statement.

The following APIs contain the soft description and soft descriptor customer service fields:

Recurring Transaction Indicators

Initial and recurring transaction types are automatically set to recurring when the field values are set to “true” under the recurring options settings in the UI (when creating a Payment Gateway). This feature may result in lower transaction fees. The recurring transaction indicators can be configured at both the Payment Gateway and Collection Group levels (Configuration > Payments).

Enhanced Auths Marketing

This customer insight feature is designed to provide additional information to merchants, allowing them to improve authorization approval rates and lower the total cost of payments.  You can configure this setting at the Payment Gateway or Collection Group level in the UI. This feature is available for authorizations, verifications and payments of the following payment methods of all Chase supported card types:

  • Credit card (pay_method=1)
  • Tokenized credit card (pay_method=13)

Chase_Enhanced_Auths_B_0504.jpg

The following APIs contain the <perform_marketing_insights_inquiry> parameter:

The input values for <perform_marketing_insights_inquiry> are the following:

  • NULL or -1: Use client-defined settings
  • 0: do not return
  • 1: Return

For direct post, the “marketing insights” field is located under the USS Reg configuration settings.

Chase_Marketing_Insights_B_0504.jpg

The output values of <perform_marketing_insights_inquiry> are the following:

  • proc_prepaid_indicator – identifies the card as a prepaid card (if available).
  • proc_prepaid_available_balance – available balance on the prepaid card.
  • proc_prepaid_card_type - categorizes the type of prepaid card (if available).
  • proc_issuing_country - indicates issuing country for the card.
  • proc_affluence_type - indicates if card is affluent.
  • proc_card_product_type - indicates whether the submitted card is a commercial or consumer card.
  • proc_signature_debit_ind – identifies the card as a signature debit card.
  • proc_pinless_debit_ind – identifies the card as PIN less-debit-eligible.
  • proc_durbin_regulated_ind – identifies the card as Durbin Regulated.

Transaction Reference IDs

Aria will parse unique transaction reference IDs returned from Chase in the <proc_payment_id> parameter for declined transactions. Transactions include but are not limited to the following:

  • Payments
  • Authorizations
  • Captures
  • Voices
  • Reverses
  • Refunds
  • Balance Inquires

If no reference ID is returned from Chase, Aria returns a NULL value for <proc_payment_id>. The following API calls include the <proc_payment_id> output parameter:

$0/ Authorization Reversals

When authorizing a card, Aria provides the option to authorize a $0 or $1 transaction on the card to ensure the card is in good standing prior to offering a service to the account. The system override settings listed in the image below are to authorize and then reverse the authorizations on the card after the verifications. The settings can be enabled for all or specific card types accepted with this integration. This configuration in the UI is at the collection group level.

Chase_0_Auth_Rev_B_0505.jpg

Chase also supports reversing pre-authorizations on credit cards outside of $0.  After performing the authorization, click on Accounts > search for the account > Payments & Credits (left panel) > Current Authorization Reversals tab > Create a New Auth Reversal. All pending authorizations that can be reversed display on this screen. Click the authorization ID for the authorization you want to reverse.

Chase_Auth_Rev_2_0424.jpg

The reasons within the drop-down list are the following:

  • Account charged in error
  • Goods/Services not delivered
  • Customer dissatisfaction
  • Cancellation of pre-paid service
  • Good will
  • Overpayment/Duplicate payment
  • Wrong/undesired payment source charged
  • Other

After a reason is deleted and CSR comment (optional) added, press Generate Auth Reversal to remove the pre-authorization on the credit card.

CVV and AVS Configurations

With the Chase Paymentech integration, error codes can be returned by Aria for a specific Card Verification Value (CVV) response. This configuration lies within the collection groups and payment gateways tab in the UI (ConfigurationPayments).

Chase_CVV_B_0505.jpg

The integration with Chase also offers Address Verification Service responses. This configuration is also within the collection groups and payment gateways tab of the UI. See image below for possible configuration options:

Chase_AVS_B_0505.jpg

3D Secure Authentication

Steps to enable 3DS authentication for Chase Paymentech are provided below.

Payment Gateway Configuration

To configure 3DS Authentication for the Chase Paymentech payment gateway, select Configuration > Payments > Payment Gateways > Chase Paymentech and select True from the radio button shown below to enable 3DS authentication (False is the default):

PG1_0923.jpg

The Payer Authentication Settings section appears:

PG2_0923.jpg

Enter the following values:

Field Name Description
Authentication API URL The API endpoint to reach the Chase JPM payment portal (200 character limit).
Merchant ID This is a unique identifier issued to the merchant by the payment provider to perform 3DS authentication in the Chase JPM payment portal.
Authentication API Password This is the password used to authenticate the Merchant ID.
3DS Termination URL

This is the URL on the merchant website that is invoked after completing the payer authentication process. For direct post, the value should be “https://secure.<environment>.ariasystems.net/api/auth_3ds2_notification_receiver.php” where the <environment> will different for the QU, Stage, or Production environments (200 character limit).

Note: The 3DS Termination URL varies depending on whether it is an API or Direct Post configuration. If using APIs, the client should use their own URL and not Aria's. If using Direct Post, the 3DS Termination URL should be Aria's.

Press Save to retain your 3DS Authentication configuration.

Collection Group Configuration

To configure 3DS Authentication for Chase Paymentech as part of a collection group, select Configuration > Payments > Collection Groups. The following appears:

CAG1_0923.jpg

Select the Use Payment Gateway Setting radio button to use the payment gateway configuration for 3DS (this is the default).  Select True from the radio button shown below to enable 3DS authentication for your collection group.

The Payer Authentication Settings section appears:

CAG2_0923.jpg

Enter the following values:

Field Name Description
Authentication API URL The API endpoint to reach the Chase JPM payment portal (200 character limit).
Merchant ID This is a unique identifier issued to the merchant by the payment provider to perform 3DS authentication in the Chase JPM payment portal.
Authentication API Password This is the password used to authenticate the Merchant ID.
3DS Termination URL This is the URL on the merchant website that is invoked after completing the payer authentication process. For direct post, the value should be “https://secure.<environment>.ariasystems.net/api/auth_3ds2_notification_receiver.php” where the <environment> will different for the QU, Stage, or Production environments (200 character limit).

Note: The 3DS Termination URL varies depending on whether it is an API or Direct Post configuration. If using APIs, the client should use their own URL and not Aria's. If using Direct Post, the 3DS Termination URL should be Aria's.

Press Save to retain your 3DS Authentication configuration.

Note: The Collection Group 3DS configuration takes precedence over the Payment Gateway 3DS configuration.

 

API Configuration

The Chase Paymentech 3DS API configuration instructions follow, including the following output:

Field Name Description Affected APIs
<pa_3ds_from_content>

If the issuer’s Access Control Server (ACS) supports this feature, this field will receive content to populate the client’s form page to enable 3DS authentication. If the issuer’s ACS does not support this feature, no information for authentication will be returned to this field.

authorize_3dsecure_m
authorize_electronic_payment _m update_payment_method_m validate_acct_fraud_scoring_m

3D Secure Authentication for Chase Paymentech is a five-step process, as follows:

  1. Begin Authentication

Execute either of the following APIs:

API Name Inputs Outputs
authorize_electronic_payment_m
update_payment_method_m validate_acct_fraud_scoring_m

Credit card and billing address details
<attempt_3d_secure> = True

<pa_3ds_from_content> and
<pa_3ds_message_version> in <proc_3dsecure_data/ proc_3d_secure_auth_data> array

  1. Submit the Device Data Collection (DDC) Form.

Note: It is the client's responsibility to provide the DDC form.


If the “authentication.3ds.methodSupported” value from Chase and their ACS is SUPPORTED, then the <pa_3ds_from_content> field will receive content to populate the client’s DDC form to enable 3DS authentication. If the “authentication.3ds.methodSupported” value from Chase and their ACS is NOT SUPPORTED, no DDC form data is returned.

  1. Authenticate Payer

Execute the following API:

API Name Inputs Outputs
authorize_3dsecure_m

<proc_payment_id> (from Step 1)

<pa_3ds_from_content> and
<pa_3ds_message_version> in <proc_3dsecure_data/ proc_3d_secure_auth_data> array (containing challenge/DDC form page HTML content)
  *<end_user_ip_address> Default is Chase
  *<end_user_browser_accept_header>  
  *<end_user_browser_agent> Default is Chase
  *<end_user_browser_color_depth>  
  *<end_user_browser_java_enabled_ind>  
  *<end_user_browser_language>  
  *<end_user_browser_screen_height>  
  *<end_user_browser_screen_width>  
  *<end_user_browser_timezone_offset_mins>  

*-Hidden field

  1. Challenge Shopper

Use the <pa_3ds_from_content> value (from step #3) in the HTML form page to perform/complete the Shopper Challenge for the 3DS 2.0. Make sure the response includes 'result/response_gatewayRecommendation.

  1. Authorization

Execute the following API:

API Name Inputs Outputs
authorize_3dsecure_m

<proc_payment_id> (from Step 1)

<pa_3ds_from_content> and
<pa_3ds_message_version> in <proc_3dsecure_data/ proc_3d_secure_auth_data> array

Mail Order/Telephone Order (MOTO) Enhancement

Aria has enhanced the Chase Paymentech integration with support for the mail/telephone order (MOTO) transaction type. This means that you will not see the 3DS challenge when you make a purchase for a customer who is not physically present at your business location and:

  • You call the authorize_electronic_payment_m API and you set the <transaction_type> value to 1 and pass false into the <attempt_3d_secure> field; or
  • In your Direct Post configuration, you set the Transaction Type field to Single transaction mail/telephone order (MOTO) and pass false into the <attempt_3d_secure> field in your Form of Payment page.

In your Direct Post configuration, Transaction Type is now a text-only field (as shown):

DIrect_Post_Tran_Type1_0720.jpg

The following values can be entered at the Transaction Type field:

Value Description
-1 Use client configuration settings for "Send Transaction Type as Recurring for Initial Request Where Possible" or "Send Transaction Type as Recurring for Subsequent Request" as applicable.
1 (Chase) Single Transaction mail/telephone order (MOTO) - Designates a transaction where the account holder is not present at a merchant location and consummates the sale via the phone or through the mail. The transaction is not for recurring services or product and does not include sales that are processed via an installment plan.
2 (Chase) Recurring Transaction - Designates a transaction that represents an arrangement between an account holder and the merchant where transactions are going to occur on a periodic basis.
3 (Chase) Installment Transaction - Designates a group of transactions that originated from a single purchase where the merchant agrees to bill the account holder in installments.
4 (Chase) Deferred Transaction - Designates a transaction that represents an order with a delayed payment for a specified amount of time.
5 (Chase) Secure Electronic Commerce Transaction - Designates a transaction consummated via the Internet at a 3-D Secure capable merchant and the account holder is fully authenticated. (e.g. 3-D Secure includes Verified by Visa, Mastercard Identity Check, American Express SafeKey and Discover ProtectBuy).
6

(Chase) Non-Authenticated Electronic Commerce Transaction - Designates a transaction consummated via the Internet at a 3-D Secure capable merchant that attempted to authenticate the account holder using 3-D Secure (e.g. 3-D Secure includes Verified by Visa and Mastercard Identity Check). Verified by Visa, Mastercard Identity Check, American Express SafeKey and Discover ProtectBuy transactions in the event of:

  • A non-participating issue
  • A non-participating account holder of a participating issuer
  • A participating issuer, but the authentication server is not available
7 (Chase) Channel Encrypted Transaction - Designates a transaction between an account holder and a merchant consummated via the Internet where the transaction includes the use of transaction encryption such as SSL, but authentication was not performed. The account holder payment data was protected with a form of Internet security, such as SSL, but authentication was not performed. For Discover, indicates an e-commerce Card Transaction with data protection but not using ProtectBuy for Cardholder authentication.
8

(Chase) Non-Secure Electronic Commerce Transaction - Designates a transaction between an account holder and a merchant consummated via the Internet where:

  • The transaction does not include the use of any transaction encryption such as SSL
  • Authentication is not performed
  • An account holder certificate is not managed
I (Chase) IVR Transaction (PINless Debit only) - Designates a transaction where the account holder consummates the sale via an interactive voice response (IVR) system.
R (Chase) Retail Transaction - Designates a transaction where the account holder was present at a merchant location.

This applies to the following APIs:

SCA 3DS Exemption

For Chase Paymentech, a new setting has been added under Options at the payment gateway and collection group level for a low-value payment strong customer authentication (SCA) exemption (for 3DS-enabled merchants). The default selection for this field is No Exemption. Using this setting, a Chase customer will not get a pop-up confirmation message for the 3DS transaction under the exempted amount and currency, which will ensure more seamless transaction processing. To access the Chase Paymentech gateway, navigate as follows in the Aria UI: Configuration > Payments > [Payment Gateways][Collection Groups].

Create a new Payment Gateway or Collection Group and select Low Value Payment from the Exemption Type field as shown:

Chase_SCA_Exemption_0913.png

Note: Clients need to work with Chase for enabling the low amount value SCA exemption feature for their merchants.

Aria Configuration Fields

  • Division Code: This field contains the Merchant ID (MID) number assigned to you by Chase Paymentech. This is your Salem Division number. The MID may also be referred to as the Transaction Division (TD) code or Presenter ID. This is a 6-digit numeric MID while the Orbital Gateway (Tampa Platform) uses a 12-digit numeric MID.
  • Merchant division country code: If you are a US-based merchant, use this field to specify your country code (ISO 3166-1 alpha-3 code) to be used when processing all payments (for US and non-US cardholders). You can also specify your country code when you create or edit a collection group create or edit a collection group.

Supported Features

  • Card-level system overrides
  • Fraud scoring and fraud filtering
  • CNP: card-not-present. To process payments using card-present transactions (US only), you must set up card-present (retail transactions) with Paymentech.
  • Enhanced Auths Marketing
  • Identify a Cardholder Initiated Transaction​ (CIT) or Merchant Initiated Transaction (MIT)when processing Visa, Mastercard, or Discover credit card payments (credit card and tokenized credit ca​rd).
Links

Regarding Processor/Gateway Integration Certifications

If you previously implemented a custom payment processor/gateway integration, you likely completed a certification process with that processor/gateway. Aria maintains certifications with each of the processors with which it integrates. Though you may wish to certify your Aria-related processor/gateway integration before going live on Aria, this is not necessary and could add significant time and Services costs to your Aria implementation process. Please consult your Aria Implementation representative for more detailed information.

Regarding Processor- and Gateway-specific Information

All Processor- and Gateway-specific information provided on Developer Central exists as publicly accessible information from the respective companies, and is presented here for your convenience. We update this information from time to time as necessary.

 

Last modified

Tags

This page has no custom tags.

Classifications

This page has no classifications.