CASE STUDY
Rebuilding Payment Infrastructure for a Field Service SaaS
How TechGrit built an automated fee recovery engine that eliminated processing cost absorption across multiple payment providers, with ZERO disruption to existing payment flows.
7 MAY, 2026
Client Summary
Credit card processing fees are a significant and growing cost for field service companies. Merchants using the platform were absorbing these fees silently, paying 2–3% per transaction with no mechanism to recover or even quantify what they were losing. As the platform scaled across thousands of companies and payment volumes grew, the business impact of this gap became impossible to ignore.
​
The core problem was threefold:
​
-
The platform integrated with three payment providers (Rainforest, FullStack, CardConnect), each with distinct API behaviours, webhook formats, and response structures- meaning any fee recovery solution needed to work seamlessly across all three without fragile, one-off implementations.
-
Invoice calculations involved tax coefficients, fixed discounts, and prorated line items, creating a mathematically complex environment where fee adjustments could easily break existing totals.
-
The feature needed to be entirely opt-in: enabled per company, invisible to merchants who hadn't activated it, and non-disruptive to thousands of live payment flows already in production.
Merchants were absorbing credit card processing costs with no visibility into the impact — and no way to recover them. The platform needed a solution that was invisible to existing flows and automatic for those who opted in.
Project Snapshot
Project | Card Fee Recovery (CFR) System |
Platform | Laravel, Modular Architecture |
Scope | Multi-provider fee automation, reporting pipeline, refund handling |
Payment Providers | Rainforest, FullStack, CardConnect |
Deliverable Type | Feature implementation across 80+ module codebase |
Outcome | Fully automated CFR with monthly merchant savings reporting |
TechGrit's Approach
TechGrit designed and implemented a complete Card Fee Recovery system within the platform's existing modular Laravel architecture — touching payment processing, invoice management, observer automation, and a reporting pipeline. The solution was built to be provider-agnostic, mathematically precise, and entirely automated.
​
-
Provider-Agnostic Fee Calculation
Rather than implementing fee logic separately inside each payment provider, TechGrit integrated CFR into the platform's shared Payment contract — the interface all providers implement. This meant fee calculation logic was added once and activated across Rainforest, FullStack, and CardConnect through their existing abstraction layer, with provider-specific adjustments handled at the edge rather than the core. ​
-
Precise Invoice Adjustment Logic
CFR fee amounts are applied as prorated line item adjustments on invoices. The calculation accounts for tax coefficients, fixed discounts, and partial payments — maintaining accuracy to fractional cents. To avoid rounding errors, invoices store both a standard total field and a total_precise field, ensuring the displayed amount and the processed amount remain aligned regardless of the fee configuration.
-
Observer-Driven Automation
Fee recovery logic runs automatically via PaymentObserver and RefundObserver — event listeners that fire after payment model events. This keeps controllers lean and ensures CFR logic fires consistently whether a payment is initiated from the web app, an API call, or a recurring billing job. Refund processing mirrors the same pattern: when a refund is issued, the corresponding fee recovery adjustment is reversed automatically.
-
Monthly Reporting Pipeline
A scheduled reporting system generates two distinct monthly report types for each company:-
Merchant Savings Report — for companies with CFR enabled, showing the actual fees recovered that month with a running total.
-
Projected Savings Report — for companies without CFR enabled, illustrating the dollar amount they could have recovered based on their payment volume. This report serves as a conversion tool, giving the sales team a data-backed case for activation.
-
Key Engineering Decisions
-
Observer pattern for CFR logic — keeps controllers focused and ensures consistent execution across all payment triggers
-
total_precise field on invoices — prevents fractional cent rounding errors introduced by fee calculation
-
Company-level feature toggle — CFR is opt-in per company, making the feature invisible to non-participants
-
Dual report types — one for active users (savings realised), one for inactive users (savings foregone), serving both operational and sales purposes
-
Chunked report generation — large datasets are processed using chunkById() to prevent memory exhaustion
Results & Business Impact
​For Merchants
-
Processing fees that were previously absorbed silently are now recovered automatically — no manual intervention required.
-
Fee recovery activates instantly upon company-level opt-in, with no changes to how invoices are created or how customers pay.
-
Monthly savings reports give merchants transparent, quantified evidence of the feature's value.
For the Platform
-
A single CFR implementation works across all three payment providers, reducing maintenance overhead and future-proofing the feature for new provider additions.
-
The observer-driven architecture means CFR logic fires consistently across every payment trigger — API, web app, recurring billing — without duplication.
-
Projected Savings Reports give the sales and success teams a concrete, data-driven tool for driving CFR adoption among inactive companies.
-
The CFR flag on every payment record creates a clean audit trail for compliance and dispute resolution.
​
The projected savings report turned a passive feature into an active sales tool — giving the team real numbers to show merchants what they were leaving on the table every month
​Several technical decisions made during this implementation have broader applicability for payment feature development:
-
Observer pattern is the right home for cross-cutting payment logic. Moving CFR calculations kept the codebase clean and ensured consistent execution regardless of how a payment was triggered.
-
Precision fields matter in financial calculations. A small addition invoice records was a small change that prevented a class of rounding bugs that would have been very difficult to debug in production.
-
Complex invoice adjustment logic requires manual verification. AI tooling was useful for navigation and documentation, but the payment method adjustments — involving tax coefficients, fixed discounts, and prorated multipliers — required human mathematical verification to get right.
-
Dual report types serve different audiences. Designing reports for both active and inactive user segments from the start meant the feature delivered value immediately — both as a savings tool and as a sales asset.
-
Chunked processing is non-negotiable at scale.
Lessons Learned
About TechGrit
TechGrit is a technology engineering firm specialising in building and scaling backend systems, payment infrastructure, and modular platform architecture for B2B software companies. We work as a deeply integrated engineering partner — embedded in your codebase, aligned with your team, and accountable for outcomes.
​