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.
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:
POST /payments
{
"amount": 100,
"paymentMethod": {
"token": "8b8c84b2-0f7b-443d-8286-ba2d3eb38f07"
}
}
{
"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.
To void the example payment above, which has a paymentId of 64c8b2d373a070c620b6ef6e, the request would be as follows:
POST /payments/64c8b2d373a070c620b6ef6e/void
{
"amount": 100
}
{
"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,
GET /payments/64c8b2d373a070c620b6ef6e
{
"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 are different from credit card statuses. ACH Transfers support the following statuses: pending, processed, canceled, failed, or funded.
pending - A pending transfer hasn't been sent to the payment network or has been sent but not processed. This means that it may still be cancellable or may result in a transfer failure.
processed - The meaning of a "processed" status varies based on the transfer destination. If it's going to a Dwolla Wallet, the funds have cleared successfully. If it's going to a linked bank account, enough time has passed for the funds to clear into that account.
canceled - A transfer can be canceled in two ways: either Dwolla cancels it systematically, or your application sends an API request. If a funding source is removed during the transfer's journey to that bank account, Dwolla will cancel the transfer.
failed - A failed status is associated with an ACH network return, meaning that Dwolla received an ACH return code from the RDFI (Receiving Depository Financial Institution). You can fetch the failure reason via an additional API request.
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.