ACH Rail Implementation

Business Problem

For a dental practice, completing treatment doesn’t always mean getting paid in full. When the office lets a patient repay through an in house payment arrangement, it has already delivered the care, and carries the risk of collecting the remaining balance.

A declined recurring payment leaves the office chasing money for services already provided. Expired cards, incorrect card details, and canceled cards interrupted collections, while chargebacks added uncertainty and processing fees accumulated with every payment.

Practices faced similar collection challenges when enrolling patients in dental plans with recurring payments. They needed an affordable, dependable way to collect without repeatedly asking patients to update their cards.

Wellfit offered only credit and debit card payments. That limitation made some practices reluctant to offer payment arrangements and affected successful collections for those already using them.

The gap also cost Wellfit business. Merchant interviews revealed demand for ACH, and Sales confirmed that prospective practices had walked away because it wasn’t available.

Business Objective

Introduce a lower cost payment rail to increase recurring payment enrollment, improve successful recurring collections, and support merchant acquisition. Build the capability needed to preserve ACH payment arrangements during the acquired customer migration.

Product Hypothesis

Offering ACH alongside cards would address merchant demand for a lower cost recurring payment option, reduce reliance on card credentials, and remove a capability gap affecting adoption and acquisition.

Discovery & Hypothesis Confirmation

• Merchant interviews: I investigated payment pain points and identified demand for ACH to support recurring collections.
• Sales interviews: I tested whether the missing capability affected acquisition. Sales confirmed that prospective merchants had declined to sign up because Wellfit did not offer ACH.
• Transaction analysis: I examined decline rates and their relationship to recurring payments. The data confirmed the problem, with expired cards and bad card details emerging as the leading decline reasons.
• Competitive analysis: I found that most competitors offered ACH, reinforcing its importance as a competitive capability.

These findings validated the need to prioritize ACH. They supported the investment decision; post launch measurement was needed to establish business impact.

Strategic Decision

Account updater and network tokenization could improve recurring card payment conversion, but they would not introduce the lower cost rail merchants were requesting or remove the ACH capability gap affecting acquisition. ACH addressed that broader business problem, while card optimization remained complementary.

Tradeoff: Validation Depth vs. Time to Market

I removed routing number lookup and bank name display from the initial release because acquiring and maintaining a routing number reference table added cost and effort that outweighed the expected benefit.

For staff assisted payments, banking details came from customer provided checks or phone calls, so we expected few routing number errors. After reviewing the implications with impacted stakeholders, we agreed to retain checksum validation and remove the lookup requirement to accelerate delivery.

My Role & Cross Functional Leadership

I served as the product and platform lead, coordinating the payments team and every product and operational team affected by ACH. I created a cross functional delivery plan, aligned dependencies, and worked through decisions as issues arose. The team delivered the core capability in 12 months against an original estimate of approximately 18 months.

Phase 1: Staff Assisted ACH Payments

The first phase brought ACH to market through staff assisted channels to support recurring payment adoption and merchant acquisition.

High Level Scope

• ACH merchant onboarding.
• Reusable, embeddable staff assisted payment experiences.
• Payment APIs, processor integration, and transaction status tracking.
• Bank account validation, fraud controls, and a centralized ACH token vault.
• NACHA compliance workflows.
• ACH refunds.
• ACH return monitoring and management.
• Notifications of Change management.
• Clearing, settlement, and merchant funding.
• Reconciliation and operational exception handling.
• ACH reporting for merchants and internal accounting.

Phase 2: Self Service ACH & Payment Risk Exploration

The second phase focused on extending ACH to self service payment experiences.

I also worked on a Plaid integration that had reached testing, alongside experimental work exploring ACH return risk estimates to inform when alternative payment methods could be offered.

Building for Scale

The ACH token vault established a foundation for adding bank payment methods to Wellfit Wallet later. Reusable, embeddable screens and backend payment APIs supported expansion across payment workflows without rebuilding each experience independently.

Challenge: Translating NACHA Requirements into Delivery

The internal Compliance team had deep PCI experience but less experience with NACHA requirements. Drawing on my previous ACH platform experience, I partnered with Compliance to identify the applicable authorization, disclosure, data retention, and return management requirements and translate them into product workflows.

I also enrolled in the Accredited ACH Professional program to deepen my knowledge and better support the team.

Challenge: Aligning Teams Without Payments Specialization

The Product Managers responsible for front end experiences were not payments specialists. I translated payment requirements into the customer and merchant workflows they needed to build.

I worked with them on one time and recurring payment prototypes and defined how merchants would view and manage their ACH transactions, settlements, refunds, returns and NOC's, walking teams through the complete lifecycle made the requirements more tangible than documentation alone.

Challenge: Managing Returns After Merchant Funding

An ACH return could arrive after a merchant had already been funded, creating a need to recover funds and make the operating account whole.

I worked with Accounting, Compliance, Operations, and Technology to define funding, reconciliation, and exception management processes, including the handling of unauthorized returns.

Lessons Learned

Specialist ACH expertise matters. ACH is a long established payment rail, but implementing it from the ground up is complex. Successful delivery calls for hands on implementation experience and a deep understanding of NACHA requirements, processor specifications, and the operational processes supporting the full transaction lifecycle.

Prioritization includes ongoing costs. The routing number decision required evaluating incremental customer value against implementation effort, data costs, and maintenance.

Payment intelligence creates opportunities for further improvement. Return risk insights and bank account data can inform experiments around payment methods and collection strategies.

Documentation works best alongside shared understanding. Requirements walkthroughs, lifecycle explanations, and prototypes helped teams understand what they were building and how their work connected to the overall payment experience.