ACH Origination

Note
This feature is currently in beta and subject to change. It also requires additional activation steps. To learn more about the Beta program for this feature and about activating it for your program, contact your Marqeta representative.

Automated Clearing House (ACH) is a payment system that runs on banking networks across the United States. The US Federal Reserve Bank and The Clearing House are the two national ACH payment operators. Every year, US financial institutions process over 25 billion electronic financial transactions—such as direct deposits and direct payments—through the ACH network, which accepts payments 23¼ hours every business day and settles four times daily (as well as a fifth window for same-day transfers). With Marqeta’s current ACH integration, transactions are batched and sent to the network once daily per a predetermined schedule. Similarly, settlement occurs once daily as well. ACH origination occurs when an originator (e.g., a payroll provider) enters an ACH transaction into the ACH payments system according to an arrangement concluded with the receiver. At the end of this guide, you should understand:

What ACH origination is, and some common ways to use it.
The ACH origination end-to-end processing flow for credits and debits.

About ACH

ACH is managed by an organization called NACHA, the National Automated Clearing House Association. In addition to NACHA, completing an ACH transaction requires the involvement of several other participants:

Originator: The originating program which agrees to initiate ACH entries into the payment system, according to an explicit arrangement with a receiver. As a participant in the ACH payments system, originators are required to follow the rules for originators in NACHA’s ACH Operating Rules book.
ODFI: The Originating Depository Financial Institution, which receives payment instructions from the originator and forwards the entries to the ACH Operator. Working with an ODFI, Marqeta takes care of generating the NACHA file that is delivered to the Federal Reserve for settlement.
ACH Operator: This is typically the Federal Reserve, although private ACH operators do exist.
RDFI: The Receiving Depository Financial Institution. The RDFI receives ACH entries from the ACH Operator and posts the entries to the accounts of the receiver.
Receiver: The receiving company or individual which has authorized an originator to initiate the ACH entry.
Third-Party Service Provider: An entity other than the Originator, ODFI, or RDFI that performs any function on behalf of the Originator, ODFI, or RDFI with respect to the processing of ACH entries. A function of ACH processing can include, for example, the creation of ACH files on behalf of an Originator or ODFI.

ACH is a popular method of payment because it offers secure transfers and predictable processing timelines, in addition to low fixed costs per transaction. Furthermore, there is less incidence of fraud on ACH compared to other funding methods because the funding account must be pre-authorized by the account holder before funds are pulled. A standard ACH transaction can take up to four or five business days to complete. This is because the transfers settle within the first 48 hours, then the funds can be held for up to 72 additional hours to allow for the return of any ACH reject notifications. You can configure these timeline values, however, depending on your program and use cases. If you are looking for even faster electronic transfers, use same-day ACH transfers instead. Same-day ACH originations make the funds available within the same business day, but impose higher fees and a per-transaction limit of $100,000. No additional configuration steps or integration on your part is required to benefit from this feature.

ACH on the Marqeta platform

With ACH, your account holders can pay for transactions by debiting their account directly instead of paying with a credit card. This functionality might be part of a banking portal experience that you develop. Use the Marqeta platform’s ACH origination for consumers functionality to process your cardholders’ requests to pull/push funds to their Marqeta account:

To fund their Marqeta account, account holders authorize an external bank account from which they want to pull funds.
Account holders also have the option of pushing funds from their Marqeta account to an external bank account.

To receive ACH transfers that were initiated from outside the Marqeta platform, see the ACH Receiving feature instead. ACH origination can also be used by programs to directly transfer funds in or out of their Marqeta accounts by authorizing an external program account from which to pull or push funds over the ACH network. Using ACH origination to fund the Marqeta account is more convenient because you avoid initiating transfers from your external account. Read more about Marqeta’s ACH origination integration in the Funding via ACH API reference page.

Cardholder account funding via ACH origination

Newly onboarded cardholders must add funds to their Marqeta account before they can begin spending. Cardholders can also push funds from their Marqeta account to an external account if they need to, in order to manage their finances across multiple bank accounts, or transfer funds to friends, family members, or payees. The sections below add a new user to the Marqeta platform, then move money between their Marqeta account and their external funding source account.

Add a new user to the Marqeta platform

Create a user or business on the Marqeta platform.

Create a deposit account on the Marqeta platform using the /depositaccounts/ endpoint. This account can be either a Demand Deposit Account (DDA) or a digital account and will be tied to the user or business created in Step 1.

