PaymentVision 5.4.3

PaymentVision 5.4.3 is now available in production. The purpose of this release is to add two new features Bank Account Verification Safety Net and Blocked Bank Accounts.

Bank Account Verification Safety Net

Bank Account Verification Safety Net is a new feature of PayAPI that enables bank accounts to be verified as part of a bank account registration request.

What is bank account verification?

Bank Account Verification is a web service provided by Lyons Commercial Data that enables merchants to verify bank account status.

What are the types of responses?

Response Type Description
Accept Means an account is open, with a positive balance (zero or above) in the account. Both the routing and account number must be valid to receive an “accept” status
Deny Means the account was open at one time but is now either closed or a large number of NSFs are stacked against the account (we are not permitted to specify how many when the status is returned).
Insufficient Information Means that the routing number has been verified but the account cannot be located, is invalid, has no activity experience; or the status is unavailable.
Error Means a request was submitted with one or more data parameters missing or improperly formatted.

What’s new?

PaymentVision previously offered bank account verification via a separate request method and as a feature of PayAgent.  It can now be “chained” to AddBankAccount requests, as part of this release.

What are the use cases?

Bank Account Verification has the following use cases:

Use Case Description
ACH Return Rate Management NACHA has established an inquiry process which is triggered when an ACH originator exceeds a return rate threshold*. This can be problematic for subprime merchants, particularly those who enroll customers in auto debit. Bank Account Verification addresses this by enabling ACH originators to chain Bank Account Verification to AddBankAccount requests.
WEB Entry Account Validation Effective January 1, 2020, NACHA is requiring bank accounts to be validated as part of a commercially reasonable fraudulent transaction detection system for WEB debit entries. Bank Account Verification addresses this by enabling merchants to chain Bank Account Verification to AddBankAccount requests within PayWeb 2.

*See NACHA Return Rate Thresholds below for more information.

How does it work?

  1. PayAPI receives a valid AddBankAccount request
  2. If Bank Account verification is enabled for the primary merchant and the run mode is set to real time, then PayAPI verifies the bank account using the Lyons Commercial Data iBankRegistry Account Verification web service
  3. If the Bank Account Verification request returns a Deny, Error or Insufficient Information response, then PayAPI returns an 5055 error response
  4. If the Bank Account Verification request returns an Accept response, then PayAPI continues processing the request as normal

Are there any integration requirements?

So long as the AddBankAccount request method is already  integrated into your software and it is able to dynamically handle new response codes, Bank Account Verification Safety Net can be enabled without any additional software integration requirements.

Error Response

Code Description
5055 The Bank Account does not pass Account Verification – {ErrorMessage}

Implementation

Bank Account Verification can be chained to AddBankAccount requests by creating an Account Verification validation rule at the primary merchant level and setting the Run Mode to Real Time.

AVSValidPay

Configuration

Bank Account Verification can be configured to apply to all capture sources or restricted by capture source.

Limitations

PayAPI

Limitation Description
Request Methods Bank Account Verification can only be chained to AddBankAccount requests.
Sub Merchants In order for Bank Account Verification to be applied to AddBankAccount requests it must be set at the primary merchant level.  Sub-merchants cannot be excluded.
Error Response PayAPI will return the same error response (5055) regardless of whether the Severity Level is set to Warning or Violation within the Bank Account Verification rule.

PayIVR

Bank Account Verification cannot be applied to requests originating from PayIVR.

PayWeb Classic

Bank Account Verification cannot be applied to requests originating from PayWeb Classic.

PayAgent Classic

Bank Account Verification can only be applied on-demand within PayAgent Classic.

PaymentVision Portal

Limitation Description
Restrict by Capture Source Bank Account Verification can only be restricted by capture source when Run Mode is set to Real Time.
Restrict by ACH Class Code Resticting Bank Account Verification by ACH Class Code is not applicable when chaining Bank Account Verification to AddBankAccount requests.
Minimum Amount Establishing a Minimum Amount is not applicable when chaining Bank Account Verification to AddBankAccount requests.

