Checking access…

Skip to main content
Version: v2

ACH Consent

ACH (Automated Clearing House) consent is a legal authorization provided by a customer that permits electronic debits from their bank account. This consent is required by NACHA (National Automated Clearing House Association) regulations before initiating any ACH transaction. Without valid consent, no ACH payment can be processed.

Get Started

To integrate ACH consent into your payment flow, follow the Payments Integration Guide for step-by-step instructions and field-level details.

Key Benefits​

Real-world Example

A patient calls their healthcare provider's billing center to pay a bill over the phone. The agent collects verbal authorization, and the provider submits a TEL consent object alongside the payment — meeting NACHA requirements without requiring the patient to fill out any online form.

Without ACH Consent EnforcementWith ACH Consent Enforcement
Payments may violate NACHA regulationsFull NACHA compliance for all ACH transactions
No audit trail of customer authorizationTimestamped consent record with collection method
Higher dispute and chargeback exposureEvidence of consent reduces unauthorized-debit risk
One workflow for all channelsTailored consent types for web, phone, and paper

How It Works​

Consent is collected alongside the payment request and validated before any debit is initiated. The platform supports three NACHA-defined collection types to accommodate different channels:

Consent TypeCollection MethodTypical Use Case
WEBOnline / digitalSelf-service web or mobile payment
TELVerbal / telephonicIVR or agent-assisted phone payment
PPDPhysical / paperSigned paper authorization form

Consent is required for all ACH (bank account) payments. Card payments do not require a consent object.

Payment MethodConsent Required
Bank Account (ACH)Yes — full consent object required
Credit / Debit CardNo
Saved Bank AccountYes — consent must accompany the payment request
IVR Bank AccountYes — TEL consent type required

Business Rules​

Pre-Conditions​

  • A consent object must be present on every ACH payment request.
  • collectionDetails.type must be one of WEB, TEL, or PPD.
  • A consent identifier is required and depends on the payment flow:
    • Session flow (X-Checkout-Id header present): merchantConsentText is required — the full consent text displayed to the customer.
    • Merchant-initiated or guest flow (no X-Checkout-Id): merchantConsentId is required — a reference to a consent record stored by the merchant.

Post-Conditions​

  • Consent valid: The ACH payment proceeds to authorization and capture.
  • Consent missing or invalid: The payment is rejected with a validation error. No debit is initiated.

Constraints​

FieldRule
collectionTimestampRequired when consent object is present. Must be ISO-8601 format (e.g., 2025-07-21T14:30:00Z).
WEB typecollectionDetails.web.ipAddress and collectionDetails.web.userAgent are required.
TEL typecollectionDetails.tel must be present (non-null). inboundPhoneNumber and its sub-fields are optional.
PPD typeagent at the payment request level must be present. No collectionDetails sub-object required beyond type.
Consent Object Schema
"consent": {
  "merchantConsentId": "string",
  "merchantConsentText": "string",
  "collectionTimestamp": "string",
  "collectionDetails": {
    "type": "WEB",
    "web": {
      "ipAddress": "string",
      "userAgent": "string"
    },
    "tel": {
      "inboundPhoneNumber": {
        "countryCode": "string",
        "number": "string"
      }
    }
  }
}

Scenarios​

WEB Consent — Online Payment

Customer agrees to ACH terms by checking a box on the payment page. The platform captures IP address and user agent as proof of digital consent.

{
  "consent": {
    "merchantConsentText": "I authorize ACME Healthcare to debit my account for the amount specified and understand this authorization will remain in effect until I cancel it in writing.",
    "collectionTimestamp": "2025-07-21T10:15:30Z",
    "collectionDetails": {
      "type": "WEB",
      "web": {
        "ipAddress": "192.168.1.100",
        "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)"
      }
    }
  }
}
TEL Consent — Phone / IVR Payment (minimal)

Customer provides verbal authorization over the phone. Only the tel object is required — inboundPhoneNumber is optional.

{
  "consent": {
    "merchantConsentId": "CONSENT-12345-ABCDE",
    "collectionTimestamp": "2025-07-21T14:22:18Z",
    "collectionDetails": {
      "type": "TEL",
      "tel": {}
    }
  }
}
TEL Consent — Phone / IVR Payment (with optional inboundPhoneNumber)
{
  "consent": {
    "merchantConsentId": "CONSENT-12345-ABCDE",
    "collectionTimestamp": "2025-07-21T14:22:18Z",
    "collectionDetails": {
      "type": "TEL",
      "tel": {
        "inboundPhoneNumber": {
          "countryCode": "1",
          "number": "5551234567"
        }
      }
    }
  }
}
PPD Consent — Paper Authorization

Customer signs a physical authorization form. The agent field at the payment request level identifies who collected the consent.

{
  "consent": {
    "merchantConsentId": "CONSENT-67890-FGHIJ",
    "collectionTimestamp": "2025-07-20T09:45:00Z",
    "collectionDetails": {
      "type": "PPD"
    }
  }
}

Edge Cases​

Low Probability — Stale Consent Timestamp

If collectionTimestamp is significantly older than the payment date, it may indicate stale consent. Merchants should ensure consent is collected at or immediately before the time of payment initiation to satisfy NACHA retention requirements.

Low Probability — Missing Consent on Retry

When retrying a failed ACH payment, include a fresh consent object with the new request. Reusing consent from a prior failed attempt may not satisfy NACHA authorization requirements.