Before initiating an ACH debit, you need to ensure the customer’s account is open, valid, and authorized for debits. PCE’s EWS integration offers real-time verification—eliminating wait times and manual steps—to dramatically reduce returns (e.g. R02, R03, R04) and satisfy Nacha rules for WEB-initiated debits.

Prerequisites

You must have EWS access enabled on your PCE merchant profile
Customer must provide account number, routing number, and account type
Coverage: real-time for U.S. consumer and most business accounts; fallback needed for unlisted FI’s

Compliance / Regulation Mandates

Nacha “Commercially Reasonable” Requirement

WEB SEC code mandates use of automated fraud-detection or validation (e.g., EWS).

Return Mitigation

Early validation helps avoid costly returns within two banking days.

How Instant EWS Verification Works

When you collect routing and account numbers in your UI, call PCE’s EWS endpoint to confirm:

Account Status (OPEN vs. CLOSED)
Ownership Match (name vs. account holder file)
Negative History (recent returns, freezes, or blocks)

If verification passes, proceed with debit origination. If it fails (e.g. ACCOUNT_CLOSED or NAME_MISMATCH), prompt the customer to correct their details or choose another payment method.

Possible Response Codes

VERIFIED – OK to debit
ACCOUNT_CLOSED – reject or re-collect details
NAME_MISMATCH – prompt user to update name
NEGATIVE_HISTORY – decline or require manual review
EWS_UNAVAILABLE – fallback to Prenote or micro-deposit

Integration Considerations

Fallback Strategy: Always implement a secondary path (prenote or micro-deposits) for accounts that EWS cannot verify.
User Experience: For high-volume consumer apps, front-load EWS to reduce drop-off; for B2B, micro-deposits may be acceptable if coverage gaps exist.
Error Handling: Handle EWS_UNAVAILABLE gracefully—queue the transaction for delayed verification rather than outright decline.
Security: Transmit verification requests over TLS and never log full account details in plaintext.