Payment routing, priority logics, fraud screening, 3DS authentication, loyalty rewards and more. Multiple products and multiple pages, one promise: build the logic yourself, without an engineer. That promise is the product. It's why merchants like Amazon, IndiGo and Swiggy don't need a deployment to change how payments route on a Friday afternoon. The rule builder is where the promise is kept or broken.

IF / ELSE IF / ELSE maps one-to-one onto how the engine actually evaluates a rule. It's cheap to build, it's what every rule builder ships, and three of the four modules already had it. There was no argument for starting anywhere else. It's also engineer grammar, handed to an operations persona who has never written a conditional in their life. That mismatch didn't show up as complaints. It showed up as merchants quietly not using the feature.

If the problem is that structure can't be seen, put it on a canvas. Sequence becomes spatial. Branching becomes a fork you can point at. Outcomes become objects rather than text at the end of a line. Much of it worked. The single biggest comprehension win came from something small: labelling the entry node “Every payment that comes in” did more for understanding than any amount of relabelling IF/ELSE ever did.

Both previous attempts asked the same question: what is the best way for a merchant to express formal logic? Node builder asked whether they should be expressing it at all. Merchants don't think in conditions. They think in intent - route premium customers to Stripe on weekends. So the system authors from intent, and the merchant's job becomes verification.

The three generations look like a sequence of replacements. They aren't. All three still ship, and which one you land in is determined by where you came from - the route carries the context, and the context picks the surface.