Collecting debit consent

Proper authorization is your primary defense against disputes, return fees, and reversed transactions. Under Nacha rules, a consumer can dispute a charge only when it was never authorized (or authorization was revoked), processed earlier than authorized, or processed for a different amount than authorized.

Straddle consent_type and SEC Codes

When you create a charge via the Straddle API, the consent_type parameter determines which SEC (Standard Entry Class) code is applied to the ACH transaction. Selecting the correct consent type ensures compliance with Nacha authorization requirements.

Internet consent

Use internet when the customer authorizes through a web browser or mobile app. This is the most common consent type for online businesses. WEB entries require "similarly authenticated" consent—a checkbox, button click, or other electronic acknowledgment.

{
  "consent_type": "internet",
  "device": {
    "ip_address": "192.168.1.100"
  }
}

Signed consent

Use signed when you have a signed agreement on file. This includes e-signatures from DocuSign, Adobe Sign, etc. Straddle applies PPD for individuals and CCD for businesses based on the customer type.

{
  "consent_type": "signed",
  "device": {
    "ip_address": "0.0.0.0"
  }
}

Choosing the right consent type

What Makes an Authorization Valid

For an authorization to be valid under Nacha rules, it must be "written, signed, or similarly authenticated." For internet-initiated transactions (WEB entries), this means complying with the E-SIGN Act through electronic consent mechanisms.

Required data elements

What "similarly authenticated" means

For WEB entries, "written and signed" is satisfied through electronic authentication that verifies the user's identity and records their assent. Acceptable mechanisms include:

• Checkbox consent with explicit acknowledgment
• Button clicks with adjacent authorization text ("By clicking Pay, you authorize...")
• PIN or password entry confirming account ownership

The authorization must be viewable on screen before consent, and you must provide an email receipt or printable confirmation immediately after authorization.

Internet (WEB) Authorization Requirements

WEB entries have specific requirements beyond standard authorization. You must verify the user's identity, obtain their explicit assent, and implement fraud detection systems.

UI implementation options

Choose one of these compliant consent patterns:

<p>
  By clicking "Pay Now", you agree to our 
  <a href="/terms">Payment Terms</a> and 
  authorize ACME Corp to debit your account 
  ending in 6789.
</p>
<button type="submit">Pay Now</button>

<label>
  <input type="checkbox" required />
  I agree to the 
  <a href="/terms">Payment Terms</a> 
  and authorize ACME Corp to debit my 
  account ending in 6789.
</label>
<button type="submit" disabled>
  Pay Now
</button>

Using hyperlinked terms

You don't need to display the full legal text on your checkout screen. You can link to a separate terms document (like Stripe and Venmo do), but:

• The link must be live and easily accessible
• The linked document must contain complete authorization language including revocation instructions
• You must maintain version control to prove which terms were displayed at any given time

Building Your Evidence Package

To successfully defend against disputes, you need a complete audit trail linking the user to the authorization action.

1. Capture the visual context

   Store a screenshot or reproduction of the exact payment page layout the user saw at the time of authorization.

2. Record timestamps

   Log the exact date and time (in UTC) of the authorization action. Include timezone information if displaying local times to users.

3. Verify identity

   Capture identity verification data including IP address, device fingerprint, and session authentication status.

   {
     "ip_address": "192.168.1.100",
     "device_fingerprint": "abc123...",
     "session_authenticated": true,
     "email_verified": true,
     "timestamp": "2024-06-28T14:30:00Z"
   }

4. Maintain version control

   Record which version of your authorization text was live at the specific timestamp. Use version identifiers or content hashes.

Fraud detection requirements

Nacha requires a "commercially reasonable fraudulent transaction detection system" for WEB entries. This typically includes:

• Account validation before first use
• Velocity limits on transaction frequency
• Device fingerprinting
• Geographic or behavioral anomaly detection

Email Receipt Requirements

You must provide customers with a copy of their authorization. For WEB entries, send an email receipt immediately upon authorization.

Required content:

• Merchant name and contact information
• Consent date and payment date
• Payment amount
• Masked account information (last 4 digits)
• Authorization terms (or a link to them)
• How to revoke authorization

