less than a minute read • Updated 13 minutes ago
Accept.blue ACH
Connect Foxy to Accept.blue ACH for secure payments.
- Countries
United States
- Features
- Refunds
Accept.blue ACH takes payment directly from a customer's US bank account over the ACH network. It is the ACH counterpart to Foxy's Accept.blue card gateway and uses the same Accept.blue account and the same API credentials.
Supported country: United States.
Read this first: expect ACH transactions in Foxy to stay pending unless you register a notification endpoint at Accept.blue. An ACH payment is recorded as pending when the customer checks out. Settlement happens days later at the bank. Accept.blue ACH is the one ACH gateway on Foxy that can update a transaction afterwards — but only if you register Foxy's notification endpoint in your Accept.blue dashboard yourself, and even then only for certain events. Foxy does not set that up for you. Until you have done it and confirmed it works, plan to reconcile settlement in your Accept.blue dashboard or your bank rather than in Foxy. See ACH payments on Foxy for the full explanation and a suggested reconciliation routine.
Setting up Accept.blue ACH
You will need an Accept.blue merchant account with ACH enabled. ACH is underwritten separately from card processing at most providers — card processing being live on your account does not mean ACH is. Confirm with Accept.blue that your account is approved for ACH before you start.
From Accept.blue, obtain:
your API Source Key
your API Pin
your Webhook Signature Key — Foxy uses this to verify that incoming status notifications really came from Accept.blue
The API Source Key and API Pin are the same credentials used for the Accept.blue card gateway; the Webhook Signature Key is asked for on the ACH payment method only. If you already have Accept.blue card processing connected to Foxy, the API Source Key and API Pin are the same two values you entered there. Accept.blue's support team or their gateway documentation can point you at where each is shown in their dashboard.
Then, in Foxy:
Accept.blue ACH is added alongside your card payment method, not instead of it. A payment method set can hold both Accept.blue and Accept.blue ACH, and customers pick between card and bank account at checkout.
The panel is split into a Live setup block and a Test setup block carrying the same three fields. (The Live heading reads "Live setup (inactive)" while the set has Use live credentials switched off — that is the current state of the set, not a different set of fields.)
Register a notification endpoint at Accept.blue — do not skip this
This is the step that is easy to miss, and missing it is the most likely reason an Accept.blue ACH transaction sits in pending forever.
Accept.blue tells Foxy what happened to an ACH payment by sending a webhook. Foxy is set up to receive and verify those webhooks — that is what the Webhook Signature Key is for; Foxy uses it to check that an incoming notification genuinely came from Accept.blue. But Foxy does not register its webhook address with Accept.blue for you. There is no connect or authorise flow for this gateway that does it automatically. You have to add it in the Accept.blue dashboard yourself.
So, in your Accept.blue merchant dashboard, add Foxy's notification endpoint as a webhook destination for transaction status events, and make sure you do it in the environment you are actually running in — a webhook registered in Accept.blue's sandbox will not fire for live transactions, or vice versa. Accept.blue's support team can show you where webhook destinations are configured.
Two things to know about what happens once it is registered:
Foxy acts on settled, voided and returned status events. Other events Accept.blue may send — intermediate or processing states, for example — are ignored.
If the endpoint is wrong, unregistered, or pointed at the wrong environment, nothing visible happens. There is no error and no warning in Foxy. The transaction simply stays
pending. So do not assume it is working because you saw no complaint: place a test transaction and confirm the status actually changes.
If you would rather not depend on this, that is a reasonable choice — just treat Accept.blue ACH like every other ACH gateway and reconcile in your Accept.blue dashboard. Building your fulfilment logic to cope with a permanently pending order is safe either way.
What the customer fills in at checkout
For an Accept.blue ACH payment, Foxy collects:
Routing number — Notes: The nine-digit ABA routing number of the customer's bank.
Account number — Notes: The bank account number.
Name on account — Notes: The name on the bank account.
Account-ownership checkbox — Notes: See below.
There is no checking/savings selector on this gateway. The checkout does not ask.
The checkout also shows a checkbox the customer has to tick, reading "I represent that I am the owner and/or authorized signer on the checking account above". The checkout will not submit without it, and there is no setting to turn it off. ACH is a pull from someone's bank account, and NACHA — the body that governs the ACH network — expects the account holder to have authorised the debit. See ACH payments on Foxy for more.
Testing
Foxy provides shared test credentials for Accept.blue ACH, so you can run test transactions without setting up your own sandbox account. Leave the Test setup fields as they are.
Those shared credentials exercise the integration only. If you need to test against your own account configuration, get test credentials from Accept.blue and enter them in the Test setup block.
As with every ACH gateway on Foxy, you can confirm that the checkout accepts bank details and that the gateway accepts the submission. Settlement is not something you can reliably rehearse in a sandbox — do not treat a clean test run as evidence that your reconciliation process works.
There are no test card numbers for this gateway — it does not touch cards at all. For card testing, see the Accept.blue article.
Advanced features
No 3-D Secure, no client-side JavaScript. ACH has no equivalent of card authentication, and this gateway needs no SDK or JavaScript on your checkout. It is a plain server-side integration: nothing to load, nothing to style, nothing extra to configure in your checkout template.
No card verification, no AVS, no CSC. There is no card, so none of these apply.
USD only. The gateway does not support multi-currency.
The "Authorize only (no capture)" toggle does nothing here. The setting is present on this payment method and looks like the same control on a card gateway, but turning it on has no effect: Accept.blue ACH always submits an immediate debit. See the note below.
Important notes and caveats
The "Authorize only (no capture)" toggle is inert. Turning it on does not change how Accept.blue ACH behaves — every transaction is submitted as an immediate debit either way. Notably, Accept.blue's own card gateway does implement a real authorize-only flow; its ACH sibling does not. Authorize.net ACH is the one gateway on Foxy where this toggle actually works.
Build for pending, even though status updates are possible here. If you have a datafeed, expect the
statusnode on an ACH transaction to readpendinginitially, and do not write fulfilment logic that assumes an ACH order will reachapproved. Status updates on this gateway depend on a webhook you registered at Accept.blue, on Accept.blue sending an event Foxy acts on, and on that webhook actually arriving — none of which your fulfilment code can rely on. Build it so that a permanently pending order is handled correctly, and reconcile against Accept.blue. See ACH payments on Foxy.ACH is slow and reversible. Settlement takes several days, and a debit can be returned after the fact for insufficient funds, a closed account or a customer dispute. Decide deliberately whether you are willing to fulfil against an unsettled ACH payment.
Refunds and voids can be issued from Foxy. Accept.blue ACH is one of only two ACH gateways where Foxy can send a refund or void request to the gateway — most cannot. Foxy sending the request is not a guarantee Accept.blue will accept it: that depends on Accept.blue's own rules and on how long ago the debit was submitted. If it is declined, take it up with Accept.blue directly.
Troubleshooting
Every ACH transaction is declined while card transactions work. Check with Accept.blue that ACH is approved and enabled on your account. Working card credentials prove nothing about ACH.
Credentials rejected. Confirm the API Source Key, API Pin and Webhook Signature Key are in the section matching the mode you are running in — Live setup if the payment method set has Use live credentials on, Test setup if it does not.
A transaction is still pending days later. First check that you registered Foxy's notification endpoint in your Accept.blue dashboard, in the right environment — that is the most common cause, and it fails silently. See the setup step above. If the endpoint is registered and the transaction still has not moved, bear in mind that Foxy only acts on settled, voided and returned events; anything else Accept.blue sends is ignored. Then see the note at the top of this article and the ACH payments on Foxy guide.
"I turned on 'Authorize only (no capture)' but the debit still happened immediately." Expected. The toggle has no effect on Accept.blue ACH — every transaction is an immediate debit regardless of the setting, even though the same toggle works on Accept.blue's card gateway. Authorize.net ACH is the one ACH gateway on Foxy where this toggle actually changes behavior.