← WritingCode

Moving OnTrac to Dejavoo in the middle of the BridgePay outage

When a ransomware attack took BridgePay offline, the thrift stores using OnTrac couldn't take cards. Here's how I moved them to Dejavoo, our third processor.

5 min read

The three card terminals OnTrac has used, from above, oldest on the left. The Heartland terminal has a tangle of cables, the BridgePay one a single cable, and the Dejavoo one none.

OnTrac is the iPad point of sale I built for KARM Thrift Stores, and it's part of ThriftTrac, the software platform KARM also sells to other thrift stores. Taken as a whole, that platform helps hundreds of thrift stores take millions of dollars in electronic payments, so when card payments stop working, it matters to a lot of people very quickly.

Over the years OnTrac has worked with three card processors, one after another: Heartland, then BridgePay, and now Dejavoo. This is the story of the third one, which I happened to be building when the second one went down.

A timeline of OnTrac's card payments: Heartland in late 2018, BridgePay in August 2022, the BridgePay outage on February 6, 2026, and Dejavoo in February 2026, rolled out to all of KARM first and then every other organization

The day BridgePay went down

On February 6, 2026, a ransomware attack took BridgePay's payment gateway offline across the US. BridgePay brought in the FBI and the US Secret Service, and said that no card data had been compromised, but the gateway stayed down for days, and it made the news.

My client called me when it happened. Most of the organizations using the software had switched from Heartland to BridgePay in recent years, so they were completely unable to take any electronic payments at all. It was an ongoing outage with no end date in sight, and at the beginning all we really knew was that we were missing sales.

Stores did what they could. Some locations across the country had Heartland systems they were able to turn back on and use, and some stores were using Stripe and Square readers and doing manual reconciliation at the end of the night. It worked, but it was a mess.

Why Dejavoo was already on the list

The timing was lucky in one way. We had already identified Dejavoo as a more premium, fully integrated partner for payments, and I'd started on the integration at the end of January, about a week before the outage.

With BridgePay, OnTrac used PAX card terminals. The hardware is very generic, engineered to work in essentially any industry that would ever want to take card payments, and so it has hundreds and hundreds of options and is very hard to configure properly. Dejavoo makes both the terminal and the software behind it, and being a single hardware and software provider makes it so much easier to configure terminals, ship them to stores and have them work consistently.

So we knew we wanted to move to Dejavoo for a better experience anyway. It just so happened that I'd already made progress on it by the time BridgePay went down, and it went straight to the top of the list.

Our easiest integration yet

Honestly, this was the easiest payment integration I've done. Dejavoo has great developer tooling and APIs, and it's a cloud API, so there's no local connection between the iPad and the terminal at all.

That's a long way from where OnTrac started. The Heartland integration meant working with a very legacy, unmaintained SDK, and I wrote about how painful that was in what we learned integrating Heartland Payments, three months later.

The other reason it went quickly goes back to 2022. When I added BridgePay, I had to do a significant refactor of the iPad app and some of the backend APIs to support the idea of more than one payment gateway, and how each one is configured. The iPad app behaves quite differently depending on which gateway a store is set up to use, so that groundwork mattered. Adding a third gateway was easier because of it, and it validated that I'd designed that architecture correctly the first time. It helps to plan properly and solve code problems the right way the first time, and this was one of those moments where it paid off.

Three terminals on my desk

I still have one of each terminal, and putting them side by side shows how much has changed since Heartland. The card terminals themselves have gotten a lot more streamlined.

Three card terminals on a desk, oldest on the left: the terminal used with Heartland with its tangle of cables and adapters, the terminal used with BridgePay with a single cable, and the Dejavoo terminal with no cable at all

The one on the left, from the Heartland days, has tons of wires and adapters. It had to be hardwired, with a direct connection over the store's local network to an IP address, and talking to it meant an Objective-C SDK with custom networking protocols. It was just so much more of a pain all those years ago.

The BridgePay terminal in the middle still had a single wire, although I believe it was on Wi-Fi. The Dejavoo terminal on the right has a battery and works for quite a while fully disconnected, on Wi-Fi. It's very portable, and it's the easiest of the three to configure.

Rolling it out under pressure

We started with a single KARM Thrift Store location, but because of the ongoing outage, we enabled it for all of KARM's stores much faster than we normally would have. KARM does a lot of sales volume, so that quickly validated that the integration worked well, and we onboarded all of the other thrift store chains and their locations across the country shortly after.

The main problem wasn't the software at all. It was getting enough Dejavoo card terminals quickly enough. Sourcing them as fast as possible, getting them in, configured, and shipped back out to stores overnight was a major effort.

Why I'm sharing it

This isn't meant to be a technical deep dive. Payment processors, card terminals and the integrations between them are a fairly technical subject, but what I really want to show is the work: that I'm capable of doing complicated integrations across hardware and software vendors, and of rolling them out to stores across the country when the timeline isn't up to me.

Matt

I've been building software since 2008, and I started Lotus in 2015. Now I'm making my own apps, starting with Bobara, and I still take the occasional client project.