TRANSACTION DETAILS
Merchant:     ACME Corp
Consent Date: June 28, 2024
Payment Date: July 1, 2024
Amount:       $50.00
Account:      Chase ****6789

To cancel, email support@acme.com 
at least 3 days before payment.

Recurring and Standing Authorizations

Different authorization types have specific requirements.

Recurring payment setup

When establishing a recurring payment schedule, your initial authorization must specify:

• The amount (or range)
• Frequency
• Start date
• Total number of payments (if applicable)

I authorize [Company Name] to electronically debit my account for $[Amount] on the [Day] of each month, beginning [Start Date]. This authorization will remain in effect until I notify you that I wish to revoke it. I understand I must provide notice at least [X] business days prior to the next billing cycle to ensure cancellation.

Change notification requirements

Standing authorizations

A standing authorization allows consumers to authorize future debits triggered by their own actions (like clicking "Pay Now" in an app) without re-entering bank details or re-displaying full authorization terms.

Requirements:

• The initial setup must clearly specify what actions trigger a subsequent entry
• Retain the original standing authorization for two years after termination
• Retain proof of each affirmative action (button click, etc.) for two years after the transaction

<!-- Initial setup (full authorization required) -->
<p>
  By saving this payment method, you authorize ACME Corp to 
  debit your account when you click "Pay" or "Submit Payment" 
  in our app or website.
</p>

<!-- Subsequent payments (simplified) -->
<p>Pay $75.00 using Chase ****6789</p>
<button>Pay Now</button>

Record Retention Requirements

Authorization Templates

Use these compliant templates as starting points for your implementation.

<p>
  By clicking "Pay Now", you agree to our 
  <a href="/payment-terms">Payment Terms</a> and authorize 
  [Company Name] to debit your bank account ending in [Last 4] 
  for $[Amount] on [Date].
</p>
<button type="submit">Pay Now</button>

<label>
  <input type="checkbox" required name="ach_consent" />
  I agree to the <a href="/payment-terms">Payment Terms</a> 
  and authorize [Company Name] to debit my bank account 
  ending in [Last 4] for $[Amount] on [Date].
</label>

<label>
  <input type="checkbox" required name="recurring_consent" />
  I authorize [Company Name] to electronically debit my account 
  ending in [Last 4] for $[Amount] on the [Day] of each month, 
  beginning [Start Date]. This authorization remains in effect 
  until I cancel by contacting [support email] at least [X] 
  business days before the next scheduled payment.
</label>

<label>
  <input type="checkbox" required name="standing_consent" />
  I authorize [Company Name] to save my payment method and 
  debit my account ending in [Last 4] whenever I click "Pay" 
  or "Submit Payment" in the [Company Name] app or website. 
  I can remove this payment method at any time in my account 
  settings.
</label>

ACH AUTHORIZATION AGREEMENT

By providing your bank account information and agreeing to 
these terms, you authorize [Company Name] ("Company") to 
initiate electronic debit entries to your designated bank 
account for payments you authorize through our service.

AUTHORIZATION SCOPE
You authorize the Company to debit your account for:
- One-time payments you initiate
- Recurring payments you establish
- Subsequent payments under a standing authorization

YOUR RIGHTS
- You may revoke this authorization at any time by contacting 
  us at [support email] or [phone number]
- You must notify us at least [X] business days before the 
  scheduled payment date for the revocation to take effect
- You may dispute unauthorized transactions with your bank 
  within 60 days of the statement date

CHANGES TO RECURRING PAYMENTS
We will notify you at least 10 calendar days before any 
change in the amount of a recurring payment, and at least 
7 calendar days before any change in the payment date.

Common Compliance Mistakes

• Missing revocation instructions — Every authorization must explain how customers can cancel. Include a phone number and/or email address.
• Unclear consent mechanism — "Terms and Conditions" links buried in footers don't count. The authorization must be clearly presented before the user can consent.
• Inadequate identity verification — Capturing only an email address isn't sufficient. At minimum, capture IP address plus authentication status.
• No version control — If you can't prove what terms were displayed when, you can't defend a dispute. Implement versioning for all authorization text.
• Missing email receipts — The receipt isn't optional. Send it immediately and log delivery confirmation.
• Wrong consent_type — Mismatched consent types cause R05 returns. Match consent_type to how authorization was actually obtained.