Add the cardholder’s external funding source account to the Marqeta platform by sending a POST request to the /fundingsources/ach endpoint.

Verify the cardholder’s bank account

In all situations, the cardholder’s external funding source account must be verified in order to send or receive ACH payments. Account verification also helps you minimize costly returns. You can integrate with our partner Plaid to verify external bank accounts on the Marqeta platform. Seamlessly verifying via Plaid enables you to optimize user conversion, as well as shorten wait times to verify the external funding source.

Pull funds to the Marqeta platform

Use ACH origination to pull the cardholder’s funds from the external account to the Marqeta account. Create an ACH transfer by sending a POST request to the /banktransfers/ach endpoint when you onboard a new cardholder and they want to add funds to their Marqeta account in order to begin spending. Ensure that the type field of your request is set to pull. For more information, as well as sample requests and responses, see the Create ACH transfer section of the Funding via ACH API reference page.

Faster ACH pull to the Marqeta platform

When you use ACH origination to pull the cardholder’s funds from their external bank account to their Marqeta account, it can take up to three days for the transaction to clear and the funds to be available to spend in the cardholder’s Marqeta account. If you determine that the cardholder’s risk level is low, and that the associated ACH transfer is unlikely to be subject to return, you can give the cardholder faster access to their funds using the /banktransfers/ach/earlyfunds endpoint. This endpoint is available only for pull-type ACH transfers. The response to a POST /banktransfers/ach/earlyfunds request is similar to the response to a GET /banktransfers API call. Marqeta sends a transaction webhook with the transaction event ach.early.funds when the faster funds ACH transfer is successful, and ach.early.funds.reversed when the original ACH transfer is settled and the faster funds are reversed. To enable this feature for your card program, contact your Marqeta representative. For more information, as well as sample requests and responses, see the Perform faster funds ACH transfer section of the Funding via ACH API reference page.

Push funds to an external account

You can also use ACH origination to push the cardholder’s funds from the Marqeta account to an external account. This is the use case for closing out an account or refunding the cardholder, or when a cardholder on the Marqeta platform wants to perform a me-to-me transfer (money out). Create an ACH transfer by sending a POST request to the /banktransfers/ach endpoint, ensuring that the type field of your request is set to push. For more information, as well as sample requests and responses, see the Create ACH transfer section of the Funding via ACH API reference page.

Program funding via ACH origination

Program funding accounts supply funds for the cardholder account at Marqeta, from which your cardholders can make card payments. Programs must maintain the established minimum required balance in their Marqeta account for the purposes of funding the cardholder account. Once you have linked an external program funding source (as explained in Add a program funding source below), you are ready to pull or push funds using ACH origination.

Add a program funding source

Use the /fundingsources/program/ach endpoint to add an external account to fund your program account for ACH payments. For more information, as well as sample requests and responses, see the Account Holder Funding Sources API reference page.

Pull program funds

To add funds to their program funding account on the Marqeta platform, programs can pull from a linked external account. The minimum required balance for a program funding account varies, depending on the program’s spend. Send a POST request to the /banktransfers/ach endpoint to create this kind of ACH transfer, ensuring that the type field of your request is set to pull. Upon successful completion of the transfer, the Marqeta platform transitions its status to COMPLETED. For more information, as well as sample requests and responses, see the Create ACH transfer section of the Funding via ACH API reference page.

Push program funds

Programs might occasionally have to move funds from the program funding account on the Marqeta platform to an external program account in a me-to-me transfer (money out). For example, an expense management platform might be unable to facilitate a card payment to a given vendor and needs to move funds dedicated for spend off the Marqeta platform in order to use another payment method. Send a POST request to the /banktransfers/ach endpoint to create this kind of ACH transfer, as described in the Create ACH transfer section of the Funding via ACH API reference page. Ensure that the type field of your request is set to push. Upon successful completion of the transfer, the Marqeta platform transitions its status to COMPLETED. Pushed payments fail if the transfer amount exceeds the available balance. The maximum allowable amount for a program funding transfer is currently $999,999.99, but might be configurable based on your program. For more information, contact your Marqeta representative.

Cancelling a recent ACH transfer

