Skip to main content

GIACT Bank Account Verification for ACH Payments

How GIACT bank account verification works for ACH payments on Adyen, the two validation-option triggers, and how to configure it correctly for a Web Drop-in integration.

GIACT verification checks the validity of a shopper's bank account details (routing and account number) before an ACH payment is processed, helping flag closed, invalid, or high-risk accounts. On Adyen, this is controlled by a merchant-account-level setting that determines when GIACT verification is triggered.

If GIACT verification isn't returning data — even though ACH payments are authorizing normally and test payloads look correct — the most common cause is a mismatched validation option, not a broken integration.

The Two Validation Options

Adyen offers more than one trigger option for GIACT verification. The two most relevant are:

Option

Setting name

Triggers on

Works with Drop-in?

Zero-value transactions only

performGiactVerificationOnZeroAmtACH

Only transactions where amount.value = 0

No — API-only

All ecommerce payments

(standard ecommerce option)

Any transaction with shopperInteraction: Ecommerce

Yes

Key distinction: the zero-amount option is intended for merchants who run a dedicated $0 authorization call purely to validate a bank account before charging it. If an integration only ever sends real-value ACH payments — which is the normal behavior for the Adyen Web Drop-in — that trigger condition is never met, so GIACT silently never fires even though everything else about the payment (including the ACH SEC code and routing/account data) is correct.

Symptom Checklist

This misconfiguration is likely if:

  • ACH payments authorize successfully (no errors, normal AUTHORISATION webhook)

  • Test payloads for both a "pass" and a "fail" bank account behave identically — i.e., the "fail" account does not fail

  • The bankVerificationResultRaw field is missing or empty from every authorization response, regardless of which account number is tested

  • Payments are submitted with shopperInteraction: Ecommerce and a standard SEC code (e.g., WEB)

  • The integration uses the Adyen Web Drop-in (not a separate zero-value verification call)

Correct Configuration for Drop-in Integrations

If the ACH flow goes through the Web Drop-in and only sends real-value payments, the GIACT validation option should be set to All ecommerce payments rather than zero-value transactions only.

This option:

  • Validates on shopperInteraction: Ecommerce

  • Works with Drop-in (no separate $0 call required)

  • Covers both consumer and corporate account types

How to Request the Change

This setting is configured on Adyen's side, not self-service in the Customer Area. To request it:

  1. Open a support case with Adyen (via your Adyen Account Manager or Customer Area → Support)

  2. Reference the merchant account name

  3. State explicitly: "Please switch our GIACT validation option from zero-value transactions to All ecommerce payments, since our integration is Web Drop-in and only sends real-value ACH transactions."

  4. Attach a sample authorization request/response pair showing shopperInteraction: Ecommerce and the SEC code in use

Verifying the Fix

After Adyen confirms the change:

  1. Run a test ACH payment using a known-bad test account/routing number combination

  2. Run a second test using a known-good test account/routing number combination

  3. Check the AUTHORISATION webhook or API response for the bankVerificationResultRaw field — the bad account should return a failure/flag result, and the good account should return a clean verification result

  4. If both accounts still return identical (or empty) results, the configuration change has not propagated — follow up with Adyen support rather than re-testing repeatedly, since the setting is applied account-wide

Rollout to Additional Production Accounts

This setting is applied per merchant account. Each production merchant account collecting ACH needs the same validation option confirmed individually — it does not automatically inherit across accounts on the same platform. It's worth testing on one live account first (e.g., using a small real transaction) before assuming the setting is live everywhere.

Related Notes

  • captureDelayHours: 0 on ACH payments means auto-capture happens immediately at authorization — this is normal ACH behavior and unrelated to GIACT triggering.

  • A failed GIACT verification does not automatically block a payment — how a failed result is handled (decline, flag for review, etc.) is a separate risk-rule configuration and should be confirmed independently if not already in place.

Did this answer your question?