ACH Origination (Beta)
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
Copy section link
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
Copy section link
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 Direct Deposit 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
Copy section link
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
Copy section link
-
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
Copy section link
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 choose to either integrate with our partner Plaid to verify external bank accounts on the Marqeta platform or you can verify the account independently, as described below. Seamlessly verifying via Plaid enables you to optimize user conversation, as well as shorten wait times to verify the external funding source.
Verifying the account independently
Copy section link
To verify the cardholder’s bank account independently, you could have your cardholder authorize an external bank account from which they want to pull or push funds from either within your banking portal or through a third party. As part of this process, you could then ask them to provide you with their account and routing number. Make small credits and debits to this account (net $0) so that the cardholder can report back to you with the values and validate their ownership of the account.
Once you have successfully verified the account, you are now ready to add this account as an external funding source by sending a POST
request to the /fundingsources/ach
endpoint.
For more information about adding an external funding source via a partner integration, see Create ACH source.
Once you have successfully added the external funding account, you are ready to pull or push the cardholder’s funds using ACH origination.
Pull funds to the Marqeta platform
Copy section link
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.
Push funds to an external account
Copy section link
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
Copy section link
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
Copy section link
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
Copy section link
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
Copy section link
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
Copy section link
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
Copy section link
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
Copy section link
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 status field.
ACH webhooks
Copy section link
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.
NACHA ACH return codes
Copy section link
An RDFI can return an ACH transaction 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
As an RDFI, the Marqeta platform only supports a subset of these return codes. For the list of return codes supported by Marqeta, see the reason codes table of the Direct Deposit API reference.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
Copy section link
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
Copy section link
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)
Copy section link
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)
Copy section link
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
Copy section link
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. |