---
title: "Account validation with giact"
description: "Use giact gVERIFY for account validation of ACH Direct Debit payments."
url: "https://docs.adyen.com/payment-methods/ach-direct-debit/verification-with-giact"
source_url: "https://docs.adyen.com/payment-methods/ach-direct-debit/verification-with-giact.md"
canonical: "https://docs.adyen.com/payment-methods/ach-direct-debit/verification-with-giact"
last_modified: "2026-06-01T15:33:15+02:00"
language: "en"
---

# Account validation with giact

Use giact gVERIFY for account validation of ACH Direct Debit payments.

[View source](/payment-methods/ach-direct-debit/verification-with-giact.md)

When accepting ACH Direct Debit payments, [Nacha](https://www.nacha.org) 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

| Requirement          | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
| -------------------- |   |
| **Integration type** | An [online-payments integration](/online-payments/build-your-integration).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
| **Limitations**      | For cost reasons, we recommend using giact validation only on the shopper's initial transaction, and when the shopper changes their account.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
| **Setup steps**      | Before you begin:- Get in touch with your Adyen contact and sign the contract addendum that specifies the terms and conditions for the use of account validation through giact.
- Ask our [Support Team](https://ca-test.adyen.com/ca/ca/contactUs/support.shtml?form=other) to enable giact verification for your Adyen account. For this, you need to [select a validation option](#select-a-validation-option).
- [Add ACH Direct Debit in your test Customer Area](/payment-methods/add-payment-methods).
- In the [Additional settings](/development-resources/webhooks/webhook-types/additional-settings/) of your Standard webhook configuration, under **Bank**, select **Include Bank Verification results**. |

## 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

| Validation option                                                      | Which payments trigger validation?                                                                                                    | Use case                                                                                   |
| ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| [Consumer ecommerce payments](#consumer-ecommerce-payments-validation) | ACH Direct Debit payments with `shopperInteraction` **ecommerce** and [SEC code](/payment-methods/ach-direct-debit#sec-code) **WEB**. | Validate consumer accounts on their first payment, as per Nacha requirements.              |
| [All ecommerce payments](#all-ecommerce-payments-validation)           | All ACH Direct Debit payments with `shopperInteraction` **ecommerce** (any SEC code).                                                 | Validate both consumer and corporate accounts on their first payment.                      |
| [Zero amount payments](#zero-amount-payments-validation)               | All ACH Direct Debit payments with `amount.value` **0**, regardless of `shopperInteraction` or SEC code.                              | Specify exactly when to trigger a call to giact. Only available for API-only integrations. |

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](/payment-methods/ach-direct-debit/api-only#add-additional-parameters-to-your-payments-request). 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](/payment-methods/ach-direct-debit/api-only#add-additional-parameters-to-your-payments-request). 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](/payment-methods/ach-direct-debit/api-only#add-additional-parameters-to-your-payments-request). 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:

### Tab: `/sessions`

1. From your server, make a [/sessions](https://docs.adyen.com/api-explorer/Checkout/latest/post/sessions) request, specifying:

   * `amount.currency`: **USD**
   * `amount.value`: **0**
   * `storePaymentMethod`: **true**
   * `storePaymentMethodMode`: **enabled** or **askForConsent**
   * `shopperReference`: your unique identification of the shopper.

   **Zero-value auth request**

   ```bash
   curl https://checkout-test.adyen.com/v71/sessions \
   -H 'x-api-key: ADYEN_API_KEY' \
   -H 'content-type: application/json' \
   -d '{
       "merchantAccount":"ADYEN_MERCHANT_ACCOUNT",
       "amount":{
           "currency":"USD",
           "value":"0"
       },
       "countryCode":"US",
       "reference":"YOUR_ORDER_NUMBER",
       "recurringProcessingModel": "CardOnFile",
       "shopperInteraction": "Ecommerce",
       "shopperReference":"YOUR_SHOPPER_REFERENCE",
       "storePaymentMethod":"true",
       "storePaymentMethodMode":"enabled",
       "returnUrl":"https://your-company.example.com/..."
   }'
   ```

2. In the [AUTHORISATION](https://docs.adyen.com/api-explorer/Webhooks/latest/post/AUTHORISATION) webhook, check the following parameters:

   * `additionalData.bankVerificationResultRaw`: the details of the validation as reported by giact. See the table with [validation result values](#validation-result-values).
   * `additionalData.bankVerificationResult`: indicates if the account passed the validation. Possible values: **Passed** or **Failed**.
   * `additionalData.storedPaymentMethodId`: an ID representing the shopper's account details. Save this together with your shopper reference, because you need it when making a payment request for the actual amount.

   **Validation result in the AUTHORISATION webhook**

   ```json
   {
     ...
     "additionalData":{
       "bankVerificationResultRaw":"1111: Account Verified - The checking account was found to be an open and valid account.",
       "bankVerificationResult":"Passed",
       "tokenization.shopperReference":"YOUR_SHOPPER_REFERENCE",
       "tokenization.storedPaymentMethodId":"JC5H4P79C9P7KPG6"
     }
   }
   ```

3. Based on the validation result, determine your next step:

   * If the account passed validation, make a payment request for the actual amount using the `storedPaymentMethodId` returned in the AUTHORISATION webhook.

     **Payment after validation**

     ```bash
     curl https://checkout-test.adyen.com/v71/sessions \
     -H 'x-api-key: ADYEN_API_KEY' \
     -H 'content-type: application/json' \
     -d '{
         "merchantAccount":"ADYEN_MERCHANT_ACCOUNT",
         "amount":{
             "currency":"USD",
             "value":"1000"
         },
         "reference":"YOUR_ORDER_NUMBER",
         "paymentMethod":{
             "type":"ach",
             "storedPaymentMethodId":"JC5H4P79C9P7KPG6"
         },
         "recurringProcessingModel": "CardOnFile",
         "shopperInteraction": "ContAuth",
         "shopperReference":"YOUR_SHOPPER_REFERENCE",
         "returnUrl":"https://your-company.example.com/..."
     }'
     ```

   * If the account did not pass validation, ask the shopper for the correct account details or for a different payment method.

### Tab: `/payments`

1. From your server, make a [/payments](https://docs.adyen.com/api-explorer/Checkout/latest/post/payments) request, specifying:

   * `paymentMethod.type`: **ach**
   * `paymentMethod.bankAccountNumber`: the bank account number.
   * `paymentMethod.bankAccountType`: the type of bank account. Allowed values: **checking**, **savings**.
   * `paymentMethod.bankLocationId`: the ACH routing number of the account.
   * `paymentMethod.ownerName`: the name on the bank account.
   * `billingAddress` (Optional): the account owner's address information.
   * `amount.currency`: **USD**
   * `amount.value`: **0**

   **Zero-value auth request**

   ```bash
   curl https://checkout-test.adyen.com/v68/payments \
   -H 'x-api-key: ADYEN_API_KEY' \
   -H 'content-type: application/json' \
   -d '{
       "merchantAccount":"ADYEN_MERCHANT_ACCOUNT",
       "amount":{
           "currency":"USD",
           "value":"0"
       },
       "{hint:state.data.paymentMethod from onSubmit}paymentMethod{/hint}":{
           "type":"ach",
           "bankAccountNumber":"1234567890",
           "bankAccountType":"checking",
           "bankLocationId":"121000358",
           "ownerName":"John Smith"
       },
       "billingAddress":{
           "houseNumberOrName":"50",
           "street":"Test Street",
           "city":"Amsterdam",
           "stateOrProvince":"NY",
           "postalCode":"12010",
           "country":"US"
       },
       "reference":"YOUR_ORDER_NUMBER",
       "recurringProcessingModel":"Subscription",
       "shopperInteraction":"Ecommerce",
       "shopperReference":"YOUR_SHOPPER_REFERENCE",
       "storePaymentMethod":"true",
       "returnUrl":"https://your-company.example.com/..."
   }'
   ```

2. In the zero-value authorization response or the [AUTHORISATION](https://docs.adyen.com/api-explorer/Webhooks/latest/post/AUTHORISATION) webhook, check the following parameters:

   * `additionalData.bankVerificationResultRaw`: the details of the validation as reported by giact. See the table with [validation result values](#validation-result-values).
   * `additionalData.bankVerificationResult`: indicates if the account passed the validation. Possible values: **Passed** or **Failed**.

   **Validation result in zero-value auth response**

   ```json
   {
     ...
     "additionalData":{
       "bankVerificationResultRaw":"1111: Account Verified - The checking account was found to be an open and valid account.",
       "bankVerificationResult":"Passed"
     }
   }
   ```

3. Based on the validation result, determine your next step.

   * If the account passed validation, make a payment request for the actual amount with the same account details that you provided in the zero-value request.
   * If the account did not pass validation, ask the shopper for the correct account details or for a different payment method.

## Validation result values

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

| Code | Description                                                                                                                                                                                                 |
| ---- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1111 | Account Verified - The checking account was found to be an open and valid account.                                                                                                                          |
| 2222 | AMEX Cheque - The checking account was found to be an open and valid American Express account.                                                                                                              |
| 3333 | Non-Participant Provider - This account was reported with acceptable, positive data found in recent or current transactions.                                                                                |
| 5555 | Savings Account Verified - The savings account was found to be an open and valid account.                                                                                                                   |
| 7777 | Account Verified - The checking account was found to be open and have a positive history.                                                                                                                   |
| 8888 | Savings Account Verified - The savings account was found to be open and have a positive history.                                                                                                            |
| 9999 | This account was reported with acceptable, positive data found in recent transactions. Positive history exists for multiple transactions.                                                                   |
| GN01 | Negative information was found.                                                                                                                                                                             |
| GN05 | The routing number supplied is reported as not assigned to a financial institution.                                                                                                                         |
| GP01 | The value for Details will vary depending on the Value for CheckReject reason in the Private Bad Checks List.                                                                                               |
| GS01 | The routing number supplied did not match the format of a valid routing number.                                                                                                                             |
| GS02 | The account number supplied did not match the format of a valid account number.                                                                                                                             |
| GS03 | The check number supplied did not match the format of a valid check number.                                                                                                                                 |
| GS04 | The amount supplied did not match the format of a valid amount.                                                                                                                                             |
| ND00 | No positive or negative information has been reported on the account. This could be a small or regional bank that does not report.                                                                          |
| ND01 | No positive or negative information has been reported on the account. This routing number can only be valid for US Government financial institutions. Please verify this item with its issuing authority.   |
| RT00 | The routing number appears to be accurate however no positive or negative information has been reported on the account. Please contact customer to ensure that the correct account information was entered. |
| RT01 | This account should be returned based on the risk factor being reported.                                                                                                                                    |
| RT02 | This account should be returned based on the risk factor being reported.                                                                                                                                    |
| RT03 | Current negative data exists on this account. Accept transaction with risk. (Example: Checking or Savings account in NSF status, recent returns, or outstanding items)                                      |
| RT04 | This is a Non Demand Deposit Account (post no debits), Credit Card Cheque, Line of Credit, Home Equity, or a Brokerage check.                                                                               |
| RT05 | Current negative data exists on this account. Accept transaction with risk. (Example: Checking or Savings account in NSF status, recent returns, or outstanding items)                                      |

## 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.

| Code | Bank Account Number | Bank Verification Result |
| ---- | ------------------- | ------------------------ |
| 1111 | 0000000016          | Passed                   |
| 3333 | 0000000018          | Passed                   |
| 5555 | 0000000019          | Passed                   |
| ND00 | 0000000008          | Passed                   |
| RT00 | 0000000010          | Passed                   |
| RT03 | 0000000013          | Passed                   |
| GN01 | 0000000001          | Passed                   |
| GS02 | 0000000005          | Failed                   |
| RT01 | 0000000011          | Failed                   |
| RT02 | 0000000012          | Failed                   |
| RT04 | 0000000014          | Failed                   |

## See also

* [Tokenization](/online-payments/tokenization)
* [Webhooks](/development-resources/webhooks)
* [ACH Direct Debit chargebacks](/risk-management/chargeback-guidelines/ach-chargebacks)
