Skip to main content
Aria Knowledge Central

Chase Paymentech

Chase-Paymentech-150.png
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

In addition, the following Account Updater fields for the Chase Paymentech payment gateway are now honored at the collection group level as part of the Aria integration to support international divisions for clients (Configuration > Payments > Collection Groups):

  • AU_Days_Prior_to_Invoice
  • AU_Update_Interval
  • AU_Cards_to_Update
  • AU_Merchant_Company_Number
  • AU_Division_Code_US
  • AU_Division_Code

Aria has also enhanced the Chase Paymentech Account Updater by allowing configurable actions depending upon your business practices. A new Chase AU Response Code Handler Settings field called Response Code Q Action (with this response code matched to an internal Aria setting) has been added at the payment gateway (Configuration > Payments > Payment Gateways > Gateway Options) and collection group (Configuration > Payments > Collection Groups > Collection Group Options) levels.

The field appears as shown:
Response_Code_Q_0204.png

The following selections are available at this field:

Selection Description
Use Payment Gateway Setting Honored at the Collection Group level.
No Action Required Default selection.
Suspend the Payment Method This will be honored for existing clients using this selection.

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 along with the UI for the accepted payment methods at the payment gateway level:
Chase_Accepted_Pymnt_Methods_0210.png

Cardholder-Initiated Transactions (CIT) and Merchant-Initiated Transactions (MIT) for Visa, American Express (AMEX), 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.
  • 2: Merchant-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 (Configuration > Payments).
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):Chase_PG_MA_Details_2_0214.png

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:
Chase_CG_MA_Details_2_0214.png

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 (same screen and fields as the Payment Gateway 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.

For Direct Post, an SCA Exemption textbox field has been introduced in the USS Reg Configuration (Configuration > Client Settings > USS Reg Configuration), as shown:
SCA_Exemption_DP_0201.png

Clients can specify the following values:

  • 0 Do not apply exemption. Process transaction via 3D Secure.
  • 1 Apply the exemption and skip 3D Secure Authorization.
  • -1 Use Payment Gateway or Collection Group settings for exemption rules.

For APIs, client can specify low amount exemptions in the <proc_field_override> array of the following APIs:

Apple Pay Payment Method Now Included In Chase Paymentech Integration

Aria is excited to introduce Apple Pay as a digital payment method to our Chase Paymentech integration. Tokenized payments are supported for the Visa®, Mastercard®, American Express® and Discover® card types.
Chase_Paymentech_Apple_0616.png

To configure Apple Pay for Chase Paymentech, navigate to the Apple Pay tab as shown (Configuration > Payments > Payment Gateways/Collection Groups [Chase Paymentech]). Download the Certificate Signing Request (.csr) file (Step 1). After downloading the .csr file, perform the following (Step 2):

  • Visit the Apple Pay portal.
  • Log into your merchant account.
  • Attach the CSR file.
  • Get the .cer format file.

After obtaining the .cer file, upload the file from the Apple Pay tab (Step 3) to complete the pre-requisite steps for making Apple Pay payments.

After generating and uploading the .cer format file to enable Apple Pay payments through Chase Paymentech, you can contact Aria with the Apple Pay payload generated outside of Aria. To accomplish this, an input field has been added to the existing record_alternative_payment_m API.

Input Field Name Description
<external_payment_payload> This accepts the Apple Pay encrypted payment payload. Using your payment processing certificate, Aria will decrypt the payload and store the token for future payments.

While executing the record_alternative_payment_m API (with as 47 for Tokenized Apple Pay), Aria will decrypt the payload and the decrypted values will be used for completing the initial payment to Chase. This API sends the payment to Chase Paymentech; then, Chase will post the payment the next day to complete the Apple Pay payment.

After the token is created, Aria will use the token for supporting the recurring Apple Pay payment as part of your Chase Paymentech integration. Electronic refunds are supported for both the initial and recurring Apple Pay transactions.

In addition to the newly added field above, Aria has also introduced the following input field to the record_alternative_payment_m API:

Input Field Name Description
<primary_payment_method_ind> Indicates the Apple Pay billing record to be created as primary payment method for the billing group mapped in the passed statement number. The default is 0. If we pass as '1', then the billing record will be created as primary pay method for the billing group associated with the statement number.

As a reminder, Apple Pay tokenized payments are supported for the Visa®, Mastercard®, American Express® and Discover® card types.

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.

Supported Features

  • Card-level system overrides
  • Fraud scoring and fraud filtering
  • CNP: card-not-present.
  • 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 Knowledge 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.

  • Was this article helpful?