Home > Aria6 User Documentation > Direct Post Payment Handler > Create a Configuration Set with the set_reg_uss_config_params API

Create a Configuration Set with the set_reg_uss_config_params API

Overview
1. Setting the <redirectURL> Parameter
2. Allowable values for transaction_type

Overview

The <set_name> parameter of the set_reg_uss_config_params API must comply with the following format:

The set name prefix must be “direct_post_”
The set name suffix can be any combination of alphanumeric characters. As a best practice, the suffix should relate to your hosted application in some way. For instance, your registration configuration set name could be direct_post_registration, direct_post_reg, etc. User self‐service could be called direct_post_uss, or what makes sense from a coding perspective.

Along with the standard inputs <client_no> and <auth_key> used by all of Aria's API methods, set_reg_uss_config_params API also accepts the <reg_name> and the <reg_value> parameters. These parameters act as key-value pairs that instruct the Direct Post handler how to behave.

Setting the <redirectURL> Parameter

Use the set_reg_uss_config_params API method to create the configuration set. The only required parameter for this call is <redirecturl>, which is the URL to which Aria returns the online customer. It is important to specify the <redirecturl> for each application that uses Direct Post.

Parameter	Optional	Expected Value	Comments
<redirecturl>	No	Valid URL	This is a URL you wish the Aria-hosted Direct Post Handler to immediately redirect to once it has processed payment information. It should be capable of performing error handling based off potential error messages the Direct Post Handler can return, or print a “receipt page” (or some other type of success page) if there are no returned errors.

The below table lists the optional parameters:

Parameter

Optional

Expected Value

Comments

<no_invoice_promotion>

Yes

1/0

A value of 0 means a pending invoice created during that session will be immediately settled. For registration pages, this typically is set to 0. Since USS pages typically do not generate pending invoices, this is usually set to 1 for USS pages. Refer to your existing registration and USS code base, and Aria API logs to determine whether pending invoices are being generated, and if you want them to be immediately settled.

<change_status_on_invoice_
promotion>

Yes

1/0

This should only be set to 1 if <no_invoice_promotion> is set to 0. This is a flag that indicates that the accounts status should be changed if an invoice is settled as part of the direct post process. Set it to 0 if changing account status is not desired.

<status_on_invoice_
promotion>

Yes

Valid Aria account status code

This should only be set if <no_invoice_promotion> is set to 0, and <change_status_on_invoice_promotion> is set to 1. This must be a valid Aria account status code. Aria account status codes can be found in the Account API documentation.

<min_auth_threshold>

Yes

Monetary unit

This is the minimum transaction amount that before credit card authorization, payment validation, and collection should occur. For instance, if it is desired that a minimum $10 transaction occur before authorizing an electronic payment, set this to 10. See <do_cc_auth>, and do_collect_or_validate> below for cases in which this should be used. By default, the <min_auth_threshold> parameter is set to 1.

<do_cc_auth>

Yes

1/0

This indicates whether or not a credit card authorization should occur. A value of 1 means authorization will be attempted. The minimum authorization amount, in all cases, is $1. If you wish it to be higher, use the <min_auth_threshold> parameter.

Note: This will update the account with the entered credit card information prior to attempting authorization. This is typically used to authorize the amount of a pending invoice. However, it can also be used without pending invoices in order to change an account status after a successful $1 authorization
(refer to <change_status_on_cc_auth_success> and <change_status_on_cc_auth_failure> in this table).

<change_status_on_cc_
auth_success>

Yes

1/0

This should only be set to 1 if <do_cc_auth> is set to 1. This is a flag that indicates that the accounts status should be changed if an successful credit card authorization was performed as part of the direct post process. Set it to 0 if changing account status is not desired.

<status_on_cc_auth_success>

Yes

Valid Aria account status code

This should only be set if <do_cc_auth> is set to 1, and <change_status_on_cc_auth_success> is set to 1. This must be a valid Aria account status code. Aria account status codes can be found in the Account API documentation.

<change_status_on_cc_
auth_failure>

Yes

1/0

This should only be set to 1 if <do_cc_auth> is set to 1. This is a flag that indicates that the accounts status should be changed if a credit card authorization was performed as part of the direct post process and failed. Set it to 0 if changing account status is not desired.

<status_on_cc_auth_failure>

Yes

Valid Aria account status code

This should only be set if <do_cc_auth> is set to 1, and <change_status_on_cc_auth_failure> is set to 1. This must be a valid account status code. Account status codes can be found below.