It is possible to cancel an ACH transfer, but only within a limited timeframe (i.e., before the transfer has been submitted to the ACH network). You can only cancel an ACH transfer that your program initiated. Send a POST request to the /banktransfers/ach/transition endpoint to cancel an ACH transfer. Ensure the status field of your request is set to CANCELLED. For more information, as well as sample requests and responses, see the Create an ACH transfer transition section of the Funding via ACH API reference page. Cancelling is only permitted for transfers currently in the PENDING state. No other states can transition to CANCELLED. The state of an ACH transfer is provided in the status field of the response. To learn the state of a transfer, either poll manually by sending a GET request to the /banktransfers/ach/{token} endpoint or set up the appropriate ACH webhook. For details on the various supported transfer states, see Viewing status updates and transitions.

Processing and viewing returned items

ACH transactions can be returned via the ACH network within the two-day RDFI return window. Items can be returned for any of the reasons listed in the reason codes table. Incoming ACH returns will be communicated to you on a daily basis, as they happen, if you set up the appropriate ACH webhook. For more information about creating webhooks, as well as sample requests and responses, see the Webhooks API reference page. In the event of a returned ACH transfer, you can reinitiate the transaction, by sending another POST request to the /banktransfers/ach endpoint, as described in the Create ACH transfer section of the Funding via ACH API reference page. RETURNED is a terminal state for ACH transfers; you cannot correct and resend an existing ACH transfer in that state.

Viewing status updates and transitions

To view details of a specific ACH transfer, including its current status, send a GET request to the /banktransfers/ach/{token} endpoint. For more information, as well as sample requests and responses, see the Retrieve ACH transfer section of the Funding via ACH API reference page. You can also subscribe to webhooks to receive a notification whenever the status of an ACH transfer changes. The following diagram shows the status lifecycle flow for ACH transfers:

For more information on the various supported states, see the ACH origination transition events section of Event Types.

ACH webhooks

Webhooks are real-time notifications about API events, sent as they occur to the endpoint you specify. You can subscribe to webhooks for ACH origination bank transfer transition events, such as when funds post to an account. Doing so will allow you to update your implementation and keep your cardholders informed. Similarly, webhooks have been enabled for ACH transaction events to help you manage your ledger. The sample status.completed webhook below indicates that the specified ACH transfer completed successfully.

JSON

{
  banktransfertransitions: [
    {
      "token": "42773d4b-5b99-45e0-a8b8-3a7f475ed140",
      "bank_transfer_token": "b188c288-433b-4678-8a07-4f142d5a0e49",
      "status": "COMPLETED",
      "channel": "SYSTEM",
      "transaction_token": "ab970f50-943a-4e16-ab51-865bd161fe57",
      "created_time": "2024-06-18T04:46:27.943Z",
      "last_modified_time": "2024-06-18T04:46:27.943Z"
    }
  ]
}

NACHA ACH return codes

An ACH transaction can be returned to the ODFI for any of the reasons given below. The value in the column on the left populates the return_code field of the create an ACH transfer transition endpoint. For more information about return reason codes, see NACHA’s Return Reason Code Guide & NOC Booklet. https://www.nacha.org/products/return-reason-code-guide-noc-booklet

Note
The Marqeta platform only supports a subset of these return codes. For the list of return codes supported by Marqeta, see the reason code table in the ACHR Return Reason Codes Guide.

