/
25 minute read
May 13, 2022

ACH Origination (Beta)

Hidden
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 Direct Deposit feature instead.

ACH origination can also be used by programs to directly transfer funds in or out of their program funding accounts by authorizing an external program account from which to pull or push funds over the ACH network. Using ACH origination to fund the program funding account is more convenient because you avoid initiating transfers from your external account.

Note
ACH origination for cardholders is enabled for Marqeta-managed programs only, and support for Gateway JIT use cases is currently unavailable. For details, contact your Marqeta representative.

Read more about Marqeta’s ACH origination integration in the Program 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
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 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

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

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 Program 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 Program 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 program funding 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 Program 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 Program 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 Program 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 Management 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 Program 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 Program 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:

Status lifecycle flow for ACH transfers

Is this helpful?

Yes
No

For more information on the various supported states, see The status field.

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 payment 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 ach.pull webhook below indicates that the specified ACH transfer completed successfully.

JSON
Copied

Is this helpful?

Yes
No

NACHA ACH return codes

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

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.

Join our developer newsletter