Execution is solved. What gets executed is still decided by a rule someone wrote months ago. This page defines the layer that changes that.
89% of companies have failover in place. Only 47% get approval rates above 97% in a typical month. Connectivity was never the bottleneck. PYMNTS × Spreedly, 2026
Connecting PSPs and running a flow is table stakes. The difference between platforms is moving up — into the quality of the decision that feeds the flow.
Agent-initiated payments arrive with no browsing session and no human at the challenge screen. Rules written for people have nothing to say about them.
| Era | Who decides | How often | Decides on | What breaks |
|---|---|---|---|---|
| 01 · Static | Whoever wrote the rule | Per release | Assumptions at the time of writing | The market moves; the rule doesn't |
| 02 · Dynamic | An ops team with a dashboard | Weekly, when someone looks | Last week's averages | Anything faster than the review cycle |
| 03 · Autonomous | The decision layer, inside limits you set | Every transaction | What is true for this transaction, now | — |
“Frequent rule updates” is the manual version of what Era 3 does on its own.
Nothing is down. Nothing alerts. Approval on one route just slides, in the middle of the busiest hour of the quarter.
Keeps routing exactly where it was told to. The loss shows up in next week's report.
Sees the outcomes change and moves the next transaction to a healthier route.
A new market opens. Nobody has written routing for it, so traffic falls through to defaults built for somewhere else.
Applies a generic default until someone finds the time to tune it.
Starts from the outcomes it sees on the new corridor and adapts without a ticket.
For twenty minutes authentication is slow or failing. Low-risk customers are sent into a challenge they cannot complete.
Applies the same 3DS policy to everyone. Conversion drops until the incident ends.
Changes the friction posture for the transactions where that is allowed and safe.
The first attempt soft-declines. The pre-configured second route is having a bad day of its own.
Retries on the fallback that was written down. The second attempt fails as well.
Chooses the recovery path from what is working now, not from what was written then.
| Category | The question it answers | Where it stops |
|---|---|---|
| Orchestrator | How do I connect and execute across many PSPs? | Executes what it was configured to do |
| PSP-native optimization | How do I approve more on my own rails? | Cannot decide across PSPs |
| Fraud tools | Is this transaction risky? | One decision out of many |
| Rules engine | What did we agree to do in this case? | Only as current as its last edit |
| Decision layer | What should be executed for this transaction, right now? | Hands the decision to the orchestrator to execute |
A decision layer is additive. It makes the orchestrator better at the job it already does. It does not move money and it does not replace a connection.
The execution layer is solved. The decision layer above it is where payment performance is now decided.
If you run payments, build an orchestration platform or invest in the stack, I am glad to talk it through.
