Any idea when we can accept ACH (one-time and recurring) via the usual payment portal?
Is there a simple workaround that doesn’t require paying a subscription fee for a different payment processing service just to be able to accept ACH?
Any idea when we can accept ACH (one-time and recurring) via the usual payment portal?
Is there a simple workaround that doesn’t require paying a subscription fee for a different payment processing service just to be able to accept ACH?
On timing: it isn’t on Wix’s published roadmap. The only payments item listed
there right now is multi-currency payouts in Q2 2026 — nothing about ACH, bank
debit or direct debit. Combine that with the Choice notice still saying
“temporarily unavailable” since March 2025, and direct-to-bank payments still
sitting as an open feature request in the help centre, and the honest read is
that nobody outside Wix can give you a date and there’s no public signal one is
coming. Don’t build a plan around it arriving.
On a simple workaround with no new subscription — there is one, and it’s
probably already switched on: PayPal eCheck. Wix’s own docs describe it as
letting “customers pay directly from their bank account.” Same PayPal
connection you likely already have, no second processor, no monthly fee.
The caveats are real though, so know them before you promise it to anyone:
It clears in 3 to 5 working days, not instantly.
The order sits Pending in your Payments tab and your inventory does not update
until it clears. When it does, the order moves to Completed and you adjust
stock then. For a B2B catalogue with tight stock counts that matters.
You can’t present it as a “Pay by ACH” button. The buyer picks it inside
PayPal’s own flow depending on what their account offers, so you’re not in
control of whether it shows. It’s a route that exists rather than an option you
offer.
I also can’t tell you it covers recurring. eCheck is documented for one-off
store orders; I’ve seen nothing confirming it for subscription billing, so if
recurring is the requirement, test it before committing rather than assuming.
Last thing, on the subscription fee worry — it’s pointed at the wrong cost. ACH
processors generally bill per transaction rather than a monthly platform fee,
so “paying a subscription just to accept ACH” isn’t usually the shape of it.
Worth checking actual per-transaction rates before ruling that path out.
Concretely, the plugin has two halves, because ACH can’t answer at checkout.
In the service plugin file, create the Stripe ACH PaymentIntent and return
pending rather than approved. 5005 is the documented pending code:
export const createTransaction = async (options) => {
// Create the ACH PaymentIntent with Stripe.
// Put the Wix transaction id from options into the PaymentIntent’s
// metadata — the webhook needs it days later to find this order again.
return {
pluginTransactionId: paymentIntent.id,
reasonCode: 5005 // pending, not approved
};
};
export const refundTransaction = async (options) => {
return { pluginRefundId: refund.id };
};
Then an HTTP function catches Stripe’s webhook when the debit finally settles
or bounces, and tells Wix:
import { ok } from ‘wix-http-functions’;
import wixPaymentProviderBackend from ‘wix-payment-provider-backend’;
export async function post_stripeAch(request) {
const body = await request.body.json();
// Verify the Stripe signature before trusting any of this.
const intent = body.data.object;
const wixTransactionId = intent.metadata.wixTransactionId;
if (body.type === ‘payment_intent.succeeded’) {
await wixPaymentProviderBackend.submitEvent({
event: { transaction: { wixTransactionId, pluginTransactionId: intent.id } }
});
}
if (body.type === ‘payment_intent.payment_failed’) {
await wixPaymentProviderBackend.submitEvent({
event: {
transaction: {
wixTransactionId,
pluginTransactionId: intent.id,
reasonCode: 3012,
errorCode: ‘INSUFFICIENT_FUNDS’,
errorMessage: ‘ACH debit returned’
}
}
});
}
return ok();
}
The order sits pending in the dashboard until that webhook lands, then flips to
paid on its own. That’s correct behaviour for ACH rather than a compromise —
you genuinely don’t know for up to four business days whether the money moved.
Stashing the Wix transaction id in Stripe’s PaymentIntent metadata is what saves
you keeping a mapping table. The webhook arrives days after checkout with no
memory of the session, and metadata rides along with it.