Return Code	Reason	Description
`R01`	Insufficient Funds	Available balance is not sufficient to cover the dollar value of the debit entry.
`R02`	Account Closed	Previously active account has been closed by customer or RDFI.
`R03`	No Account/Unable to Locate Account	Account number structure is valid and passes editing process, but does not correspond to individual or is not an open account.
`R04`	Invalid Account Number	Account number structure not valid; entry may fail check digit validation or may contain an incorrect number of digits.
`R05`	Improper Debit to Consumer Account	A CCD, CTX, or CBR debit entry was transmitted to a Consumer Account of the Receiver and was not authorized by the Receiver.
`R06`	Returned per ODFI’s Request	ODFI has requested RDFI to return the ACH entry (optional to RDFI – ODFI indemnifies RDFI).
`R07`	Authorization Revoked by Customer	Consumer, who previously authorized ACH payment, has revoked authorization from Originator (must be returned no later than 60 days from settlement date and customer must sign affidavit).
`R08`	Payment Stopped	Receiver of a recurring debit transaction has stopped payment to a specific ACH debit. RDFI should verify the Receiver’s intent when a request for stop payment is made to insure this is not intended to be a revocation of authorization.
`R09`	Uncollected Funds	Sufficient book or ledger balance exists to satisfy dollar value of the transaction, but the dollar value of transaction is in process of collection (i.e., uncollected checks) or cash reserve balance below dollar value of the debit entry.
`R10`	Customer Advises Originator is Not Known to Receiver and/or Originator is Not Authorized by Receiver to Debit Receiver’s Account	The receiver does not know the Originator’s identity and/or has not authorized the Originator to debit. Alternatively, for ARC, BOC, and POP entries, the signature is not authentic or authorized.
`R11`	Customer Advises Entry Not in Accordance with the Terms of the Authorization	The Originator and Receiver have a relationship, and an authorization to debit exists, but there is an error or defect in the payment such that the entry does not conform to the terms of the authorization. The Originator may correct the error and submit a new entry within 60 days of the return entry settlement date without the need for reauthorization by the Receiver.
`R12`	Branch Sold to Another DFI	Financial institution receives entry destined for an account at a branch that has been 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 deceased	(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 been 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).
`R37`	Source Document Presented for Payment (Adjustment Entry)	The source document to which an ARC, BOC, or POP entry relates has been presented for payment. RDFI must obtain a Written Statement and return the entry within 60 days following Settlement Date.
`R38`	Stop Payment on Source Document (Adjustment Entry)	A stop payment has been placed on the source document to which the ARC or BOC entry relates. RDFI must return no later than 60 days following Settlement Date. No Written Statement is required as the original stop payment form covers the return.
`R39`	Improper Source Document	The RDFI has determined the source document used for the ARC, BOC, or POP entry to its Receiver’s account is improper.

ENR entries

The following return codes are used for ENR entries, and are initiated by a Federal US Government Agency.

Return Code	Reason	Description
`R40`	Return of ENR Entry by Federal Government Agency (ENR Only)	This return reason code may only be used to return ENR entries and is at the federal Government Agency’s Sole discretion.
`R41`	Invalid Transaction Code (ENR only)	Either the Transaction Code included in Field 3 of the Addenda Record does not conform to the ACH Record Format Specifications contained in Appendix Three (ACH Record Format Specifications) or it is not appropriate with regard to an Automated Enrollment Entry.
`R42`	Routing Number/Check Digit Error (ENR Only)	The Routing Number and the Check Digit included in Field 3 of the Addenda Record is either not a valid number or it does not conform to the Modulus 10 formula.
`R43`	Invalid DFI Account Number (ENR Only)	The Receiver’s account number included in Field 3 of the Addenda Record must include at least one alphameric character.
`R44`	Invalid Individual ID Number/Identification Number (ENR only)	The Individual ID Number/Identification Number provided in Field 3 of the Addenda Record does not match a corresponding ID number in the Federal Government Agency’s records.
`R45`	Invalid Individual Name/Company Name (ENR only)	The name of the consumer or company provided in Field 3 of the Addenda Record either does not match a corresponding name in the Federal Government Agency’s records or fails to include at least one alphameric character.
`R46`	Invalid Representative Payee Indicator (ENR Only)	The Representative Payee Indicator Code included in Field 3 of the Addenda Record has been omitted or it is not valid consistent with the Federal Government Agency’s records.
`R47`	Duplicate Enrollment (ENR Only)	The Entry is a duplicate of an Automated Enrollment Entry previously initiated by a DFI.

RCK entries

The following return codes are used for RCK entries only, and are initiated by an RDFI.

Return Code	Reason	Description
`R50`	State Law Affecting RCK Acceptance	RDFI is located in a state that has not adopted Revised Article 4 of the UCC or the RDFI is located in a state that requires all canceled checks to be returned within the periodic statement
`R51`	Item Related to RCK Entry is Ineligible or RCK Entry is Improper	The item to which the RCK entry relates was not eligible, Originator did not provide notice of the RCK policy, signature on the item was not genuine, the item has been altered or amount of the entry was not accurately obtained from the item. RDFI must obtain a Written Statement and return the entry within 60 days following Settlement Date
`R52`	Stop Payment on Item (Adjustment Entry)	A stop payment has been placed on the item to which the RCK entry relates. RDFI must return no later than 60 days following Settlement Date. No Written Statement is required as the original stop payment form covers the return.
`R53`	Item and RCK Entry Presented for Payment (Adjustment Entry)	Both the RCK entry and check have been presented for payment. RDFI must obtain a Written Statement and return the entry within 60 days following Settlement Date.

Dishonored return entries (ODFI)

The following return codes are used by the ODFI for dishonored return entries.

