PayConexDecryptxShieldConexTECS Platform
Guides
Request SandboxContact Us

Real-Time ACH Account Verification

Suggest Edits

The National ACH Association (NACHA) has introduced a new rule that payment originators must perform account validation for WEB debit ACH transactions the first time a customer uses an account number.

The rule was originally approved in November of 2018 and became effective on March 19, 2021. The NACHA board of directors approved a 1-year extension to the effective date, allowing additional time for providers to implement their chosen solution.

Our Partner

Microbilt has been a pioneer in consumer data for over three decades. Bluefin is partnering with Microbilt to validate first-time ACH accounts. This enables merchants to meet the new NACHA rules and any additional ACH account validation they may want to conduct.

Microbilt is a NACHA Preferred Partner. This means that their data and products meet the highest standards of accuracy, quality, and security as mandated by NACHA.

Informational Links:

How does this change the ACH transaction processing flow?

From a developer or merchant perspective, there won't be much that changes.

The most significant change will be that — in some cases — you may receive a declined ACH transaction, whereas in the current ACH model there is no real-time verification.

Current ACH Transaction Flow

Traditionally, when processing ACH payments, PayConex will receive a transaction request containing the data relevant to an ACH account and other details.

This transaction is placed into a batch and then issued to our ACH processing providers. After the transaction is batched it will be marked as pending.

As an ACH transaction continues through the ACH network for processing the status of the payment will continue to be updated until the transaction is settled, or returned.

Here is a diagram showing that flow:

6805

Transaction Flow With Real-time ACH Account Verification

As you can see from the previous transaction flow, there has traditionally been no validation from the ACH network that the bank account is open/closed, or that there are funds available within the account.

The new NACHA rule aims to close this gap by requiring payment originators to validate ACH accounts the first time they are used. All of this happens prior to processing an ACH transaction.

In this scenario, PayConex will check if the ACH account supplied within a transaction has been verified by Microbilt previously, and if it has, then the flow will remain very similar.

However, if the ACH account information has not been previously validated, then PayConex will attempt a verification with Microbilt to determine whether or not the transaction can be batched for processing.

Here is a diagram showing the flow using Real-Time ACH Account Verification:

6075

Configuring ACH Verification in PayConex

Merchants will have a variety of options for how strict or lenient they would like their ACH verification to be.

Below is a screenshot of the settings inside PayConex for this feature:

958

A PayConex customer service team member can assist you with enabling this feature.

📘

Note

These settings will only appear if an ACH processor is selected.

ACH Verification

This setting will enable or disable the ACH verification service.

SEC Codes to Validate

This selection box allows multiple ACH SEC codes to be selected. Transactions containing an SEC code that is selected here will flow through the ACH verification process. Transactions containing an SEC code that is not selected from this list will not flow through the ACH verification process.

📘

What is a SEC Code?

SEC Code stands for Standard Entry Class Code. These codes are used to identify the type of transaction being run.

While the new NACHA rule only requires ACH account verification for the WEB SEC code, we have provided the capability to select other SEC codes as well. This can help some merchants reduce the chance of transactions being declined or returned at the end of the ACH process.

  • The WEB SEC code will be selected by default and cannot be deselected.

Here's a list of other SEC codes and their definitions.

  • CCD: Cash Concentration or Disbursement. This is the default type for corporations. Requires a signature.
  • PPD: Prearranged Payment & Deposit. Requires a signature.
  • WEB: Web-originated, e-commerce transactions.
  • TEL: Telephone-initiated transactions. Voice recording required.
  • POP: Point-of-Purchase, in-person transaction.
  • ARC: Accounts Receivable. This is for converting a check into an electronic ACH transaction.
  • RCK: Re-presented Check. This is used to present a declined check an additional time.
  • DEF: This can be sent to tell PayConex to use the default ACH SEC code. Sending nothing will result in the same action.

ACH Verification Frequency

The NACHA rule requires that when a new ACH account is used for the first time it must be verified; however, there are no guidelines on how frequently this verification should occur.

The PayConex system purges transactions that are 18 months or older, and NACHA provides no guidelines on how frequently verification should be performed so the decision was made to have the default frequency be set to "Every 360 Days".

This means that the first time an ACH account is used for a PayConex account it is verified through Microbilt. All subsequent uses of that account data in a transaction will not be verified with Microbilt for the next 360 days.

  • Every 360 Days will be selected by default.

