Funding Transactions

ACH Funding

Overview

ACH Funding Transactions initiate a Same-Day ACH debit from the user's bank account to the Payer's merchant account. Funds are debited/posted 3 times per business day. Transactions initiated after the last submission deadline debit/post the following business day. Funds are debited and posted at the times below:

Submission DeadlineEstimated Posting Time
9:15AM EST1:00PM EST
1:30PM EST5:00PM EST
3:30PM EST6:00PM EST

API Workflow

Funding Transactions follow the same pattern as the Payouts workflow.

  1. Create Recipient (referred to as "user" in this guideline)
  2. Add Bank Account
  3. Create Transaction

Transaction Methods

MethodDescription
ACH_FUNDINGACH Funding transaction with optional Risk Mitigation parameters
ACH_FUNDING_PLUSACH Funding transaction with optional Risk Mitigation parameters and automatic Retry workflow upon R01 Failure

Webhooks

Webhook notifications are a critical component of the Funding Transaction workflow. Webhooks are sent for the following events:

  • Bank Account successfully added, re-authenticated, pending expiration, or permission revoked. See Webhooks documentation for Bank Account payload examples.
  • Transaction status changed
    • Possible statuses:PROCESSING, RETRY, FAILED, PAID, REVERSED, REFUNDED,REFUNDED_PARTIAL

Bank Account Widget

Plaid

The Bank Account Widget utilizes Plaid Link to handle bank account authentication. Users can verify and link their accounts by selecting their institution logging directly into their bank account to grant access. Plaid Link is mobile friendly and increases conversion rates. Only Plaid-linked accounts are eligible for ACH Funding transactions. To add a Plaid-linked account, call the Create Bank Widget for the user. A webhook is sent when the user successfully adds their bank account.

📘

Bank Authorization Expiration

A banking institution may require a user to re-authenticate and re-link their account with Plaid at their own discretion. A transaction request with an account that requires a re-authentication will result in a ERR_ACCOUNT_RE_AUTH_REQUIRED error response. This action can be handled using the Create Bank Account widget and including the existing account_id value. Upon successful re-authentication, a webhook will be sent and the transaction can be re-attempted.

Widget Domain

The Bank account widget will be served from linkyouraccount.com. This allows the Plaid Link UI to be shown from a stand alone browser window or native web view without exposing Interchecks as the service provider. Plaid Link will be co-branded with your client logo and Plaid.

Referencing the widget_url from an iFrame is not recommended for native apps instantiating a web view component.

Widget Workflows & Outcomes

The Widget UI Workflow handles the following:

  • Plaid Link UI rendered
    • Plaid Description
    • Institution Selection
    • Bank Login
      • Major banking institutions handle login UI with MFA
    • Grant account access to their Checking or Savings accounts
  • Interchecks redirects control back to client if successful
    • Webhook is sent with new account_id

Error Scenarios

User ActionResult
Exits Plaid WorkflowRedirect back to ACH Authorization page
Invalid Login with BankPlaid or Bank shows error, allows retry
Plaid session times out (15 minutes)Redirect back to error page, user has exit page and restart workflow from Client's site or app.

Funding Risk Mitigation

The Transaction API allows the Client to indicate risk associated parameters in the request body. Sample requests structures for funding_options can be found on the Create Transaction page and are only applicable to the ACH_FUNDING and ACH_FUNDING_PLUS methods. Risk-related error codes will include a funding_options_response object with configured threshold values and actual values. Response payload examples can be found on the Create Transaction page.

📘

Risk Settings

Our Risk and Onboarding teams facilitate the setup of transaction velocity limits, funding balance requirements, and risk score thresholds. These parameters can be setup per user segment (VIP or Tier of a user on a client's platform). The user_segment parameter can be supplied per Transaction API request.

  • Transaction Velocity Limits - Checks completed transactions from the last 24, 48, and 72 hours to determine if activity is within defined limits. Velocity checks are completed with every transaction request.
  • Balance Check - Retrieves the user's bank balance to confirm funds are available prior to processing the transaction. The balance check requirements can be configured in tiers based on transaction amount. The parameter balance_check parameter indicates if the transaction requires a balance check. In some instances we will enforce a balance check based on certain conditions or situations such as retry transactions.
  • Risk Check - Evaluates risk metrics associated with the user's bank account and bank transaction history. Tier level can also be indicated in the request. The parameters risk_check and risk_level indicate a risk evaluation is required. Two optional parameters ip_address and user_agent can also assist in determining the authenticity of the funding request.

Retries

Transactions processed as ACH_FUNDING_PLUS will automatically go into the retry workflow if the initial transaction is returned with an R01 (Insufficient funds) or R09 (Uncollected Funds) ACH return codes. Upon failure, the transaction status is updated toRETRY and will be re-attempted up to 3 times after 3, 7, and 15 days from the failure date. The transaction will remain in a RETRY status only if it fails the balance check fails. A failure for any other reason will result in a FAILED transaction status.

Chargebacks

Transaction chargebacks occur when the user disputes the ACH transaction. Funds are automatically credited back to the user's bank account. A chargeback kicks off an internal process to prevent subsequent transactions against the user's bank account:

  • User's bank account is deactivated
  • Webhook sent indicating account status isBANK_ACCOUNT_BLOCKED
  • Subsequent transactions referencing the user's account_id will result in an ERR_INVALID_ACCOUNT_ID response
  • If the user adds the same bank account through the Bank Widget and another chargeback occurs, the bank account cannot be re-added
  • If the user has 3 total blocked bank accounts, we will prevent additional bank accounts from being added

Refunds

ACH Funding Transactions can be refunded with an ACH Payout Transaction using the method ACH_REFUND. The ACH_REFUND method requires an originating_transaction_id to reference the original transaction being refunded. Interchecks supports full refunds and partial refunds. The original transaction status will be updated to REFUNDED or REFUNDED_PARTIAL upon processing the transaction request. A refund request for an amount lower than the original transaction amount will automatically process as a partial refund. Samples can be found on at Create Transaction. Error codes specific to Refunds can be found at About Transactions.

Process Workflows