> ## Documentation Index > Fetch the complete documentation index at: https://docs.synctera.com/llms.txt > Use this file to discover all available pages before exploring further. # ACH Payments > If you’re building a service that will enable your customers to send and accept payments, issue cards, or transfer money between accounts at different institutions, chances are you’ll need ACH. ACH is a one-stop shop for a variety of payment use cases. From recurring payments and payroll deposits to online purchases and bill payment, ACH offers a fast and flexible way to send money. Originally established in 1970, expanding support and innovation around ACH payments has led it to become one of the most popular online payment rails in the world. ## What is an ACH Transaction? An ACH transaction (often referred to as an ACH transfer) is an electronic, bank-to-bank money transfer processed through the Automated Clearing House (ACH) Network. You can think of the ACH Network as a postal service for ACH files. Each file can contain up to 1000 ACH entries with each entry representing a transaction being sent from one bank to another. ACH transactions can be used to facilitate Person-to-person (P2P), Business-to-consumer (B2C), and Business-to-business (B2B) payments and is a convenient alternative to card networks, wire transfers, paper checks or cash. In addition to their convenience, ACH transactions are reliable, inexpensive, fast, and most importantly, safe. Most transfers are processed and settled within 1-2 business day with zero cost to the consumer. ## What are the 2 types of ACH Transactions? Each ACH transaction involves 2 primary parties: 1. The **Originating Depository Financial Institution (ODFI)** which is the bank initiating the transaction; and 2. The **Receiving Depository Financial Institution (RDFI),** the bank receiving the transaction. All transactions fall into one of two categories, debit (“pull”) or credit (“push”). ### Push (Credit) Determining if a transaction is a push or pull is always with respect to the receiving account. For example, if Tom, a customer of Bank A wants to send money to John, a customer of Bank B. Tom’s bank can originate an ACH push transaction from his account to John’s account. The term “push” is used interchangeably with “credit”. The result is a credit to John’s (the receiver) account balance and a debit to Tom’s (the sender). A real life use case for push transactions are the deposits that result from an employee signing up for payroll direct deposit. Whenever payday rolls around, the employer’s bank initiates a push/credit to the employee’s bank account. ### Pull (Debit) Alternatively, if Tom want’s to request money from John, Tom’s bank can originate an ACH pull request from his account to John’s. The term “pull” is used interchangeably with “debit”. The result is a debit to John’s account and a credit to Tom’s. This is what occurs when users of a service sign up for recurring bill payments. The service provider ends up debiting the customer’s account via an ACH pull request. This is also the case when a banking customer deposits a check made out to him/her by an account holder at another financial institution. Checks are ultimately translated into pull request on the ACH network. The check contains the account holders routing and account number which are the only pieces of information required to initiate a credit or debit from an account at another institution. There is a difference between the direction of an ACH transaction and the direction of money flow. The direction of the transaction refers to the direction of the ACH message on the network. It always flows from the originator to the receiver while the direction of money flow relates to which account is receiving funds and which account is sending them. This means there are 2 ways to achieve the same direction of money movement. ## Scenario The desired result is to withdraw funds from an account at **Bank A** and deposit them into an account at **Bank B** ### Option 1 (This is how customers fund their accounts) Bank B sends an ACH **debit / pull** transaction requesting funds from the account at Bank A: ### Option 2 Bank A sends an ACH **credit / push** transaction to send funds to the account at Bank B. ## How does Synctera support ACH? From the outside, the ACH workflow may seem simple, but it’s actually quite complex. This is where Synctera comes in. Synctera works with your sponsor bank to serve as your connection to the ACH network and supports sending and accepting ACH transactions from other financial institutions. In ACH terms, Synctera acts as the **ODFI** (Originating Depository Financial Institution) when it comes to originating transactions and the **RDFI** (Receiving Depository Financial Institution) when it comes to receiving them. It means that we take care of all the batch processing and file generation while ensuring that all transactions are reflected in your customer account balances. ### FinTech in the Auth Flow Synctera allows the FinTech to participate in the transaction authorization decision for Inbound ACH Direct Debit. This capability can only be enabled for linked zero balance accounts and can be used to: * Restrict payments to certain institutions * Run your own balance checks against the linked balance carrying account If the transaction is declined by the FinTech, then an ACH return will be sent to the network. The FinTech does not have to participate unless there is an additional approval logic. If the FinTech opts not to participate in the Auth Flow, Synctera will use default authorization logic to authorize the transactions. In order to participate in Auth Flow for Pull (Debit) ACH transactions, the FinTech should support an **Authorization Gateway** and a corresponding **Gateway Endpoint** must be configured on the Synctera side. #### Authorization Gateway An authorization Gateway enables a FinTech to optionally take part in the decision of a Pull (Debit) ACH transaction’s authorization cycle. The FinTech receives an authorization request via the configured Gateway to either **approve** or **decline** corresponding ACH transactions based on the FinTech's own business logic. **Request Body** Synctera sends such information as a `POST` HTTP request to the FinTech about Pull (Debit) ACH transactions that needs to be authorized: ```json JSON theme={"system"} { "customer_id": "2b9cc6f2-d0bd-4d9d-aa20-5e53355f9469", "account_id": "0221e0a7-7774-48a4-8521-e678ec09a53a", "transaction_id": "9b59fc80-9bf5-4749-8dd2-511f183becf2", "settlement_date": "2022-03-25", "effective_date": "2022-03-25", "transaction_type": "incoming_debit", "dc_sign": "debit", "amount": 100, "currency": "USD", "network": "ACH", "company_entry_description": "ACCTVERIFY", "company_name": "PAYPAL" } ``` **Response HTTP code** To signal an authorization request decision, the FinTech must reply with the appropriate HTTP code: * HTTP code `200`: **approve** the corresponding ACH transaction * HTTP code `402`: **decline** the corresponding ACH transaction Receiving any other HTTP code in the response will stop the processing of the corresponding Pull (Debit) ACH transaction. However, in this case the transaction will ***not be declined***, but will be ***retried within 2 days*** until the FinTech responds with either `200` or `402` response. **Response timeout** Synctera waits for the authorization response within the timeout window which **defaults to 1.5 seconds**, but can be configured in the **Gateway Endpoint Configuration**. If the response is not received within the defined timeout window, the corresponding Pull (Debit) ACH transaction will stop being processed. But will ***not be declined*** and will be ***retried with exponential backoff*** until the FinTech sends the response within the defined timeout window. If no response is given within the retry window (default: 35 minutes, configurable per bank/partner via `auth_retry_config`), the ACH will be sent to suspense for a manual review by Payment Operations. #### Gateway Endpoint Configuration To configure a Gateway for the FinTech, a valid publicly accessible `url` must be provided. Additionally, `custom_headers` and custom response timeout in milliseconds `max_wait_ms` can be configured. Also, Gateways may be disabled by setting the `disabled` field to `true`. ```sh Shell theme={"system"} curl \ -X POST \ -H "Authorization: Bearer $apikey" \ -H "Content-Type: application/json" \ $baseurl/v0/ach/gateways \ --data-binary ' { "url": "https://example-fintech.com/ach/auth", "custom_headers": { "key1": ["value1", "value2"], "key2": ["value"] }, "max_wait_ms: 1500, "disabled": false }' ``` ## How are accounts funded using ACH? Once your customers have an account setup, they’ll need to fund their account by originating an ACH pull/debit transaction to be sent to their account at another institution. Synctera refers to this as an [external account](/docs/external-accounts-guide). If you have just created account B on the Synctera platform and you want to add funds to it from account A at another financial institution, its natural to assume that funding involves *pushing* funds from account A to account B. Instead, funding your customers account involves originating an ACH debit/pull transaction with your Synctera account in order to withdraw funds from the external account. ## How do I get started with sending/receiving ACH payments? ### Step 1: Customer Creation 1.1 **Create a Customer** Any individual wanting to transact on the Synctera platform must be stored as a customer in our system. Part of that includes completing the KYC process. See the [Customer guide](/docs/create-a-personal-customer) for details. ### Step 2: Account Creation 2.1 **Create an Account** In order to send and receive ACH payments you will need to create an account and associate it with your customer. [Account Guide](/docs/create-accounts-guide) 2.2 **Create an External Account** In order for your customers to fund their accounts they’ll need to debit funds from an account at another institution. You’ll need to create an external account on the Synctera platform which serves as the internal representation of the account to be debited. [External Account Guide](/docs/external-accounts-guide) ### Step 3: Send/Receive an ACH 3.1 **Send an ACH request** Once the external account has been verified, ACH transactions (credits and debits) can be originated from your customer’s account. If you’re unsure what values to set in your API request take a look at the documentation [here](/reference/addtransactionout). 3.2 **Receive an ACH transaction** As long as your customer has an account that is both active and verified, there is no work required by you or your customer to receive ACH transactions. Synctera will process the incoming transaction and debit/credit the account accordingly. ## What happens after I send an ACH request? After you send a request to originate an ACH transaction, the transaction is placed in a batch which, in turn, is placed in an ACH file to be sent out over the network. Depending on the time that you originate the transaction there may be some delay between the time the transaction is created and the time the file is sent. This is done to align with the [processing schedule](https://www.frbservices.org/resources/resource-centers/same-day-ach/fedach-processing-schedule.html) set by the federal reserve. The date the transaction is sent will ultimately determine when funds are settled across accounts and institutions. It will also have a bearing on if and when an ACH transaction can be returned by the recipient. The responsibilities and guidelines for participants in the ACH system are determined by the National Automated Clearing House Association, better known as NACHA. NACHA operates as the rule making body for all financial institutions wanting to use the ACH system. ## What do I need to do to receive an ACH transaction? Nothing. Unless an incoming transaction needs to be returned (see [Why would an ACH transaction be returned?](#why-would-an-ach-transaction-be-returned)), no action is required. Synctera will process all debit and credits for any ACH transactions that we receive on behalf of you or your customers. Check your Synctera dashboard to view all ACH transaction that have been sent or received. Synctera also supports webhooks to notify you of all ACH transactions. ## How long does it take to process an ACH transaction? The time it takes for the network to completely process an ACH transaction is dependent on a number of variables. The operating schedule of the federal reserve, the operating schedule of each bank, and the time of day the transaction was created are all key factors in determining when a transaction will settle. “Settle”. Integrators can influence the timing of an ACH transaction by setting the `is_same_day` field to `true` when posting a request to send a transaction. However, even when sending “same day” ACH transfers, there are a couple things to keep in mind: * Transactions can be returned up to 2 business days after the settlement day. This introduces risk for fintech’s who choose to make funds immediately available to account owner who have initiated a pull request. The ACH system operates on a “no news is good news” basis. The absence of a return within the 2-day timeframe typically means that the RDFI has accepted the transaction. * “Same day” ACH is only available within certain transmission windows set by the federal reserve. Take a look at the Fed [processing schedule](https://www.frbservices.org/resources/resource-centers/same-day-ach/fedach-processing-schedule.html) for more information on cut off times. In general, transactions submitted (Mon-Fri) by 4:45pm are eligible to settle on the same day. “Same day” is not available on non-banking days (weekends and holidays) and will automatically default to the next available “banking day”. * Submitting incorrect information may cause processing errors that result in delays. Errors may also increase the likelihood of a transaction being returned. ## Why would an ACH transaction be returned? ACH transactions can be returned for a variety of reasons. “Insufficient funds”, “invalid account number”, “account closed” are all fair game but but many of the return reasons are not so obvious. NACHA guidelines specify [85 different codes](https://engineering.gusto.com/how-ach-works-a-developer-perspective-part-2/#appendix) that may be associated with a returned transaction. The good news is that you and your customers are likely to see only the most common ones. Synctera will take care of processing any returned transaction and notify you of the resolution via webhooks. In the event that a returned transaction requires your immediate attention, you will be able to take action through the Synctera dashboard. The dashboard is also were you can generate returns from received ACH transactions. While most transaction failures such as insufficient funds, invalid account, etc., will result in automatic returns, you may occasionally identify transactions that were not authorized and choose to manually initiate a return. ## ACH same day vs non-same day cut-off times | ACH Type | Cut-off time | Comments | | ------------ | ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | Same day | 4:45 pm ET (1:45 pm PT) (Monday - Friday) | Same day ACH payments with effective date of today submitted before 4:45 pm ET will be processed as ‘same day’ ACH | | Non-Same day | 24:00 pm ET (Monday-Friday) | Non same ACH payments with effective date of tomorrow or 2 days in the future submitted before 24:00 will be processed as ‘non-same day’ | **ACH (Debit/Credit) - External bank to Synctera account** | ACH Type | File processing time | Comments | | ------------------------------- | --------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | Same day | 10:30 am ET2:45 pm ET4:45 pm ET | ACH Batch files with same day payments (debits/credits/returns) directed to Synctera accounts will be processed at these times | | Non same day / future dated ACH | 10:30 am ET2:45 pm ET4:45 pm ET8:00 pm ET \*2:15 am ET \* | ACH Batch files with non-same day payments (debits/credits/returns) directed to the Synctera accounts will be processed at these times | Not all of our sponsor banks support 8:00 pm ET / 2:15 am ET exchange times **ACH Returns - External bank to Synctera account** | Return code | Days from original transaction | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ | | **R01:** NSF | 2 Banking Days | | **R02:** Account closed | 2 Banking Days | | **R03:** No Account - Account number structure is valid, but doesn't match individual or Open account | 2 Banking Days | | **R04:** Invalid Account - Account number structure not valid, ie edit check digit or number failed | 2 Banking Days | | **R05:** Unauthorized Debit to Consumer Account Using Corporate SEC Code - A Debit entry that uses a corporate SEC code was transmitted to a consumer but was not authorized by the consumer | 60 Calendar Days | | **R07:** Authorization Revoked - Customer who previously authorized an entry claims, authorization has been revoked from the Originator | 60 Calendar Days | | **R08:** Payment Stopped: The customer has requested the stop payment of a specific ACH Debit Entry | 2 Banking Days | | **R09:** Sufficient ledger balance exists, but value of uncollected items brings available balance below amount of debit entry | 2 Banking Days | | **R10:** Customer Advises Not Authorized, Improper, Ineligible, Part of Incomplete transaction or Improperly reinitiated - Not authorized, wrong amount, debit date before authorized, incomplete transaction, improper source document or exceeds reinitiating attempt | 60 Calendar Days | | **R12:** Account sold to another FI | 2 Banking Days | | **R16:** Account frozen/Entry Returned Per OFAC Instruction - Access to account is restricted due to action by the bank | 2 Banking Days | | **R20:** Non-transaction Account - Policies and regulations restrict activity to account indicated | 2 Banking Days | | **R24:** Duplicate Entry - Entry is a duplication. The trace number, date, dollar amount, etc. match another entry | 2 Banking Days | | **R29:** Corporate Customer Advises Not Authorized | 2 Banking Days | | **R31:** Permissible Return Entry - Sender bank agreed on behalf of the Originator to accept a return after the deadline for an unauthorized corporate entry | Undefined | | **R37:** Source document Presented for Payment - The source document to which an ARC or BOC or POP entry relates has also been presented for payment | 60 Calendar Days | | **R38:** Stop Payment of Source Document - A Stop Payment has been placed on the source document to which the ARC or BOC Entry relates. | 60 Calendar Days | | **R39:** Improper Source Document/Source Document presented for payment - The RDFI determines the source document for the ARC, BOC or POP entry is not an eligible item or was presented for payments | 2 Banking Days | | **R50:** State Law Affecting RCK Acceptance - RDFI is located in a state that has not adopted Revised Article 4 of the UCC or RDFI is located in a state that requires all canceled checks to be returned to the receiver | 2 Banking Days | | **R51:** Item is Ineligible, Notice Not Provided, Signatures not Genuine, Item Altered or Amount of RCK Not Accurately Obtained from the Item | 60 Calendar Days | | | | ## Company Entry Description As of March 20, 2026, NACHA dictates that ACH transactions meeting the requirements for Payroll or Purchase transactions are required to be classified in the Company Entry Description as such: `PAYROLL`: wages, salary, or other similar types of compensation for labor or services. `PURCHASE`: e-commerce purchases authorized by a consumer receiver for the online purchase of goods. This does not include recurring bills such as utilities, mortgages or other types of bill payments. If sending a Payroll or Purchase payment via Synctera ACH, include the `PAYROLL` or `PURCHASE` descriptor in the `company_entry_description` field accordingly. ## Example: Funding a customer account To fund a customer account from an external bank account the Synctera API: ```shell shell theme={"system"} curl \ -X POST \ -H "Authorization: Bearer $apikey" \ -H "Content-Type: application/json" \ https://api.synctera.com/v0/ach \ --data-binary ' { "risk": { "client_ip": "127.0.0.1" }, "customer_id": "{CUSTOMER_ID}", "amount": 100, "currency": "USD", "receiving_account_id": "{EXTERNAL_ACCOUNT_ID}", "dc_sign": "debit", "originating_account_id": "{ACCOUNT_ID}", "reference_info": "Synctera test", "memo": "Synctera test" }' ``` It is important to note a few things in this example: 1. The `receiving_account_id` always refers to an [External Account](/docs/external-accounts-guide). 2. The `originating_account_id` always refers to to an [Account](/docs/create-accounts-guide). 3. The `dc_sign` is always from the perspective of the **receiving** account. So a `debit` to the receiving account results in a credit to the originating account. 4. The `amount` is always in the smallest denomination of the given currency. In this case, the currency is `USD`, which means the amount is in cents. 5. The `customer_id` indicates the person that is making the outgoing ACH request. This customer must be an account holder or authorized signer of `originating_account_id`