Techivies
On this page

Payment Integration

We build the payment plumbing inside software products: ACH origination and returns, batch processing, reconciliation between gateway, bank and ledger, and the ledger itself. Built for teams whose product moves money but whose business is not payments.

The gateway, the bank statement and the ledger each report a different number, and the difference is somebody’s job to explain.

Money moves in three places at once

A product that collects payments has three records of every dollar: what the gateway or ACH processor says happened, what the bank shows, and what the application wrote to its own ledger. They are updated at different times, by different systems, with fees, returns and partial settlements in between.

When the product was small, one person reconciled it in a spreadsheet. When it grew, the spreadsheet became the risk. We build the pieces that make the three records agree by design: correct ACH handling, batch jobs that can be re-run safely, a ledger that cannot be edited into agreement, and reconciliation that flags what is genuinely wrong.

  • Returns found weeks later

  • Batches that cannot be re-run

  • Ledgers edited by hand

  • Fees hidden in deposits

  • Forced-to-balance entries

Bank payments (ACH)

We build the software that creates the ACH files your bank expects (NACHA format), with the right authorisation type for each debit (PPD, CCD, WEB or TEL), and reads the return and correction files the bank sends back.

Returns are handled by rules, not by hand: insufficient funds (R01, R09) retries or notifies the customer by your policy, account problems (R02, R03, R04) stop future debits, and unauthorised returns (R10, R11) go to dispute and are never retried. Bank cut-off times and same-day windows are built in, so a debit submitted at 4:55 pm behaves the way the bank will actually treat it.

  • NACHA file generation

  • Returns and corrections read

  • Same-day windows

  • Account verification

  • Authorisation records

Batches that can be re-run

Payment batches fail in the middle. A job that processes 40,000 debits has to be restartable from record 23,117 without double-submitting the first 23,116, and has to be provably complete before the file goes to the bank.

We build batch jobs as steps with checkpoints: assemble, validate, submit, confirm, post. Every record carries its status and history, every step can be re-run without side effects, and the exact file that went to the bank is kept with the bank’s acknowledgement.

  • Safe to re-run

  • Pre-submission validation

  • Bank cut-off times

  • Bank files kept unchanged

  • Batch dashboards

Making the numbers agree

Reconciliation is a three-way match between the processor’s settlement report, the bank statement and the ledger. The matching has to understand that a gateway payout has fees, refunds and chargebacks already taken out, that ACH money arrives one or two days later, and that a single deposit can cover several batches.

We build matching rules for the normal cases so they stop being exceptions, and an exception queue for the rest, with the evidence attached. The output is a daily reconciliation that someone can sign, not a spreadsheet someone has to build.

  • Processor reports read in

  • Bank statements read in

  • Fee and timing rules

  • Exception queue

  • Daily reports

A ledger you can trust

A payments ledger is double-entry, never edited after the fact, and boring, which is the point. Every movement is a balanced set of entries; nothing is updated in place; corrections are reversals with a reason. Balances are derived, not stored as the truth, so any balance can be rebuilt from its entries.

We design the accounts (customer balances, receivables, clearing, fees, reserves), the posting rules that turn a business event into entries, and the reporting on top. Where a ledger already exists, we audit it and fix the parts that make reconciliation impossible.

  • Double-entry, never edited

  • Reversals not edits

  • Clearing accounts

  • Balances rebuilt from entries

  • Audit trail

Card payments through your gateway

Card and wallet payments go through a gateway, and the integration is more than the checkout call: webhooks, retries, saved payment methods, refunds, chargebacks and payout reports all have to reach the ledger.

Card data stays with the gateway. Your systems hold a token that stands in for the card, never the card number itself, which keeps your PCI obligations small and keeps auditors calm.

  • Checkout without storing cards

  • Webhook handling

  • Refunds and chargebacks

  • Payout reports read in

  • Smaller PCI scope

What is different afterwards

Every return code has an action, and the ledger, the customer and your team hear about it the same day.

A failure at record 23,117 is a restart, not an incident.

Daily three-way match with exceptions and evidence, instead of a month-end spreadsheet.

How a project runs

Every way money enters, moves and leaves your product, with the systems and timing involved. Output: one diagram everyone agrees is true.

Accounts and posting rules written as a spec and reviewed by your finance lead before any code.

Processor and gateway sandboxes, synthetic bank files, and a test suite covering returns, partials, duplicates and failures mid-batch.

The new reconciliation runs against real data alongside your current process for at least one full cycle.

Traffic is moved by payment type or by customer cohort, never all at once.

Dashboards, alerts and a runbook; your team runs it, we stay on call if you want us to.

Questions we get on the first call

Either works and the design differs. Going direct means you generate the ACH files under your own bank agreement and own the returns handling; a processor API hides the file format but you still own the ledger and reconciliation. We build both and will tell you which fits your volume and risk appetite.

We keep card data out of your systems: the gateway stores the card and gives you a token, card entry happens in the gateway’s own fields, and no card numbers end up in logs or databases. That keeps your PCI scope to the smallest questionnaire the gateway allows.

The ledger reverses the receipt with the return code as the reason, the customer balance goes negative, and the action for that code runs: retry for funds-related returns if your policy allows, stop and dispute for unauthorised returns. Your collections flow is triggered from the same event.

In a queue with the three records side by side and the evidence attached, with alerts on age and amount thresholds. Nothing is auto-resolved by writing a plug entry.

Yes. We start with an audit: whether entries balance, whether history can be reconstructed, where in-place updates happen. Often the ledger stays and the posting rules and reconciliation are what change.

Node.js or Python services on AWS (ECS Fargate, RDS PostgreSQL, SQS) in your own account, with infrastructure as code handed over. Other stacks on request.

Four ways to
work with us

ecommerce shipping solutions

A defined project

A defined integration or product, priced and scheduled up front, delivered with the test suite and infrastructure code you keep.

small_medium_img

Engineers on your team

Engineers who join your team, your code and your daily meetings for as long as the roadmap needs them.

enterprise_img

Ongoing support

We keep the integrations you run working: monitoring, vendor updates, new connections and month-end support.

agencies_img

Taking over existing systems

A system or integration nobody wants to touch: we review it, make it stable, then build on it.

What clients say

Tell us which systems
you run.label_leaf

An engineer replies within one business day, with questions rather than a pitch.

you_ready
select_arrow
you_ready