collect_from_account_m Guide

Last updated
Save as PDF
Share
1. Share
2. Tweet
3. Share

The collect_from_account_m API collects a specified amount from a specified account holder using the electronic method of payment on file.

API Specification:	collect_from_account_m
Required Fields:	<client_no> <auth_key> <acct_no> or <client_acct_id>

Additional Guidance

Inputs passed to this API call will override any fraud options that you specified in your payment gateway, collection group, or Direct Post settings, unless stated otherwise below.
You can specify <client_payment_plan_id> or <payment_plan_no> to apply payments to a specified payment plan. You can also specify via the field <payoff_installment_ind> whether the full balance should be paid or only the due amount (default).

The following outlines the collection behavior based on whether or not you specify values for <amount_to_collect> and/or <specific_charge_transaction_id>:


Scenario	<amount_to_collect>	Specific-targeting field(s)	<specific_charge_transaction_id>	Behavior
Amount only	Provided	Omitted	Omitted	Collects the specified amount
Specific target only	Omitted	Provided	Omitted	Collects against the specified invoice, plan, or statement
Both provided	Provided	Provided	Omitted	<amount_to_collect> takes precedence; specific-targeting fields are ignored
Charge transaction	Mandatory	Optional	Provided	<amount_to_collect> is required; <specific_charge_transaction_id> drives collection

Input Fields

Field Name

Notes

<client_acct_id>

If you pass in a <client_acct_id> and an <acct_no>, Aria will use this order of precedence to decide which account to take action on:

<acct_no>
<client_acct_id>

<amount_to_collect>

If you pass <amount_to_collect> alongside <invoice_no>, <statement_no>, etc., Aria will only honor <amount_to_collect> and ignore the specific-targeting parameters.

<payment_application_method>

The value that you pass into the this field will override your selection for the Default Payment Collection Method parameter (in the Aria application under Configuration > Payments > Payment Settings).

(When the input fields <specific_invoice_no>, <specific_master_plan_instances_list> or <specific_charge_transaction_id> are passed, then those fields will be honored over <payment_application_method>).

Note: This override only applies when amount_to_collect is not also included in the request. If it is, amount_to_collect takes precedence regardless.

<fraud_filter>

To use fraud filtering, you must have it enabled and configured in your payment gateway. Contact your payment gateway representative for setup information and additional documentation.
If you set this field to 0, then Aria will ignore all other fraud filtering fields.
If you set this field to 1, then Aria will apply the values that you specified in the other fraud filtering fields. However, if you pass -1 into any fraud filtering field, Aria will ignore that field.
If you set this field to 2, then Aria will apply the values that you specified in the other fraud filtering fields.

<recurring_processing_model_ind>

This feature is available to you if your payment gateway supports Cardholder Initiated Transactions (CIT) and Merchant Initiated Transactions (MIT).

For the Vantiv payment gateway, the value in this field will automatically be set to 2 if your payment gateway or collection group configuration has the Send orderSource as recurring for all transactions option enabled.

Refer to your payment gateway documentation to see if this applies.

Please contact your payment gateway representative for more information.

<transaction_type>

If you use Chase Paymentech or Vantiv, 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).

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/Vantiv > Gateway Options; and
Configuration > Payments > Collection Groups > Chase Paymentech/Vantiv > Collection Group Options.

Currently, only Chase Paymentech and Vantiv support 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

<bank_acct_type>

Allowable values:

Values	Description
savings	savings
checking	checking
business	business

<payment_application_method>

Allowable values:

Values	Description
Null (default)	Value taken from client parameter
1	FIFO (First In, First Out)(default)
2	FDFO (First Due, First Out)
3	None (future manual allocation)
4	Statement FIFO

<fraud_filter>

Allowable values:

Values

Description

false (disable)

Note: If you set this field to 0, then Aria will ignore all other fraud filtering fields.

true (enable)

Note: If you set this field to 1, then Aria will apply the values that you specified in the other fraud filtering fields. However, if you pass -1 into any fraud filtering field, Aria will ignore that field.

Use settings specified at the collection group or payment gateway level.

Note: If you set this field to 2, then Aria will apply the values that you specified in the other fraud filtering fields.

<fraud_filtering_enabled>

Allowable values:

Values	Description
0	disable
1	enable
-1	Use settings specified at the collection group or payment gateway level.

<change_status_on_fraud_filtering_failure>

Allowable values:

Values	Description
0	false
1	true
-1	Use settings specified at the collection group or payment gateway level

<change_status_on_fraud_filtering_review>

Allowable values:

Values	Description
0	false
1	true
-1	Use settings specified at the collection group or payment gateway level

<change_mp_status_on_fraud_filtering_cc_prefix_failure>

Allowable values:

Values	Description
0	false
1	true

<change_mp_status_on_fraud_filtering_cc_number_failure>

Allowable values:

Values	Description
0	false
1	true

<change_mp_status_on_fraud_filtering_cc_issuing_country_failure>

Allowable values:

Values	Description
0	false
1	true

<change_mp_status_on_fraud_filtering_cc_issuing_country_suspect>

Allowable values:

Values	Description
0	false
1	true

<recurring_process_model_ind>

Allowable values:

Values	Description
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 nonrecurring charge (onetime order or plan upgrade) that uses a credit card that is currently stored in Aria.

<transaction_type>

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	(Chase) 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	(Chase) 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	(Chase) Installment Transaction -Designates a group of transactions that originated from a single purchase where the merchant agrees to bill the accountholder in installments.
4	(Chase) Deferred Transaction -Designates a transaction that represents an order with a payment delayed for a specified amount of time.
5	(Chase) 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	(Chase) 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	(Chase) 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	(Chase) Non-Secure Electronic Commerce Transaction - Designates a transaction between an accoutholder 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	(Chase) IVR Transaction (PINless Debit only) -Designates a transaction where the accountholder completes the sale via an interactive voice response (IVR) system.
R	(Chase) Retail Transaction -Designates a transaction where the accountholder was present at a merchant location.
telephone	(Vantiv) The transaction is for a single telephone order.
mailorder	(Vantiv) The transaction is for a single mail-order transaction.

<payoff_installment_ind>

Indicates if payment should be allocated to payoff future installment early or not. This is applicable only for installments; this will be ignored for other non-installment charges. This is applicable when users pass a specific <charge_transaction_id>.

Allowable values:

Values	Description
0	Pay off installment due (default)
1	Pay off installment (including future installment)

Error Codes

Error Code/Description	Associated Inputs
1016: invalid input Additional Comments: This error can be caused by the wrong type of input; for example, text in a numbers-only field, or specifying a value other than one of the documented allowable values.	"Invalid input: The <field_name> (e.g., <sequential_statement_no>) array contains duplicate entries."
1500: Unsupported bank/country code for this payment method. Additional Comments: Added in support of ACH payments via Direct Debit (country code must be US).	<bank_country_cd>
4040: Could not find a processor for this payment method
4044: Missing a required value. Please check that either bank_account_no, bank_routing_number or agreement_id is present.
6029: Bank swift code is alphanumeric and is 8 or 11 characters in length	<bank_swift_cd>, <alt_pay_method>
6032: Bank ID code is numeric and up to 10 digits
32006: Inputs conflict: assign_installment_term input conflicts with client installment term id or installment term no.	This can be generated if there are conflicting inputs such as invoices list or master plan instances list.
32012: <field_name>, <field_name_values> are invalid.