Datics AI
← All work

Government payments software company

Sheriffs and courts take fines online and at the counter on one portal

We built one payment portal that each sheriff's office, court and town runs under its own domain, letterhead and fee rules. Then we moved every live portal onto one new code base, verified each in production, and handed launches to the client's team.

Government, Legal & DefenseFines and fees payment portalsModernized a live product

The public payment portal finds a case by number and lets the payer pay it online.

The challenge

Agencies took fines at the counter in cash or check. Each needed its own branded site for card and bank payments, plus card swipers at the front desk.

What we did

We built one portal configured per agency, ran the convenience fee as its own gateway transaction, and later moved every live portal to a single second version.

The outcome

Agencies take card and bank payments online and at the desk under their own brand, and the client's own engineers now launch and run portals from our guide.

Customers
Sheriffs' offices, courts, towns and a private business
Payments
Card and bank online, swipers at the front desk
Per agency
Domain, letterhead, fee rates, gateway processors
Handover
Client's team launches new portals itself

The starting point

A government payments software company sells online fines and fees payment portals to sheriffs' offices, courts and towns. Defendants and citizens pay fines, court costs and fees online, and front desk staff take card payments in person.

What had to change

Agencies took payments at the counter in cash or check. Each one needed its own branded site for card and bank payments, a swiper at the desk, a correctly routed convenience fee and a receipt on its own letterhead.

What could not break

  • Every live portal keeps taking real payments through each fix and the migration
  • Each agency keeps its own domain, letterhead, disclaimers and convenience fee rates
  • Fee legs and second transaction ids must match the gateway's records
  • Front desk swipers keep working after every redeployment
  • Card data stays tokenized by the gateway, never stored by the portal

The calls we made

We treated each new agency as configuration of one product, and every change as something to prove in production, portal by portal.

  1. 01

    Each agency is configuration

    Domain, SSL, letterhead, disclaimers, fee rates and gateway processors are set per agency on one reusable frontend and backend, so a new agency is a setup, not a build.

    Ruled out

    A separate copy of the code for each agency, where every fix would have to be made again.

  2. 02

    The fee as its own transaction

    The convenience fee runs as a separate leg on its own processor so each agency's books match the gateway records, with a single leg option for the one customer that needed it.

    Ruled out

    Folding the fee into the main charge, which would not match the gateway records.

  3. 03

    Migrate live portals one by one

    Each first version portal moved to the second version as its own task, then we studied the swiper flow, fixed what broke and verified the portal in production again.

    Ruled out

    Switching every portal at once while agencies were taking payments.

  4. 04

    Hand launches to the client

    When the client said it had many portals to build, we wrote a deployment guide for both repositories, then reviewed its engineers' changes and ran a knowledge transfer on launching new portals.

    Ruled out

    Keeping every new launch dependent on us.

How the system fits together

pays a fineswipes a cardbrand and fee rulestokenized card datapayment resultfee legstoresemailed receiptpaymentsDefendants andcitizensLook up a case and payonlineFront desk staffCard swiper at the counterAgency payment portalReact, one domain and SSLper agencyAgency configurationLetterhead, disclaimers,fee rates, processorsPortal backendDjango API, receipts,tracking endpointPayment recordsPostgreSQLNMI payment gatewayCard, ACH and conveniencefee legsCase managementproductThe client's own, linkedlater
PeopleBuilt by DaticsData storeOutside serviceClient's existing systemEvery agency runs the same portal and backend with its own configuration, and card data goes to the gateway as a token.

What we built

01

Public payment portal

Case or citation lookup, card and bank payments through the gateway with tokenized card data, receipts on the agency's letterhead and email receipts.

02

Front desk payments

Card swiper payments for counter staff, studied and fixed office by office until no payment hung in progress, then checked again after every redeployment.

03

Second version code base

One code base that replaced every first version portal, with per agency disclaimers and footers, rounding that matches the gateway and an authenticated tracking endpoint.

How it works

Set up

A new agency gets its domain, SSL, letterhead and fee rates as configuration.

Look up

A citizen finds the case or citation to pay.

Pay

Payment runs by card, bank transfer or the front desk swiper, with the fee as a separate leg.

Receipt

A receipt prints on the agency's letterhead and goes out by email.

What changed

Agencies moved from counter only cash and check to online and front desk card payments under their own brand. All live portals run on one code base, and the client's own engineers launch and run new portals.

Under the hood

Datics role
Built with a partner agency
Payments
NMI gateway with per agency processors for card, bank and convenience fee legs, card data tokenized by the gateway.
Deployment
Each portal deployed with its own domain and SSL, frontends on AWS S3 and backends on DigitalOcean.
Integrations
Front desk card swipers, an authenticated tracking endpoint, and later a link to the client's fines and fees case management product.

Data and retrieval

PostgreSQL

Cloud and infrastructure

AWS S3

Apps and APIs

ReactDjangoPython

Also in the stack

NMI gatewayDigitalOcean

How it shipped

  1. First portals live

    We launched the first agency portals and set up each backend with its own domain and SSL, then added card gateways and swiper support.

  2. More agencies as configuration

    New sheriffs' offices, courts and towns came on as configured instances with bank payments, swipers and letterhead receipts.

  3. One second version

    We moved every first version portal to the new code base, fixed swiper and receipt issues after each move and verified each portal live.

  4. Handover

    A deployment guide for both repositories, two more sheriff portals, then reviews of the client engineers' changes and a knowledge transfer so they could run the portals without us.

Through a partner agency, then direct

The work began through a partner agency for its client, and we kept building and supporting the portals as the client's needs grew.

Verified in production

Every migration and fix was redeployed and checked in each live portal, including swiper flows, receipts and second transaction ids.

Documented and handed over

The deployment guide covered both repositories. We then reviewed and merged the client's own engineers' changes and ran a knowledge transfer on launching new portals.

What this unlocked

With every portal on one code base and launches in the client's hands, we went on to scope the client's fines and fees case management product with them.

Related work

Have a product with the same kind of constraints?

Tell us what already exists and what you want it to do. We will tell you what it takes.

Book a 30-minute Product Review