For a long time, our payment setup did not feel broken. We had a processor, customers could pay, and there was no obvious reason to add another layer. Then the questions started getting harder. What happens if we want a second processor? Which one should receive a transaction first? How much would we have to change if our payment setup became more complicated next year? I did not add PaymentKit because the old setup suddenly stopped working. I added it because the old setup was becoming too dependent on one path.
The Setup Was Fine Until Our Requirements Changed
The original arrangement was easy to understand. One processor handled payments, and most decisions were built around that connection. Simplicity was an advantage at that stage. There were fewer moving parts to check. There was also less flexibility once I began thinking beyond a single processor.
That was the point where I started separating “working today” from “easy to change later.” They are not the same thing. A payment setup can process transactions perfectly well and still make the next change inconvenient. I did not want every new processor decision to turn into another checkout project. I wanted the payment logic to become less attached to one provider.
Before, Need, Decision
Before: one main payment path was enough, so there was little reason to introduce another layer. Everything was easier because there were fewer decisions.
Need: I wanted the option to work with multiple processors without rebuilding the payment flow around each one. I also wanted routing to become something we could define deliberately rather than handle as separate integrations.
Decision: I added Payment Kit between our payment flow and the processors. Its orchestration setup supports multiple processors and lets payments follow configured routes instead of relying only on a single default processor.
I Was Looking for Control, Not More Features
Once I stopped evaluating extensive feature lists, I found my requirements easier to articulate. With a focus on the following three principles: first, that it is always possible to add another processor; second, that there is a clear way to manage the movement of transactions between the different processors; and importantly, third, that the checkout process should not become inextricably linked to any one service. It is exactly the approach of PaymentKit’s orchestration that meets my criteria since it allows different processors to be installed behind a uniform payment interface.
Routing mattered more to me than I expected. PaymentKit allows processor routes to contain an ordered list of processors. When a payment uses that route, the processors can be attempted in sequence until one succeeds. If a processor is unavailable or cannot handle the currency, the documented routing behavior can move to the next one. Routes currently require at least two connected processors and are defined through the API.
I also liked that I did not have to treat multi processor payments as the starting point. PaymentKit’s documentation says an account can begin with one processor and add others as requirements grow. That suited the way I was thinking about the change. I was not trying to make payments more complicated immediately. I was trying to avoid painting the setup into a corner.
Adding Another Layer Had to Solve a Real Problem
I was cautious about adding another system because extra layers can create extra work. If all PaymentKit did was put another dashboard between me and the processor, I would not have had a convincing reason to use it. The useful part was moving processor choice and routing into a separate part of the payment architecture. PaymentKit describes its orchestration layer as a way to connect multiple processors and control how payments are routed between them.
That changed the role I expected it to play. I was not replacing processors. I was creating some distance between the customer facing payment flow and the processors sitting behind it. The distinction matters because those processors may change over time. My goal was to make that change less disruptive when it eventually happened.
There was also a practical limit to what I expected on day one. I did not need sophisticated routing rules immediately. I needed the structure to support them when the business case appeared. Starting with that expectation kept the decision fairly grounded.
What I Wanted From the Decision Long Term
The first thing I wanted was optionality. If we decide to connect another processor, I do not want that decision to begin with the question of whether the entire checkout needs to be redesigned. PaymentKit supports multiple processor connections within its orchestration model, which is the part that mattered for this goal.
I also wanted failures to become a routing question rather than automatically becoming a dead end. PaymentKit documents processor routes where another processor can be attempted when the earlier one cannot complete the transaction under supported conditions. That does not mean every decline suddenly disappears. It means the setup has somewhere else to go when the routing conditions allow it.
The more interesting benefit for me was organizational. Adding PaymentKit forced me to separate the payment experience from the processor underneath it. Before, those two ideas felt almost interchangeable because one processor handled everything. Once there can be several processors, that mental model stops working.
That is ultimately why I added PaymentKit this year. The old setup was not failing badly enough to demand an emergency replacement. It had become too rigid for the direction I wanted the payment setup to take. I was solving for the next change rather than the last problem. In payments, that turned out to be a more useful reason to change the architecture.