- Batch Account Updater
- Fraud Protection
- Payment Methods
- Cardholder-Initiated Transactions (CIT)/ Merchant-Initiated Transactions (MIT) for Visa, MasterCard, AMEX and Discover
- Level 2/3 Data
- Soft Descriptors
- Recurring Transaction Indicators
- Enhanced Auths Marketing
- Transaction Reference IDs
- $0 Authorizations / Authorization reversals
- Card Verification Value (CVV) and Address Verification Service (AVS) Configurations
- 3D Secure Authentication (Currently, 3DS 2.0 supports only Visa and Mastercard. Please contact your payment gateway representative for more information. Additional details appear on this page.)
- Mail Order/Telephone Order (MOTO) Enhancement
- SCA 3DS Exemption
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).
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):
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:
The following selections are available at this field:
|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.|
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.
For improved fraud scoring, we recommend that you send the below data to Chase when you create or update an account:
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.
The following payment methods are accepted with the Chase Paymentech /Aria integration:
|Traditional Payment Methods||Cards|
|ACH (Electronic Check)||MasterCard|
|Tokenized Credit Card||American Express|
|Diners Club/ Carte Blanche|
These are listed on Developer Central along with the UI for the accepted payment methods at the payment gateway level:
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.
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.
- 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)
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.
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:
- 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 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.
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
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).
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:
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):
The Payer Authentication Settings section appears:
Enter the following values:
|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:
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.
The Chase Paymentech 3DS API configuration instructions follow, including the following output:
|Field Name||Description||Affected APIs|
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_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:
- Begin Authentication
Execute either of the following APIs:
Credit card and billing address details
- 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.
- Authenticate Payer
Execute the following API:
<proc_payment_id> (from Step 1)
<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_agent>||Default is Chase|
- 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.
Execute the following API:
<proc_payment_id> (from Step 1)
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):
The following values can be entered at the Transaction Type field:
|-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).|
(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:
|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.|
(Chase) Non-Secure Electronic Commerce Transaction - Designates a transaction between an account holder and a merchant consummated via the Internet where:
|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:
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:
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.
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
In addition to the newly added
|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.
- 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 card).