Options for this setting range from 30 to 360 days (in 30-day increments). In addition, a setting is provided that allows a merchant to have verification performed every time an ACH transaction is processed. This is ideal for merchants that want to make sure an ACH account is valid each time a transaction is processed. This design allows Bluefin to provide the maximum amount of flexibility for our PayConex merchants.

ACH Verification for Recurring

This setting provides a merchant who is configured to process recurring transactions through PayConex and/or the Scheduling Layer API to have those transactions also be verified through Microbilt based on the ACH Verification Frequency settings.

  • The default for this setting is No

ACH Verification for Reissue

This setting provides a merchant who utilizes PayConex reissue transactions to also be verified through Microbilt based on the ACH Verification Frequency settings.

  • The default for this setting is No

How will ACH account verification work when using the PayConex API?

Data validation rules for ACH account verification

  • first_name is required; can be no longer than 32 characters.
  • last_name is required; can be no longer than 32 characters.
  • bank_routing_number is required; can be no longer than 9 characters
  • bank_account_number is required; can be no longer than 20 characters.

If any of these validation checks fail the API request will trigger an error and the transaction will not be sent to Microbilt or batched for processing.

Example of an API data validation error:

array (
 'error' => true,
 'error_code' => 31311,
 'error_message' => 'The first name is too long. Max. size is 32.',
 'error_msg' => 'The first name is too long. Max. size is 32.',
)

Example API Request for ACH Transactions

The request format and parameters for passing an ACH transaction via the PayConex API will remain unchanged.

This is a simple example of an ACH transaction POST to the PayConex API.

curl --request POST \
 --url https://cert.payconex.net/api/qsapi/3.8 \
 --header 'Content-Type: application/x-www-form-urlencoded' \
 --data account_id=220614966801 \
 --data api_accesskey=32d42f0f0b6c89616d42aed8c96801e6 \
 --data tender_type=ACH \
 --data transaction_type=SALE \
 --data transaction_amount=1.00 \
 --data response_format=JSON \
 --data bank_routing_number=123123123 \
 --data bank_account_number=123456789 \
 --data first_name=Blue \
 --data last_name=Fin

In the transaction example above no ach_sec_code is provided. If the SEC code is not provided at the point of the transaction it will be retrieved from the PayConex account's ACH processor setup.

For example, in the scenario above if the account was set up to only run ACH verification for WEB transactions and the processor settings contain TEL as the default SEC code, the transaction will not be routed to Microbilt for verification.

However, if a transaction is processed with the ach_sec_code of WEB, the transaction will be routed to Microbilt for verification if the ACH account has not previously been verified. Here is an example showing the usage of ach_sec_code within an ACH transaction request:

curl --request POST \
 --url https://cert.payconex.net/api/qsapi/3.8 \
 --header 'Content-Type: application/x-www-form-urlencoded' \
 --data account_id=220614966801 \
 --data api_accesskey=32d42f0f0b6c89616d42aed8c96801e6 \
 --data tender_type=ACH \
 --data transaction_type=SALE \
 --data transaction_amount=1.00 \
 --data response_format=JSON \
 --data ach_sec_code=WEB \
 --data bank_routing_number=123123123 \
 --data bank_account_number=123456789 \
 --data first_name=Blue \
 --data last_name=Fin

Example API Reissue ACH Transaction Requests

The request format for reissue transactions will also remain the same; however, it is important to note how the ach_sec_code parameter can be used with these types of transactions.

If an ach_sec_code is provided in the request then the API will decide if the transaction should flow through verification based on the account's settings.

If an ach_sec_code is not provided in the transaction, and the token_id of the transaction being reissued contained an ach_sec_code then the SEC code from the original transaction will be utilized in the reissue transaction.

If no ach_sec_code is provided in the original transaction, or the reissue transaction, the default SEC code configured with the ACH processor will be used.

This is an example reissue ACH transaction request:

curl --request POST \
 --url https://cert.payconex.net/api/qsapi/3.8 \
 --header 'Content-Type: application/x-www-form-urlencoded' \
 --data account_id=220614966801 \
 --data api_accesskey=32d42f0f0b6c89616d42aed8c96801e6 \
 --data transaction_type=SALE \
 --data transaction_amount=1.00 \
 --data response_format=JSON \
 --data ach_sec_code=WEB \
 --data token_id=000000104601 \
 --data reissue=1 \

