Skip to main content

ACH Payments

The Exact Payments Payfac platform supports ACH payments in addition to credit/debit cards. This is a payment acceptance option (pay-in) where buyers pay sellers (merchants on our platform) using their bank account.

Processing Overview​

There are 4 steps required for processing ACH payments on our Payfac platform.

Seller account creation

A merchant on the Payfac platform must be onboarded for ACH either at the time of submitting a merchant application or subsequently by our Merchant Support team. In the application process, on the final screen, there is a Click to Agree to ACH Terms & Conditions that must be accepted for our platform to make an automated call to create the account on Dwolla’s system (referred to as a Business Verified Customer).

Buyer account creation

Once a seller is onboarded for ACH, they are then able to use our APIs to create buyers, tokenize and vault payment method (ACH) details on the Payfac platform. Create Payment Method call.

Buyer Account Verification

For ACH payments, additional validation of the funding source is required before transaction processing can take place. Exact offers two mechanisms to facilitate this: instant verification via Plaid , or through micro-deposits. Micro-deposits are two small deposits sent by Exact to the bank account. The account owner will need to confirm the amounts received using our endpoint "Verify Microdeposits"

At completion of step 3, a ‘Customer’ (buyer) with an attached tokenized ACH payment method has been created on the platform and is ready to be used for payment initiation (both one-time and recurring payments).

ACH Payment Initiation

To initiate ACH payments, a Software partner (or merchant) uses the Post Payments API.

Terms and Conditions​

Exact's onboarding API or hosted application both mandate a Terms & Conditions click to agree button. When a merchant account is being onboarded, ACH Terms and Conditions must first be accepted. This is mandatory to enable account activation and is found at the end of the onboarding message. Create Onboarding.

Supported ACH transfers scenarios:

Payment In (Debit) - Funds are pulled from the sender’s bank account (source) into the merchant bank account.

Payment Out (Credit) - Funds are pushed into the recipient's bank account (destination) from the merchant bank account. ACH Credit transactions can be utilized by a merchant to refund money back to a buyer.

ACH credits do not need to be tied to a previous sale transaction, however Exact supports linking original debits to credit transactions for easier reconciliation. Please contact our customer support team for required backend enablement to support this feature.

Accepting ACH Payments​

In Step 1, Merchants are onboarded to the Payfac platform which includes creation of a verified bank account. This bank account will be the destination funding account into which all ACH payments will be made.

In Step 2, the merchant creates buyers with associated ACH payment methods which are set-up on the Payfac platform and available for future payments. Buyer set-up requires a one-time bank account validation using either Plaid instant verification process or micro-deposits. Once verified, the customers ACH account details are tokenized for all future transactions.

A more detailed description of the available options for creating ACH payment methods is available on our ACH Platform Tokens page.

Once you have created an ACH payment token for your customer, you can then use that token when creating payments. Below are a few transaction examples.

Let's assume the token you received was 8b8c84b2-0f7b-443d-8286-ba2d3eb38f07. To charge $1 to that ACH payment method, the request would be as follows:

Request: ACH Payment
POST /payments
{
  "amount": 100,
  "paymentMethod": {
    "token": "8b8c84b2-0f7b-443d-8286-ba2d3eb38f07"
  }
}
Response: ACH Payment
{
  "id": "64c8b2d373a070c620b6ef6e",
  "paymentId": "64c8b2d373a070c620b6ef6e",
  ...
  "type": "ach",
  "status": "pending",
  "approved": true,
  "captured": true,
  "authorization": "I4EM4E8O",
  "amount": 100,
  "sentToBank": true,
  "settled": false,
  ...
  "currencyCode": "USD",
  "ach": {
    "clearing": "next-day"
  }
}

Once a payment has been created, a paymentId will be returned in the response which can then be used for followup requests through our Payments API.

Note that the response indicates that the payment is not yet processed status: pending,and that in this example our default clearing is next-day.

Voiding an ACH Payment​

