How a payment is tracked
Money arrives on different days, with fees taken out and some payments returned. Each step below keeps a record that can be matched to the others.
- You have
Payment provider and bank
Card payments, bank transfers and the reports they send.
- Step 1
Payment records
Each payment recorded against what it pays, with the provider’s reference.
- Step 2
Ledger
Every payment, fee and refund as its own entry, never edited.
- Step 3
Daily match
Provider, bank and ledger compared every day, with differences in a queue.
Payment integration services
Mistakes are corrected with new entries rather than edits, and nothing is forced to balance, so the history of any amount can always be read back.
Taking payments
- Bank payments (ACH)Payment files in the format your bank expects, and return files read back in.
- Returned paymentsEach return reason handled by your rules: retry, notify the customer, or stop.
- Card paymentsCheckout through your gateway, with card details kept by the gateway.
- Refunds and chargebacksRefunds, disputes and payouts recorded against the original payment.
Keeping the books right
- Payment runsRuns that can restart after a failure without paying anyone twice.
- ReconciliationProvider, bank and ledger matched daily, with fees and timing built in.
- LedgersDouble-entry ledgers where every change is a new entry.
- Help with mismatchesAn AI assistant suggests matches for unclear payments. A person approves each one.
Tools we work with
Built in your own cloud account, with the infrastructure code handed over.
Payment methods
- Bank transfers (ACH)
- Cards
- Wallets
Platform
- Node.js
- Python
- AWS
- PostgreSQL
- Amazon SQS
Questions we get on the first call
Have a question that is not here? Send it with the form below and an engineer will reply within one business day.
Do we need our own bank relationship for ACH?
Either way works, but the design differs. With your own bank agreement you create the payment files and handle returns yourself. With a payment processor’s API the file format is hidden, but you still own the ledger and reconciliation. We build both and will tell you which fits your volume and risk.
How do you handle card security (PCI)?
Card details never reach 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 checklist as short as your gateway allows.
What happens when a payment is returned after the service was delivered?
The payment is reversed in the ledger with the return reason, the customer balance goes negative, and the action for that reason runs: a retry if your policy allows it, or a stop and dispute if the payment was not authorised.
How do reconciliation problems reach us?
In a queue that shows the provider, bank and ledger records side by side with the evidence, with alerts by age and amount. Nothing is forced to balance with a made-up entry.
Can you work with a ledger we already have?
Yes. We start by checking whether entries balance, whether history can be rebuilt, and where records are edited in place. Often the ledger stays and only the posting rules and reconciliation change.
Which technology do you build this in?
Node.js or Python services on AWS, with PostgreSQL and message queues, in your own account, with the infrastructure code handed over.
See how this works in practice
Four ways to work with us
A defined project
A defined integration or product, priced and scheduled up front, delivered with the test suite and infrastructure code you keep.
Engineers on your team
Engineers who join your team, your code and your daily meetings for as long as the roadmap needs them.
Ongoing support
We keep the integrations you run working: monitoring, vendor updates, new connections and month-end support.
Taking over existing systems
A system or integration nobody wants to touch: we review it, make it stable, then build on it.