Forcing or Bypassing ACH Verification

Because there can be instances where you may want to force or bypass Real-time ACH Account Verification, we have added an API parameter called validate_ach_account.

When this flag is set equal to 1 or true the transaction will be routed through ACH verification regardless of any past verification data.

When this flag is set equal to 0 or false the transaction will not be routed through ACH verification.

Example usage:

curl --request POST \
 --url https://cert.payconex.net/api/qsapi/3.8 \
 --header 'Content-Type: application/x-www-form-urlencoded' \
 --data account_id=220614966801 \
 --data api_accesskey=32d42f0f0b6c89616d42aed8c96801e6 \
 --data tender_type=ACH \
 --data transaction_type=SALE \
 --data transaction_amount=1.00 \
 --data response_format=JSON \
 --data ach_sec_code=WEB \
 --data bank_routing_number=123123123 \
 --data bank_account_number=123456789 \
 --data validate_ach_account=1 \
 --data first_name=Blue \
 --data last_name=Fin

API Response Examples for ACH Transactions

There will be two new additional parameters returned when Real-time ACH Account Verification is enabled.

  • ach_verification_passed: returns true (1) if verified or false (0) if not verified.
  • ach_verification_message: returns the reason/message from the Microbilt service in the event the ACH account cannot be verified. In the case that the ACH account is verified it will read "Accepted", and if the ACH account has been previously verified it will be populated with "Previously verified".

The following are examples of the PayConex API response using the DEBUG response format:

Verification Passed

array (
 'transaction_id' => '000000000372',
 'tender_type' => 'ACH',
 'transaction_timestamp' => '2021-10-18 06:45:21',
 'card_brand' => 'ACH',
 'transaction_type' => 'SALE',
 'last4' => '4987',
 'authorization_code' => 'ACH',
 'authorization_message' => 'PENDING',
 'request_amount' => 1.0,
 'transaction_amount' => 1.0,
 'first_name' => 'Test',
 'last_name' => 'Dev',
 'keyed' => true,
 'swiped' => false,
 'entry_mode' => 'keyed',
 'transaction_approved' => true,
 'gateway_id' => NULL,
 'currency' => 'USD',
 'card_expiration' => NULL,
 'ach_verification_passed' => true,
 'ach_verification_message' => 'Accepted',
 'error' => false,
 'error_code' => 0,
 'error_message' => NULL,
 'error_msg' => NULL,
)

Account Previously Verified

array (
 'transaction_id' => '000000000375',
 'tender_type' => 'ACH',
 'transaction_timestamp' => '2021-10-18 06:47:10',
 'card_brand' => 'ACH',
 'transaction_type' => 'SALE',
 'last4' => '4987',
 'authorization_code' => 'ACH',
 'authorization_message' => 'PENDING',
 'request_amount' => 1.0,
 'transaction_amount' => 1.0,
 'first_name' => 'Test',
 'last_name' => 'Dev',
 'keyed' => true,
 'swiped' => false,
 'entry_mode' => 'keyed',
 'transaction_approved' => true,
 'gateway_id' => NULL,
 'currency' => 'USD',
 'card_expiration' => NULL,
 'ach_verification_passed' => false,
 'ach_verification_message' => 'Previously verified',
 'error' => false,
 'error_code' => 0,
 'error_message' => NULL,
 'error_msg' => NULL,
)

ACH Account Not Verified

array (
 'transaction_id' => '000000000368',
 'tender_type' => 'ACH',
 'transaction_timestamp' => '2021-10-18 06:42:52',
 'card_brand' => 'ACH',
 'transaction_type' => 'SALE',
 'last4' => '8319',
 'authorization_code' => 'ACH',
 'authorization_message' => 'NOT BATCHED',
 'transaction_amount' => 1.0,
 'first_name' => 'Kevin',
 'last_name' => 'Williams',
 'keyed' => true,
 'swiped' => false,
 'entry_mode' => 'keyed',
 'transaction_approved' => false,
 'reason_code' => NULL,
 'network' => NULL,
 'gateway_id' => NULL,
 'currency' => 'USD',
 'card_expiration' => NULL,
 'ach_verification_passed' => false,
 'ach_verification_message' => 'History of unauthorized',
 'error' => true,
 'error_code' => 30002,
 'error_message' => 'DECLINED',
 'error_msg' => 'DECLINED',
)

Updated over 2 years ago