If an ACH payment has not yet been processed, you can submit a void request which has the effect of canceling the transfer. Transfers can be canceled for both ACH debit payments (payments in) and ACH credits (payment out).

To void the example debit payment above, which has a paymentId of 64c8b2d373a070c620b6ef6e, the request would be as follows:

Request: ACH Void
POST /payments/64c8b2d373a070c620b6ef6e/void
{
  "amount": 100
}
Response: ACH Void
{
  "id": "64c8b61673a070c620b6ef7f",
  "paymentId": "64c8b61673a070c620b6ef7f",
  ...
  "type": "void",
  "status": "completed",
  "approved": true,
  "settled": false,
  "authorization": "I4EM4E8O",
  "amount": 100,
  "sentToBank": true,
  ...
  "currencyCode": "USD",
  "ach": {
    "clearing": "next-day"
  }
}

Note that you can only void the full amount of the original payment.

Looking up a Payment​

Now that we've voided the initial payment, let's lookup the details of that payment to see what has changed. Note the following 3 fields: "type": void , "status": completed, "approved": true,

Request: ACH Get Details
GET /payments/64c8b2d373a070c620b6ef6e
Response: ACH Get Details
{
  "id": "64c8b2d373a070c620b6ef6e",
  "paymentId": "64c8b2d373a070c620b6ef6e",
  ...
  "type": "ach",
  "status": "voided",
  "approved": true,
  "voided": true,
  "settled": false,
  "authorization": "I4EM4E8O",
  "amount": 100,
  "sentToBank": true,
  ...
  "currencyCode": "USD",
  "voidDetails": {
    "voids": [
      "64c8b61673a070c620b6ef7f"
    ]
  },
  "ach": {
    "clearing": "next-day"
  }
}

You can see that the original payment has been voided status: voided, approved: true, voided: true, and there's a voidDetails element which contains the paymentId of the void transaction.

ACH Statuses​

Webhook notifications from the ACH processor advise Exact of status change events. ACH Statuses are different from credit card statuses. ACH Transfers support the following statuses: pending, completed, processed, canceled, failed, or funded.

ACH Debit Responses​

  • Approved - if true, the transaction reached our ACH processor and was initiated in their system, if 'false', it was not initiated at the ACH processor and status will change to 'failed'
  • Captured - if true, the transaction reached our ACH processor and was initiated in their system, if 'false', it was not initiated at the ACH processor and status will change to 'failed'
  • Sent to Bank - if true, the transaction reached our ACH processor and was initiated in their system, if 'false', it was not initiated at the ACH processor and status will change to 'failed'
  • Settled - is tied to the status (if "status" equals 'failed', this will read 'false')

ACH Status Definitions:​

  • Created - A transfer was created, however we are unable to receive a response from our ACH processor
  • Pending - A transfer will display pending as it processes in the ACH system and continues processing on submission to the ACH account holder's bank. This means that it may still be cancellable or may result in a transfer failure.
  • Completed - A transaction has been sent to and accepted by the ACH processor, but has not yet been processed, therefore it can still be canceled.
  • Processed - A transfer was submitted through the payment network for processing and successfully completed. (funds are cleared)
  • Canceled - A transfer can be canceled in two ways: either it is canceled systematically by the ACH processor in the event that the funding source is removed after the initiation of the transfer and before it exports out of the ACH processors platform, or your application sends an API POST request.
  • Failed - A transfer failed to be submitted to your bank for processing.
  • Funded - We have executed funding instructions to transfer funds to the merchant bank account

Rejects​

It is important for our clients to understand that ACH transactions can reject over the period from initiation to funding (and in certain cases for up to 60 days). Unlike credit/debit cards, where a transaction is authorized in real-time and represents ‘good funds’ which will be paid to the merchant, ACH transactions can reject for a variety of reasons.

In the case that an R code (reject) is received for an ACH transaction, the response will indicate this. Returned transactions are those that are approved and not settled so the "approved" response will be “true” and ''settled" response will be “false.”

In the Transaction report, the Columns "bankResponseCode” will display the specific “R” code, and “bankResponseDesc” will display the return code description.