How we built the world’s first payment automation engine

There was a time when payments were incredibly rigid. 

Payment teams had strategies. Big ideas. But they were stuck without engineering. Payments were locked behind code. Most merchants couldn’t route at all, and there was no easy way to test, no way to optimize. Even a ‘simple’ change, like updating 3DS logic, meant logging a dev ticket and waiting for the next sprint. And adding a new processor? That was a full-blown project. Months of work.

Primer changed that with Workflows.

We launched the world's first visual workflow editor for payments. This innovation allowed teams to build, test, and deploy complex payment flows without writing code or involving engineers.

But this wasn’t just about removing engineering bottlenecks. It was about clarity and control.

There’s a saying in programming: “Code is read more than it is written.” We believed the same applied to payments. It’s not just about creating logic, it’s about being able to see, understand, and evolve it over time.

From day one, Workflows were designed to be easy to understand at a glance, with no ambiguity or guesswork. While most visual tools at the time let you drag things around an endless canvas, we took a different path, handling the layout automatically, so users can focus on building their logic. 

It was a foundational shift in an industry that had always been buried in backnd code. For the first time, payment managers, product owners, and ops leads could take direct ownership of their payment strategy.

It made payments adaptable, transparent, and ownable and set a new standard for the industry.

Success, with a caveat

Now, it would be great to say job done, close our laptops, and celebrate how we changed the industry. But that’s not how we work at Primer. Challenging the status quo is part of our culture. We’re always looking for what’s next, because payments don’t stand still, and neither do we.

Workflows struck a chord. Merchant adoption was quick, and usage grew fast. We had validation, but real-world usage revealed real-world cracks.

The first iteration of Workflows had architectural limits. For example, each payment method was tied to a single flow. If you wanted to treat Apple Pay and Google Pay differently or adapt logic for different markets, you had to duplicate entire flows. That meant recreating them from scratch, which was time-consuming and error-prone.

Another issue was that Workflows were tightly scoped for payments. You could only orchestrate what lived inside Primer’s core payment flow. Transactions, 3DS, routing. That was it. You couldn’t connect Workflows to upstream systems or automate logic beyond payments.

That was fine at the time. But not for where we were going. We needed something to support the entire payment lifecycle and deliver on Primer’s vision of creating a Unified Payments Infrastructure. Every business has a different payment strategy, so we needed to support them all. That includes use cases like triggering internal fraud checks before authorization, sending confirmation emails on capture, A/B testing providers, and decoupling authentication from authorization to give more flexibility on what happens during the checkout flow versus afterwards

It was time for a complete overhaul of our Workflows into a fully scoped payment automation platform. 

Rethinking Workflows from first principles

When we started rebuilding Workflows, we weren’t fixing what didn’t work; we were rethinking it entirely.

We wanted to keep what worked—visual clarity, low-code flexibility, instant deployment—but we also wanted something more powerful to handle complexity without losing simplicity.

For casual users, it had to feel effortless. A payment manager should be able to jump in, tweak a flow, and move on. For power users, it needed depth, a place to model logic, experiment, and build complex flows with confidence.

That balance, simple on the surface yet powerful underneath, is what makes our workflows unique.

To achieve this, we built a domain-specific language that models business logic without code. And to get it right, we had to answer some hard questions.

• How much freedom should we give users?
• Should we block invalid flows at build time, or let them run and flag issues later?
• Should we optimize for safety or speed? Guardrails, or creativity?

Every constraint would make flows easier to reason about, but risked slowing people down. Every layer of flexibility unlocked richer logic, but came with more risk.

These tensions shaped our approach. We settled on a clear direction: Remove the guardrails and give merchants full control and flexibility to build workflows, while ensuring they have clear, granular visibility into each step, so it’s easy to see what happened when things didn’t go as expected.

At Primer, we don’t believe in black-box systems. Workflows had to reflect that too. And that principle shaped one of the most critical features: Workflow run history.

Every time a workflow runs, it leaves a complete, readable trace where you can see:

• The path it took through the flow.
• How long each step took.
• The data that passed in and out.
• The conditions evaluated, and the decisions made.

‍

That visibility gives merchants something they’ve never had before: the power to understand every payment route at any given time and the confidence to build complex logic without fear of breaking things they can’t see.

Building for commerce, not just payments

The next decision we made was not hardwiring Workflows to payments. In fact, it doesn’t even “know” what a payment is.

In the first iteration of Workflows, every trigger was related to a payment event. The next version of workflows supports any number of triggers. Payment creation is one option, but it could be a refund, a subscription update, or an external webhook.

That flexibility is foundational. It unlocks more use cases today and sets the stage for Primer to orchestrate across the entire commerce stack tomorrow.

To make this concept real, the system is built around four primitives: triggers, actions, apps, and outputs. It models logic, not just payment flows, without assuming what kind of problem you’re solving.

That neutrality is a big leap. But it’s what makes a general-purpose automation platform.

With greater flexibility came new design challenges. In the first Workflows, every block had fixed outcomes: success, failure, and decline. These outcomes were hard-coded into the canvas, making things easy to read but also rigid.

We took a different approach for the new Workflows engine. We removed defaults, and merchants now define outcomes themselves using condition blocks. It’s more complex under the hood, but far more expressive. Want to cancel a payment only if it’s a “first payment” to support vaulting flows? Or route payments based on the card issuer’s country? All of that is now possible.

Engineering for complexity and scale

The new Workflows were designed to serve the most complex businesses in the world.

It has to scale across teams, markets, use cases, and transaction volumes. From global subscription platforms to multi-market retailers, merchants built increasingly sophisticated flows, expecting them to run without friction.

Early on, we hit limits. Concurrency was a bottleneck. A few workflows running in parallel could cause slowdowns. Some merchants hit issues after launching just five or six active flows, and we quickly learned that merchants would create many more than just a handful.

To solve for this, we’ve worked hard on optimizing performance, including:

• Simplified some of our technical architecture to reduce dependencies.
• Improved caching.
• Tuned the execution model to handle higher throughput.
• On the front end, we reworked state propagation, introduced schema caching, and optimized the editor to stay fast, even for sprawling, branching flows.

‍

As usage ramped up, we tracked every run and analyzed every failed workflow, not just to fix bugs but to ask: Was it a platform fault, or was there a misconfiguration? And if the latter, how could we make it easier for the user to get it right next time?

That loop helped us tighten validation, refine UI patterns, and smooth edge cases across the board. 

The result?

Performance has been stable across hundreds of millions of workflow runs. Even under real-world complexity, where merchants are building flows comprising hundreds of blocks, the new generation of Workflows has held up. It’s fast, predictable, and reliable.

Built for what comes next

Our automation platform represents more than a rebuilt product; it marks a shift in how payments and business logic are designed, owned, and operated. 

It’s stable at scale, flexible by design, and built to handle the complexity we know merchants face every day. And while it already supports millions of runs, its real strength lies in the architecture: domain-agnostic, deeply extensible, and ready to grow with how merchants use it.

Orchestration shouldn’t stop at payments. As businesses look to automate more of their operations, the same logic engine can be extended to support them all.

We’re setting a new standard for the industry, and it’s only the beginning of what we’re building.

Want to learn more about how we're building Primer? Take a look at how we rebuilt our processing engine from the ground up.