Blocked Bank Accounts

Blocked Bank Accounts is a new feature of PayAPI that enables bank account registration requests to be blocked in the event that the bank account has been flagged.

What request methods can use it?

Blocked Bank Accounts can be chained to the following PayAPI request methods:

  • AddBankAccount
  • MakeACHPayment

What is the use case?

Blocked Bank Accounts has the following use case:

Use Case Description
ACH Return Rate Management NACHA has established an inquiry process which is triggered when an ACH originator exceeds a return rate threshold*.   Bank Account Verification addresses this issue by enabling ACH originators to flag problematic bank accounts so that they can be blocked.

*See NACHA Return Rate Thresholds below for more information.

How does it work?

Flagging a Bank Account

Bank Accounts can be flagged by clicking the new Flag action and entering a reason within the PaymentVision Portal Customer Manager page.  When a bank account is flagged a flag icon is presented within the status column.

Flag

Blocking a Bank Account

  1. PayAPI receives a valid AddBankAccount or MakeACHPayment request
  2. PayAPI checks to see if the bank account is already associated with the customer
  3. If the bank account is not already associated with the customer or is but is unregistered*, then PayAPI checks the merchant’s active validation rules
  4. If Block Flagged Bank Accounts is enabled for the merchant and the run mode is set to real time, then PayAPI checks the bank account against the BankAccountFlags table
  5. If the bank account exists within the BankAccountFlags table and its status is active, then PayAPI returns a 5054 error response

*Subject to limitation within MakeACHPayment request.  See Limitations below for more information.

Configuration

Block Flagged Bank Accounts is configured using the new Block Flagged Bank Accounts validation rule and associating it to the primary merchant.

FlaggedBankAccount

Are there any integration requirements?

So long as one of the above methods is already integrated into your software and it is able to dynamically handle new response codes, Blocked Bank Accounts can be enabled without any additional software integration requirements.

Error Response

Code Description
5054 The bank account is not accepted by the merchant.

Limitations

PayAgent Classic

Blocked Bank Accounts cannot be applied to requests originating from PayAgent Classic.

PayAPI

Limitation Description
Request Methods Blocked Bank Accounts can only be chained to AddBankAccount and MakeACHPayment requests.
Unregistered Bank Accounts While a customer’s bank account that is both flagged and unregistered can be blocked if it is included within an AddBankAccount request, it cannot be blocked if it is included within a MakePayment request.

PaymentVision Portal

Limitation Description
Viewing Flagged Accounts There is currently no way to view flagged bank accounts outside of the Customer Manager screen within PaymentVision Portal.
Unflagging Accounts There is currently no way to unflag an unregistered bank account unless it is registered with another customer, in which case it can be unflagged in the Customer Manager screen within PaymentVision Portal. Unflagging an unregistered bank account that is not already registered with another customer must be performed at the database level by a PaymentVision database administrator.
Run Modes Run Mode options are currently limited to Real Time within the Block Flagged Bank Accounts rule.
Severity Levels Severity Level options are currently limited to Violation within the Block Flagged Bank Accounts rule.

NACHA Return Rate Thresholds

Both of the new features within this release address the following ACH return rate thresholds:

Category Reason Codes Limit
Unauthorized debit entries
  • R05 – Unauthorized Debit to Consumer Account Using Corporate SEC Code
  • R07 – Authorization Revoked by Customer
  • R10 – Customer Advises Unauthorized, Improper, Ineligible, or Part of an Incomplete Transaction
  • R29 – Corporate Customer Advises Not Authorized
  • R51 – Item Related to RCK Entry Is Ineligible or RCK Entry is Improper
.5%
Administrative returns
  • R02 – Account Closed
  • R03 – No Account/Unable to Locate Account
  • R04 – Invalid Account Number Structure
3%
Overall returns All 15%