<do_collect_or_validate>

Yes

1/0

This is used to verify a credit cards validity prior to setting the accounts payment method on file, as opposed to <do_cc_auth>, which sets the accounts payment method prior to performing the authorization. This will attempt to collect the balance of the account with the entered credit card if the balance of the account is greater than or equal to the <min_auth_threshold>. If the balance is not greater than the <min_auth_threshold>, an attempt will be made to validate payment information using the entered credit card. The validation is a $1 authorization. If either collection or payment validation succeed with the entered credit card, the account will be updated with the entered credit card.

Note: By default, Chase Paymentech completes $0 authorizations for payments that are made using Visa or MasterCard. Aria automatically completes $0 authorizations instead of $1 authorizations for such payments.

<do_one_time_collection>

Yes

1/0

This is a User Self-Service feature which requires a form input field named <collection_amount> in order to work. You can only use this with Credit Card and ACH (Automated Clearing House) forms. Net Terms is not supported, so any form of Net Terms must not be selectable in this type of payment page. If this is set to 1, <collect_from_account> is performed using the amount entered in the <collection_amount> form field, with the entered Credit Card or ACH information. Form of payment on file is not changed. This must be a positive numeric value to be entered in the <collection_amount> field. If set to 1, this takes priority over all other directives, which are not used.

To collect a payment made using Direct Debit, pass 1 into this field and complete the additional steps described in Use Direct Post to Collect Direct Debit Payments.

Note: This direct post configuration parameter only applies to User Self-Service (USS) direct post configurations. If you need more functionality, you can use the collect_from_account API. You can call this API during both USS, and registration use cases, and it also allows you to use an alternate payment method.

<no_reuse_session_ind>

Yes

0/1

If this field is set to 1, Direct Post will call the kill_session API method, which will disable the current session ID after Direct-Post has completed its transactions successfully or unsuccessfully. After the session ID is disabled, you must call set_session or set_session_auth again to start a new session if you want to reattempt any unsuccessful transactions. This will allow you to verify the validity of a session every time a customer resubmits payment information. In addition, disabling a session ID will prevent that session ID from being used for any transactions other than the ones triggered by Direct Post in your Account Registration or User Self Service application.

This field is set to 0 by default. This will allow the same session to be reused if a customer attempts to resubmit payment information.

Note: If you call the set_session or set_session_auth API method for something other than Direct Post and you want to utilize the <no_reuse_session_ind>field, you will need to call a separate instance of set_session or set_session_auth specifically for Direct-Post.

For example, if you set up the no_reuse_session_ind to automatically disable a session ID. When Direct Post attempts to authorize a credit card and the authorization fails, the session ID will be disabled. You must then call set_session again to start a new session and allow the customer to resubmit credit card information.

<alt_client_acct_group_id>

Yes

Your chosen Client Group ID

This refers to a Client Group ID, a unique ID code with which to identify a collection account group. You add a Client Group ID when you create or edit a collection account group in Aria6 (currently available in only Stage Future).

Set this field to your chosen Client Group ID to specify that for a payment that you are currently submitting to Direct Post, Aria should process the transaction using the payment gateway information associated with the corresponding collection account group instead of the default Aria collection account group or the collection account group to which a customer is assigned.

Note: Passing in <alt_client_acct_group_id> will not assign a customer to the corresponding collection account group. Unless you specify otherwise, future payments will be processed using the default Aria collection account group or the collection account group to which a customer is assigned.

<alt_caller_id>

Yes

Your chosen value

You can utilize this parameter to pass in your chosen value to associate with an API call used to create or modify your customer data. For example, you can pass in the user ID of the person making an API call.

The value that you passed into the <alt_caller_id> parameter is displayed in your API call logs in Aria in a column named Caller ID.

Note: In order to be able to pass a value into the <alt_caller_id> parameter, you must first contact Aria Systems Customer Support to enable the parameter for your company.

<track_data1>

Yes

Track 1 data retrieved from a credit card that was passed through a swipe machine (card-present transaction)

If credit card numbers are added to your accounts via a swipe machine (card-present transactions), Direct Post accepts inputs consisting of the track 1 and track 2 data retrieved from credit cards. You can pass the track 1 and track 2 data into the <track_data1> and <track_data2> parameters in Direct Post.

<track_data2>

Yes

