Account validation with giact

When accepting ACH Direct Debit payments, Nacha requires you to validate the bank account details for consumer accounts (SEC code WEB) on the shopper's first transaction. This validation is mandatory to reduce fraud and minimize payment failures. To help you meet this requirement, we partner with giact gVERIFY.

Using giact gVERIFY allows you to verify the validity and status of a shopper's bank account before initiating a transaction. This verification reduces the chance that payments are returned because of issues such as incorrect routing numbers or closed accounts. Giact checks account information against an extensive proprietary database and static rules, not through real-time access to the bank.

Requirements

Select a validation option

Adyen offers three integration options to trigger the giact validation service, allowing you to comply with Nacha requirements and manage validation costs according to your business model. The configuration is managed on your Adyen account, and you can only select one option. Ask our Support Team to configure the option you need on your account.

Validation options

If you have a Components or Drop-in integration, we recommend the consumer ecommerce payments option because it covers Nacha requirements and is the easiest to use.
If you have an API-only integration, you can use any of the validation options.

Consumer ecommerce payments validation

For Drop-in or Components integrations

1. The shopper selects ACH Direct Debit on the checkout page.
2. The Drop-in or the Component collects the required details (the bank account number, ACH routing number, and account owner's name) from the shopper. Keep the hasHolderName and holderNameRequired configuration parameters set to true. If you change these to false, you will have to collect the account owner's name manually.
3. If this is the shopper's first payment, the shopperInteraction is ecommerce, and the SEC code is WEB, we automatically send the account details to giact gVERIFY for validation.
4. If the account passes validation, we try to process the payment. If the account fails validation, we refuse the payment.
5. If the payment is refused, we show a refusal screen. The shopper can either use a different bank account for the ACH payment, or they can use a different payment method.

For API-only integrations

1. The shopper selects ACH Direct Debit on your payment form.
2. You collect the required details from the shopper as a part of your payment request. To do this, add the required parameters. You need to collect the following details:
   • Bank account number
   • ACH routing number
   • Account owner's name
3. If this is the shopper's first payment and the shopperInteraction is ecommerce, and the SEC code is WEB, we automatically send the account details to giact gVERIFY for validation.
4. If the account passes validation, we try to process the payment. If the account fails validation, we refuse the payment.
5. If the payment is refused, you get a refusal response from the API. The shopper can either use a different bank account for the ACH payment, or they can use a different payment method.

All ecommerce payments validation

For Drop-in or Components integrations

1. The shopper selects ACH Direct Debit on the checkout page.
2. The Drop-in or the Component collects the required details (the bank account number, ACH routing number, and account owner's name) from the shopper. Keep the hasHolderName and holderNameRequired configuration parameters set to true. If you set these to false, you will have to collect the account owner's name manually.
3. If this is the shopper's first payment and the shopperInteraction is ecommerce, we automatically send the account details to giact gVERIFY for validation.
4. If the account passes validation, we try to process the payment. If the account fails validation, we refuse the payment.
5. If the payment is refused, we display a refusal screen. The shopper can either use a different bank account for the ACH payment, or they can use a different payment method.

For API-only integrations

1. The shopper selects ACH Direct Debit on your payment form.
2. You collect the required details from the shopper as a part of your payment request. To do this, add the required parameters. You need to collect the following details:
   • Bank account number
   • ACH routing number
   • Account owner's name
3. If this is the shopper's first payment, the shopperInteraction is ecommerce, we automatically send the account details to giact gVERIFY for validation.
4. If the account passes validation, we try to process the payment. If the account fails validation, we refuse the payment.
5. If the payment is refused, you get a refusal response from the API. The shopper can either use a different bank account for the ACH payment, or they can use a different payment method.

Zero amount payments validation

1. The shopper selects ACH Direct Debit on your payment form.
2. You collect the required details from the shopper as a part of your payment request. To do this, add the required parameters. You need to collect the following details:
   • Bank account number
     • ACH routing number

       Alert your shoppers that some banks have different routing numbers for different transfers. Shoppers should not provide their wire transfer routing number.

     • Bank account type: checking or savings.

       The account type is not verified by giact. But if you use the Advanced flow (the /payments endpoint) you need to specify the account type when you make a payment request for the actual amount. This avoids unnecessary chargebacks due to account type mismatches.

     • Account owner's name
3. You send a [zero-value authorization] (#validate-using-zero-value-authorization) request with the details that the shopper provided. Include the storePaymentMethod and storePaymentMethodMode parameters so you can store the shopper's details as a token to use later when you make the payment request for the actual amount.
4. We send the details to giact gVERIFY and return the outcome in the zero-value authorization response and in the AUTHORISATION webhook.
5. Based on the zero-value authorization response, you decide on your next step. You can either:
   • Make a payment request for the actual amount. Specify the token (storedPaymentMethodId) that was generated when you made the zero-auth request.
   • Ask the shopper to provide correct details or use a different payment method.

Validate using zero-value authorization

If you selected the zero amount payments option, you need to make a zero-value authorization request. After you have gathered the shopper's account details, verify those details.

Select the tab for the endpoint you are using:

Validation result values

In the authorization response, the additionalData.bankVerificationResultRaw parameter can include the following information.

Test and go live

To test your giact account validation integration, you can use specific mock account numbers in our test environment. These details simulate various validation outcomes, allowing you to confirm that your integration correctly handles both successful and unsuccessful scenarios before going live. You can enter these test account numbers directly into the payment details fields when using a Drop-in or Components integration, or include them in the API request body.

The following table lists the specific test account numbers and the corresponding giact status codes they trigger. Use the routing number 122105278 across all test scenarios.

See also