White-Label Merchant Portals Integrated with ACH Payment Gateways

Summary

We build white-label merchant portals integrated with ACH payment gateways. Merchants sign in, submit single or batched debits and credits, see the disposition of every item, and pull the reporting they need, while the processor keeps the relationship and the data. Built as a white-label product, the same portal is themed and configured per programme, so a processor can present it under its own brand or a reseller's.

The Challenge

ACH processors move funds into and out of merchant bank accounts, and historically many depended on a third-party agent to capture transactions from the merchant. That intermediary costs commission, constrains the feature set and puts the processor at one remove from the merchants it serves. Internalising that step means taking on the rules. Every entry carries a standard entry class code, and the class determines what authorisation the merchant must hold. Entries carry effective dates and must be submitted ahead of cut-off for a given settlement window. Returns arrive asynchronously and each reason code demands different downstream handling. Exposure is the other hazard: without caps and velocity controls a single bad actor creates unrecoverable losses. And a merchant who finds a reporting discrepancy once stops trusting the portal entirely.

The Solution

Services, not a bolted-on front end

The portal is a front end over a set of services rather than a monolith attached to the gateway:

• Merchant onboarding and configuration.
• User and role management.
• Transaction capture in single-entry and batch upload forms.
• A submission service that talks to the ACH gateway.
• A status and returns processor.
• A reporting layer.

Multi-programme support requires strict scoping: a merchant belongs to a programme, a programme belongs to a processor, and every query is filtered along that hierarchy. Theming, enabled features, transaction types and limits are configuration per programme, not forks of the codebase. The gateway integration is isolated behind an internal interface so that gateway changes, or an additional gateway, do not ripple into the portal.

Payments domain rules and data

Web-initiated consumer debits, recurring prearranged payments, corporate credit or debit entries and telephone-initiated entries each have different authorisation requirements, and same-day windows are priced and deadlined separately. Return reason codes such as insufficient funds, account closed, invalid account number and unauthorised debit are handled distinctly; unauthorised consumer returns in particular carry an extended return window that affects how long exposure remains open. Notifications of change carry corrected account data that is applied before the next entry, or the same error repeats. The portal reports pending, settled and returned counts as first-class state, because that is what a merchant actually needs to see.

Risk, security and compliance

Bank account details are tokenised so the portal stores a reference rather than the account and routing number, with encryption at rest and tight key management regardless. Exposure control is a functional requirement, not an operational one: per-merchant daily and monthly caps, per-transaction limits, velocity checks and hold periods on new merchants. Role-based access separates initiation from approval for higher-value batches. Every action produces an immutable audit record, and originator records including authorisation evidence are retained for the period the rules require.

How we build it

We define the transaction state machine first, covering capture, submission, acknowledgement, settlement, return, correction and reversal, and make every report a projection of that single model. Gateway integration is developed against recorded message fixtures so behaviour can be tested without live submissions, and batch file generation and parsing are validated with golden files before anything is transmitted. Cut-off times and banking holidays come from a maintained calendar rather than hard-coded logic, batch uploads produce a preview and rejection report rather than partial acceptance, and submission is idempotent.

What This Delivers

A processor captures transactions directly from merchants instead of paying an intermediary for the privilege, and keeps both the merchant relationship and the transaction data in house. Merchants see pending, settled and returned items as real state rather than a delayed statement, and reconcile reporting against settlement without discrepancies. New programmes launch as configuration and theming rather than a code fork, and exposure limits are enforced by the system rather than by whoever is watching.

Technologies and Tools

An ACH gateway integration isolated behind an internal service interface, tokenised bank account storage with encryption at rest and managed keys, NACHA standard entry class codes, return reason and notification of change handling, batch file generation and parsing validated with golden files, and a maintained settlement calendar covering cut-offs and banking holidays.