Track 2 data retrieved from a credit card that was passed through a swipe machine (card-present transaction)

If credit card numbers are added to your accounts via a swipe machine (card-present transactions), Direct Post accepts inputs consisting of the track 1 and track 2 data retrieved from credit cards. You can pass the track 1 and track 2 data into the <track_data1> and <track_data2> parameters in Direct Post.

<record_pay_method_on_cc_auth>

Yes

1/0

Specifies whether to disable or enable a payment method after a failed card authorization.

If you pass in 0 (false) and the authorization fails, the card is added to the account with a disabled status. If you pass in 1 (true) and the authorization fails, the card is added to the account with an enabled status.

The default for this field is 1 (true).

If you enabled fraud scoring/filtering in your Direct Post configuration, you can use this field to also specify whether to disable or enable a payment method after fraud scoring/filtering failure (if your payment gateway supports fraud scoring/filtering).

A card authorization will automatically be performed after successful completion of fraud scoring/filtering (if your payment gateway supports fraud scoring/filtering).

Start of proc_field_override array

proc_field_override

array

Your chosen data to send to your payment gateway passed as an array of proc_field_name/proc_field_value key-value pairs.

The allowable field(s) and values for the key-value pairs are listed below.

Field Name

Field Type

Max Length

Description

transaction_type

string

If you use Chase Paymentech, this field allows you to tell that payment gateway which transaction type is involved (examples: single or recurring transaction) when you process a customer's payment information.

This field applies to credit cards and tokenized credit cards. If you don't pass a value into this field, it will default to -1 (use client configuration settings).

Notes:

The value that you pass into this field will override the Recurring Options that you set in the Aria application under:
- Configuration > Payments > Payment Gateways > Chase Paymentech > Gateway Options; and
- Configuration > Payments > Collection Groups > Chase Paymentech > Collection Group Options.
Currently, only Chase Paymentech supports this field. Other payment gateways might not honor all of the allowable values for this field. You will need to check your payment gateway documentation for confirmation.

Aria will use this order of precedence to determine the transaction type:

value passed into this field
collection group configuration
payment gateway configuration
transaction type that you specified in the <recurring_processing_model_ind> field

Allowable Values

Values	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. (default)
1	Single transaction mail/telephone order (MOTO) - Designates a transaction where the accountholder is not present at a merchant location and completes the sale over the phone or through the mail. The transaction is not for recurring services or products and does not include sales that are processed via an installment plan.
2	Recurring Transaction - Designates a transaction that represents an arrangement between an accountholder and the merchant where transactions are going to occur on a periodic basis.
3	Installment Transaction - Designates a group of transactions that originated from a single purchase where the merchant agrees to bill the accountholder in installments.
4	Deferred Transaction - Designates a transaction that represents an order with a payment delayed for a specified amount of time.
5	Secure Electronic Commerce Transaction - Designates a transaction completed via the Internet at a 3-D Secure capable merchant and in which the accountholder was fully authenticated. (examples: 3-D Secure includes Verified by Visa, Mastercard Identity Check, American Express SafeKey and Discover ProtectBuy.)
6	Non-Authenticated Electronic Commerce Transaction - Designates a transaction completed via the Internet at a 3-D Secure capable merchant that attempted to authenticate the accountholder using 3-D Secure (examples: 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 issuer * A non-participating accountholder of a participating issuer * A participating issuer, but the authentication server is not available
7	Channel Encrypted Transaction - Designates a transaction between an accountholder and a merchant completed via the Internet where the transaction includes the use of transaction encryption such as SSL (Secure Sockets Layer), but authentication was not performed. The accountholder 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 in which ProtectBuy for Cardholder authentication was not used.
8	Non-Secure Electronic Commerce Transaction - Designates a transaction between an accountholder and a merchant completed via the Internet where: * The transaction does not include the use of any transaction encryption such as SSL * Authentication is not performed * An accountholder certificate is not managed.
I	IVR Transaction (PINless Debit only) - Designates a transaction where the accountholder completes the sale via an interactive voice response (IVR) system.
R	Retail Transaction - Designates a transaction where the accountholder was present at a merchant location.

Create a Configuration Set with the set_reg_uss_config_params API

Table of contents

Overview

Setting the <redirectURL> Parameter

Tags

Classifications

Create a Configuration Set with the set_reg_uss_config_params API

Table of contents

Overview

Setting the <redirectURL> Parameter

Related articles

Tags

Classifications