Overview of ACH
Learn about ACH Payments and review example ACH files.
🏁 Get Started
1. Learn
If you are just learning about TabaPay you can begin at Getting Started, and About TabaPay.
2. Chat
To Make your first API Call, you will first need access to Sandbox. Talk to sales to discuss your use case or get help at [email protected].
3. Test
Once you have access to sandbox from TabaPay Support, look at some code samples with recipes or feel free to post your questions in the developer forum.
Payload Should Be Compact
Each API request body should be formatted in compact JSON when sending a request to the TabaPay API.
Note: If you don’t have access to sandbox, please reach out to [email protected] .
ACH Network is the National Automated Clearing House (ACH) for electronic funds transfers. It processes financial transactions for consumers, businesses, and federal, state, and local governments. ACH processes large volumes of credit and debit transactions in batches. Short for "Automated Clearing House", ACH credit transfers include direct deposit for payroll, Social Security and other benefit payments, tax refunds, and vendor payments. ACH direct debit transfers include consumer payments on insurance premiums, mortgage loans, and other kinds of bills.
The rules and regulations that govern the ACH network are established by National Automated Clearing House Association (NACHA). In 2018, the network processed 23 billion transactions with a total value of $51.2 trillion.
Available in Unified API
TabaPay ACH is available via both our Unified API as well as via file-based exchanges.
For more information please look at our ACH via API guide.
Want to get enabled for ACH in Unified API? Email [email protected]
How ACH Payments Work
For each ACH payment from a payor's bank account to a payee's bank account, there are effectively two ACH transactions created and transmitted, namely an ACH Debit transaction and an ACH Credit transaction. In the case of a payor and payee having an account at the same financial institution, there is only one ACH transaction, which is often called an "on-us" transaction.
ACH Debit transaction
The payee's sending institution creates, batches, and transmits an ACH Debit transaction to the payor's receiving institution. The ACH Debit transaction instructs the receiving institution to withdraw and transmit the funds from the payor's bank account to the sending institution.
The receiving institution must send the return to the sending institution by the end of the following business day if it is unable to debit the funds from the payor's account, such if the account was not found, the account was closed, or the account was frozen.
For an ACH Debit transaction, the sending institution may be a third-party bank, rather than the payee's bank.
ACH Credit transaction
The payor's sending institution creates, batches, and transmits an ACH credit to the payee's receiving institution. The ACH Credit transaction instructs the receiving institution to credit the funds to the payee's bank account.
The receiving institution must send the return to the sending institution by the end of the following business day if it is unable to credit the funds to the payee's account, such if the account was not found, the account was closed, or the account was frozen.
For an ACH Credit, the sending institution may not be a third-party bank, rather than the payor's bank.
Same Day vs Next Day
There are two types of ACH settlements.
Next-day ACH
ACH debits and credits are transactions that are created, batched, and transmitted typically by way of a financial institution's connection to the ACH Network.
With next-day ACH, each ACH transaction is cleared overnight. The sending institution (called the Originating Depository Financial Institution) sends the transaction to the receiving institution (called the Receiving Depository Financial Institution). When the receiving institution receives the transaction, it has until the end of the next working day to send a rejection to the sending institution. If the sending institution does not receive a return from the receiving institution by the morning of the third business day, then the transaction is deemed to be successful.
Same-day ACH
With same-day ACH, settlement can happen the same day. The sending institution can transmit files to the receiving institution the same day, expediting the processing of ACH transactions. The receiving institution still has two business days in which to send a return, so there will still be a delay of two business days in same-day ACH debit transactions. On the other hand, ACH credit transactions can be credited on the same business day as along as the receiving institution receives the ACH transaction within the correct window.
Transactions exceeding $1,000,000 and international transactions are not eligible for same-day ACH.
API Integration
For how ACH API integration works, refer ACH via API
ACH Files
Refer to ACH File Overview by NACHA to understand ACH file formatting.
File Details
- File sharing details will be provided to the client
- Input File name: yyyymmdd_ISO_MID_ACHInput_N_v2-5.csv (sent to TabaPay)
- Output File name: yyyymmdd_ISO_MID_ACHOutput.csv (received from TabaPay)
- Processed file: yyyymmdd_ISO_MID_ACHProcessed_A.csv (received from TabaPay)
- Comma separator for each field
Input files
- Merchant deposits input file(s) into the file sharing tool.
- All input files since last batch are processed.
- TabaPay moves Input files to 'Inboxprocessed' after processing.
- Email to [email protected] with copy to [email protected]: subject: NAME ACH; total debits and $s, total credits and $s
- Cut-off times:
- File based -> Same day: 7:00 AM PT; Next day: 5:30 PM PT
- API -> Same day and Next day: 12:00 PM PT (Same window)
- File cutoff missed will be moved to next window
- Confirmation of processing email to merchant
- TabaPay output files, processed files, return files:
- Merchant Pickup return files, Processed files, and Output files in the 'Outbox'
- Processed file delivered within minutes of ACH files being processed by bank; One file for each merchant batch.
- Output file delivered next business day; same format as Processed file - with Trace ID and processed time from bank
Guidelines
- All files received prior to same day cutoff are processed as same day, otherwise processed as next day.
- ISO+MID assigned by TabaPay.
- CompanyName, CompanyID assigned by TabaPay.
- IIN must be unique by CompanyName, CompanyID as traceIDs and returns provided by IIN. For Person-to-Person WEB credit Entries, this field is required and contains the name of the consumer Originator. For WEB debit Entries, this field is optional, and is used at the discretion of the Originator.
- Offset account is always merchant's DDA at ODFI. Option to include offset records (default is no offset).
Explanation for each file
There are 4 files associated with ACH.
- Input file -> this file is generated by the merchant and contains the transaction requests.
- Processed file -> this file is generated by TabaPay. It indicates that transactions that have been sent to the bank.
- Status: Processed -> Transaction has been sent to the bank.
- Status: Rejected -> Transaction was rejected, status codes below.
Processed File Is Not a Completed File
A processed file that is generated by does not indicate the payment has been completed, but only that the transaction has been sent to the bank.
- Output file (Conditional) -> This file is generated by some banks to let us know when the transaction was sent to the Fed. This file has the exact same format as the Processed file, and will include the Trace ID from the Fed. Might take up to 2 days to be sent.
- Return file -> This file contains a list of returned transactions. Can come back 6 to 7 days later.
SFTP Push. TabaPay pushes ACH files via SFTP. Security options can include:
- Merchant whitelists TabaPay IP
- SFTP ID and Password
- TabaPay public key for SFTP security (ID or ID+PW)
- File encryption using Merchant public PGP key
ACH Request
Refer to ACH API for fields in the API request. View the following file format option for ACH file requests, or view a NACHA file format.
For file based format refer to ACH File Exchange
ACH Response
Response and Processed File Format
ISO |
Assigned by TabaPay |
||
---|---|---|---|
MID |
Assigned by TabaPay |
||
Entry Type |
CCD, PPD, Web |
3 alpha |
|
Status |
Output file: Complete, Error. Processed file: Accepted or Rejected |
See Response Codes |
|
Result |
0, Response Code |
See Response Codes |
|
Same Day or Next Day |
S, N |
1 alpha |
Same Day must be in by cutoff time or converts to next day |
Processed date |
mm-dd-yyyy |
||
Settlement date |
mm-dd-yyyy |
||
Amount |
########.## |
999999.99 |
2 decimal places |
IIN |
abcdefghijklmnop |
15 alpha-numeric |
No commas, no blanks. No symbols |
Trace ID |
################ |
15 numeric |
Output file only - from bank |
First name |
doe |
22 alpha-numeric combined First Name and Last Name |
No commas, blanks allowed. No symbols |
Last name |
doe |
No commas, blanks allowed. No symbols |
|
Account type |
C/S/L/BC/BS/G |
Up to 2 Alphabet (C, S, L, G, BC, BS) |
Checking(C), Savings(S), Loan (L) Business Checking (BC), Business Savings (BS) General Ledger (G) |
RTN |
######### |
Exactly 9 digits; must have checksum |
Destination Bank Routing Number |
Account |
############### |
4-17 numeric |
Destination Bank account number |
Credit-Debit |
C |
1 alpha C, D |
Credit or Debit (C or D) |
Fee |
##.## |
4 numeric with decimal (signed) |
##.## |
Message |
Processed file contains a descriptive reason of any Rejected entries |
ACH Response File Sample
To zoom in for smaller table values, pinch out on your trackpad. For an Apple Mac, type CMD and the plus sign (⌘ and +). For PC, use CTRL and +.
ISO |
MID |
Status |
Result |
ACH Type |
Processed date |
Settlement date |
Entry Type |
Entry Description |
Credit-Debit |
Amount |
Trace ID |
IIN |
First name |
Last name |
Account Type |
RTN |
Account |
Fee |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1000 |
1 |
Complete |
0 |
N |
03-11-24 |
03-12-24 |
CCD |
D |
100 |
9234000001 |
Samwise |
Gamgee |
C |
123456789 |
4444444444 |
0.25 |
||
1000 |
2 |
Error |
422: Duplicate IIN |
N |
03-11-24 |
03-12-24 |
CCD |
D |
101 |
9234000002 |
Samwise |
Gamgee |
C |
123456789 |
4444444445 |
0.25 |
||
1000 |
2 |
Error |
422: ACHType |
S |
03-11-24 |
03-12-24 |
CCD |
C |
102 |
9234000003 |
Samwise |
Gamgee |
BC |
233456789 |
3333333335 |
0.25 |
||
1000 |
2 |
Error |
422: EntryType |
N |
03-11-24 |
03-12-24 |
PPD |
D |
101 |
9234000004 |
Samwise |
Gamgee |
BC |
123456789 |
4444444445 |
0.25 |
||
1000 |
2 |
Complete |
0 |
S |
03-11-24 |
03-12-24 |
CCD |
C |
102 |
9234000005 |
Samwise |
Gamgee |
C |
233456789 |
3333333335 |
0.25 |
||
1000 |
2 |
Complete |
0 |
S |
03-11-24 |
03-12-24 |
CCD |
C |
102 |
9234000006 |
Samwise |
Gamgee |
C |
233456789 |
3333333335 |
0.25 |
ACH Returns (Includes "Rejects" and "NOCs")
ACH Return File Format
ISO |
ISO |
|
---|---|---|
MID |
MID |
|
Return date |
Date (5_70_75) |
|
Amount |
Amount (6_30_39) |
|
Account |
Account (6_13_29) |
|
RTN |
ABA/Routing (6_04_12) |
|
Name |
Individual Name (6_55_76) |
|
IIN |
Individual ID (6_40_54) |
Matches IIN from input |
ACH RC |
Transaction Code (6_02_03) |
|
Trace |
Trace (80_94) |
|
Bank Discretionary |
Bank Discretionary (6_77_78) |
|
Addenda |
Addenda (7_04_83) |
|
Descriptive Date |
Descriptive Date (5_64_69) |
|
Company Name |
Company Name (5_05_20) |
IIN unique to company name and ID |
Company Discretionary |
Company Discretionary (5_21_40) |
|
Company ID |
Company ID (5_41_50) |
|
Class |
Class (5_51_53) |
|
Entry Description |
Company Entry Description (5_54_63) |
|
Batch |
Batch (5_88_94) |
|
ODFI |
Originating DFI (5_80_87) |
|
Immediate Destination |
Immediate Destination (1_04_13) |
|
Immediate Origin |
Immediate Origin (1_14_23) |
|
File Date |
File Date (1_24_29) |
|
File Time |
File Time (1_30_33) |
|
File modifier |
File Modifier (1_34_34) |
|
Immediate destination name |
Immediate Destination Name (1_41_63) |
|
Immediate origin name |
Immediate Origin Name (1_87_94) |
|
Amount |
Amount_Unsigned (no dollar or comma) |
|
Service CC |
Service Class 2xx (5_02_04) |
|
Julian Date |
Julian_Settle_Date (5_76_78) |
|
Text4 |
Text4 |
|
Text5 |
Text5 |
|
Return Code |
Return Code (7_04_06) |
|
Return Description |
Return Description |
|
Original Trace # |
Original Trace (7_07_21) |
|
Optional Date |
Optional Date (7_22_27) |
|
Original RDFI |
Original Receiving DFI (7_28_35) |
|
Addenda Text |
Addenda Text (7_36_79) |
|
Addenda Trace |
Addenda Trace (7_80_94) |
|
Addenda Type |
Addenda Type (7_02_03) |
|
Returns Origin ID |
Returns Origination Transaction Code (calculated) |
|
Returns RTN |
Returns ABA 9 digit (concatenated) |
|
Amount |
Amount_Unsigned (no dollar or comma) |
ACH Return Codes
Code |
Description |
Detail |
---|---|---|
R01 |
Insufficient funds |
Available balance is not sufficient to cover the amount of the debit entry |
R02 |
Bank account closed |
Previously active amount has been closed by the customer of RDFI |
R03 |
No bank account/unable to locate account |
Account number does not correspond to the individual identified in the entry, or the account number designated is not an open account |
R04 |
Invalid bank account number |
Account number structure is not valid |
R06 |
Returned per ODFI request |
ODFI requested the RDFI to return the entry |
R07 |
Authorization revoked by customer |
Receiver has revoked authorization |
R08 |
Payment stopped |
Receiver of a recurring debit has stopped payment of an entry |
R09 |
Uncollected funds |
Collected funds are not sufficient for payment of the debit entry |
R10 |
Customer advises not authorized |
Receiver has advised RDFI that originator is not authorized to debit his bank account |
R11 |
Check truncation entry return |
To be used when returning a check truncation entry |
R12 |
Branch sold to another RDFI |
RDFI unable to post entry destined for a bank account maintained at a branch sold to another financial institution |
R13 |
RDFI not qualified to participate |
Financial institution does not receive commercial ACH entries |
R14 |
Representative payee deceased or unable to continue in that capacity |
The representative payee authorized to accept entries on behalf of a beneficiary is either deceased or unable to continue in that capacity |
R15 |
Beneficiary or bank account holder |
(Other than representative payee) deceased* - (1) the beneficiary entitled to payments is deceased or (2) the bank account holder other than a representative payee is deceased |
R16 |
Bank account frozen |
Funds in bank account are unavailable due to action by RDFI or legal order |
R17 |
File record edit criteria |
Fields rejected by RDFI processing (identified in return addenda) |
R18 |
Improper effective entry date |
Entries have been presented prior to the first available processing window for the effective date. |
R19 |
Amount field error |
Improper formatting of the amount field |
R20 |
Non-payment bank account |
Entry destined for non-payment bank account defined by reg. |
R21 |
Invalid company ID number |
The company ID information not valid (normally CIE entries) |
R22 |
Invalid individual ID number |
Individual id used by receiver is incorrect (CIE entries) |
R23 |
Credit entry refused by receiver |
Receiver returned entry because minimum or exact amount not remitted, bank account is subject to litigation, or payment represents an overpayment, originator is not known to receiver or receiver has not authorized this credit entry to this bank account |
R24 |
Duplicate entry |
RDFI has received a duplicate entry |
R25 |
Addenda error |
Improper formatting of the addenda record information |
R26 |
Mandatory field error |
Improper information in one of the mandatory fields |
R27 |
Trace number error |
Original entry trace number is not valid for return entry; or addenda trace numbers do not correspond with entry detail record |
R28 |
Transit routing number check digit error |
Check digit for the transit routing number is incorrect |
R29 |
Corporate customer advises not authorized |
RDFI has bee notified by corporate receiver that debit entry of originator is not authorized |
R30 |
RDFI not participant in check truncation program |
Financial institution not participating in automated check safekeeping application |
R31 |
Permissible return entry (CCD and CTX only) |
RDFI has been notified by the ODFI that it agrees to accept a CCD or CTX return entry |
R32 |
RDFI non-settlement |
RDFI is not able to settle the entry |
R33 |
Return of XCK entry |
RDFI determines at its sole discretion to return an XCK entry; an XCK return entry may be initiated by midnight of the sixtieth day following the settlement date if the XCK entry |
R34 |
Limited participation RDFI |
RDFI participation has been limited by a federal or state supervisor |
R35 |
Return of improper debit entry |
ACH debit not permitted for use with the CIE standard entry class code (except for reversals) |
TabaPay Response Codes
Status |
Result |
File |
Message |
---|---|---|---|
Accepted |
0 |
Processed |
|
Rejected |
423 |
Processed |
Invalid input record length |
Rejected |
440 |
Processed |
Invalid entry class |
Rejected |
430 |
Processed |
Invalid ISO |
Rejected |
431 |
Processed |
Invalid MID |
Rejected |
432 |
Processed |
invalid ISO format |
Rejected |
428 |
Processed |
Duplicate or re-used IIN |
Rejected |
409 |
Processed |
Duplicate or re-used IIN |
Rejected |
427 |
Processed |
Invalid entry type |
Rejected |
426 |
Processed |
Invalid ACH type (S, N, R) |
Rejected |
425 |
Processed |
Invalid account type |
Rejected |
452 |
Processed |
Invalid debit or credit indicator |
Rejected |
422 |
Processed |
Invalid RTN |
Rejected |
448 |
Processed |
Invalid amount formt |
Rejected |
449 |
Processed |
Limit exceeded |
Complete |
0 |
Output |
|
Error |
100 |
Output |
Rejected by ODFI |
Notification of Change (NOC)
A Notification of Change (NOC) is just a heads-up that there’s a small update needed for a customer’s bank account info, like the account or routing number. It’s sent by the customer’s bank to notify you to update their records.
When you get an NOC, there's usually no major action needed—your ACH payment should still go through. The key thing is to update the customer’s info to avoid any issues with future payments.
- Receiving Depository Financial Institution (RDFI): The recipient's bank detects the issue with the payment details and sends an NOC to the sender's bank.
- Originating Depository Financial Institution (ODFI): The sender's bank receives the NOC from the RDFI and passes it along to you, or the payment service provider to update the ledger.
- Payment Service Provider, or Sender’s Organization: The initiator of the ACH payment, such as a business or organization that is sending the funds, receives the NOC. They must update their records to correct any mistakes in the customer's bank details to ensure future payments are processed accurately.
Updating Customer Records
In most cases when you receive an NOC, your ACH transaction should still process as expected.
After receiving an NOC, you will need to update your customer records to reflect the change to their account and ensure that future ACH transactions can be processed correctly.
Refer to the National Automated Clearing House Association (NACHA) Operating rules and Guidelines for more information.
NOC Correction (COR) Codes
Clients receiving a NOC Class = COR must incorporate the change (e.g. C04 - account name change).
NOC Code | Description |
---|---|
C01 | Incorrect bank account number |
C02 | Incorrect transit/routing number |
C03 | Incorrect transit/routing number and bank account number |
C04 | Bank account name change |
C05 | Incorrect payment code |
C06 | Incorrect bank account number and transit code |
C07 | Incorrect transit/routing number, bank account number and payment code |
C08 | Corrected foreign routing number |
C09 | Incorrect individual ID number |
C10 | Incorrect company name |
Updated about 2 months ago