Return Code	Reason	Description
`R61`	Misrouted Return	The financial institution preparing the Return Entry (the RDFI of the original Entry) has placed the incorrect Routing Number in the Receiving DFI Identification field.
`R67`	Duplicate Return	The ODFI has received more than one Return for the same Entry.
`R68`	Untimely Return	The Return Entry has not been sent within the time frame established by these Rules.
`R69`	Field Error(s)	One or more of the field requirements are incorrect.
`R70`	Permissible Return Entry Not Accepted/Return Not Requested by ODFI	The ODFI has received a Return Entry identified by the RDFI as being returned with the permission of, or at the request of, the ODFI, but the ODFI has not agreed to accept the Entry or has not requested the return of the Entry.

Dishonored return entries (RDFI)

The following return codes are used by the RDFI for contested dishonored return entries.

Return Code	Reason	Description
`R71`	Misrouted Dishonored Return	The financial institution preparing the dishonored Return Entry (the ODFI of the original Entry) has placed the incorrect Routing Number in the Receiving DFI Identification field.
`R72`	Untimely Dishonored Return	The dishonored Return Entry has not been sent within the designated time frame.
`R73`	Timely Original Return	The RDFI is certifying that the original Return Entry was sent within the time frame designated in these Rules.
`R74`	Corrected Return	The RDFI is correcting a previous Return Entry that was dishonored using Return Reason Code R69 (Field Error(s)) because it contained incomplete or incorrect information.
`R75`	Return Not a Duplicate	The Return Entry was not a duplicate of an Entry previously returned by the RDFI.
`R76`	No Errors Found	The original Return Entry did not contain the errors indicated by the ODFI in the dishonored Return Entry.

International payments returns

The following return codes are used by gateways for the return of international payments.

Return Code	Reason	Description
`R80`	IAT Entry Coding Error	The IAT Entry is being returned due to one or more of the following conditions: Invalid DFI/Bank Branch Country Code, invalid DFI/Bank Identification Number Qualifier, invalid Foreign Exchange Indicator, invalid ISO Originating Currency Code, invalid ISO Destination Currency Code, invalid ISO Destination Country Code, invalid Transaction Type Code
`R81`	Non-Participant in IAT Program	The IAT Entry is being returned because the Gateway does not have an agreement with either the ODFI or the Gateway’s customer to transmit Outbound IAT Entries.
`R82`	Invalid Foreign Receiving DFI Identification	The reference used to identify the Foreign Receiving DFI of an Outbound IAT Entry is invalid.
`R83`	Foreign Receiving DFI Unable to Settle	The IAT Entry is being returned due to settlement problems in the foreign payment system.
`R84`	Entry Not Processed by Gateway	For Outbound IAT Entries, the Entry has not been processed and is being returned at the Gateway’s discretion because either (1) the processing of such Entry may expose the Gateway to excessive risk, or (2) the foreign payment system does not support the functions needed to process the transaction.
`R85`	Incorrectly Coded Outbound International Payment	The RDFI/Gateway has identified the Entry as an Outbound international payment and is returning the Entry because it bears an SEC Code that lacks information required by the Gateway for OFAC compliance.

Guides

​About ACH

​ACH on the Marqeta platform

​Cardholder account funding via ACH origination

​Add a new user to the Marqeta platform

​Verify the cardholder’s bank account

​Pull funds to the Marqeta platform

​Faster ACH pull to the Marqeta platform

​Push funds to an external account

​Program funding via ACH origination

​Add a program funding source

​Pull program funds

​Push program funds

​Cancelling a recent ACH transfer

​Processing and viewing returned items

​Viewing status updates and transitions

​ACH webhooks

​NACHA ACH return codes

​ENR entries

​RCK entries

​Dishonored return entries (ODFI)

​Dishonored return entries (RDFI)

​International payments returns

About ACH

ACH on the Marqeta platform

Cardholder account funding via ACH origination

Add a new user to the Marqeta platform

Verify the cardholder’s bank account

Pull funds to the Marqeta platform

Faster ACH pull to the Marqeta platform

Push funds to an external account

Program funding via ACH origination

Add a program funding source

Pull program funds

Push program funds

Cancelling a recent ACH transfer

Processing and viewing returned items

Viewing status updates and transitions

ACH webhooks

NACHA ACH return codes

ENR entries

RCK entries

Dishonored return entries (ODFI)

Dishonored return entries (RDFI)

International payments returns