How Checkout.com empowers internal teams to self-serve merchant data and operate at scale

Checkout.com's growth is tied to the success of its merchants. Internal teams like support and success rely on merchant data as part of almost every workflow to service customers.

This merchant data—everything from merchant balances to payment authorization rates—had historically been manually pulled by engineers, but rapid growth meant the team was constantly inundated with other requests.

Sam Williams, a Senior Software Engineer at Checkout.com, experienced this problem firsthand with merchant balance requests. Support teams would request merchant data for day-to-day operations. The product teams would request the data to inform important proof of concept work that could decrease failed payment rates and open up new lines of revenues for merchants while expanding Checkout.com’s product line.

The typical flow for Sam and his team looked like this:

1. Internal stakeholder opens ticket to request merchant balances

2. Tickets sit in queue until an engineer becomes available

3. Assigned engineer makes API call, or searches in database for balances

4. Requested balances are included in the ticket, and the ticket is closed

But by that point it was too late. The numbers changed, or other issues would come up. Sam and his team knew they needed to remove themselves as a bottleneck for non-technical teammates who requested merchant balances.

As Sam and his team searched for a way to self-serve merchant balance requests, one of the requirements included a simple user interface. This was key for non-technical users who desired minimal technical friction—ideally they could just paste an ID into a field and see the live balance immediately. 

Sam and his team asked around how they should go about building a user-friendly UI. Did a React component library already exist? Were there style guides tucked away inside internal documentation? The rabbit hole went deeper when considering other issues like security.  Sam could learn how to implement a functional UI with React, but he would still need to figure out how to secure and restrict data access.

When Sam and his team discovered Retool, it was a different story. Engineers wouldn’t have to build the UI from scratch. Security features like auditing, traceability, and restricting access would be abstracted away: “Retool just did this out of the box with our SSO provider. You just sign in and you can restrict a certain group of people, and away they go.”

It wasn’t long before stakeholders across the company had a tangible internal tool to test: “The initial mockup for this was done in 15-20 minutes, and the final product didn’t look all that different.” Automating this workflow meant that non-technical and technical teams always operated on equal footing with fresh and relevant merchant data. And engineering could spend less time spending precious cycles on manually solving tickets.

Alex Sullet, a Senior Data Scientist on the Payment Performance team, created a suite of apps with Retool to automate manual requests his team received from different teams across the company. He wrapped these apps into one universal hub: the Performance Hub.

Here was one destination where multiple internal teams could pull the specific type of merchant data they needed without opening a ticket:

• Customer Success teams had access to portfolio tracking to follow specific accounts, get a global overview of the portfolio, view authorizations, and acceptance rates.

• Product teams had access to deeper, more complex areas of payments, to fine tune their proof of concepts to improve failed payment rates and rapidly iterate.

There was a tight feedback loop embedded inside the app. Any of these internal teams could submit suggestions at the click of a button. Captured feedback would be forwarded to the Payments team in Slack, and create a Jira ticket automatically. 

Development took advantage of Retool’s UI component library to add the ability to filter subsets of data, and implement a common header bar. Alex notes: “In the end we wanted to get as close as possible to an experience that was familiar to end users.” 

Fresh off the heels of its $1B Series D round, Checkout.com continues to onboard new engineers at a rapid pace. What's kept engineering moving fast is a relentless focus on minimizing friction for new and mature teams:

In pursuit of this mission, Joe and the engineering org have come to embrace Retool's features like SSO via Open ID and employing user permissions to streamline authentication and user access. This low friction approach has helped keep administration and maintenance costs under control as the next wave of hires are onboarded.

With engineers unblocked, internal teams had access to better tooling, and merchants received better service. It's a cycle that's been at the core of Checkout.com's internal processes since 2020. In the space of 2 years (2020-2022), engineering rapidly built and deployed 54 internal apps on top of the Retool platform.

Internal teams across the organization–from product, customer success, and support–have been able to interact with these internal apps daily to streamline their workflows and brace for the next global release.