A merchant on WinkPG can hold more than one processor account. When you submit a transaction you don't name one: the gateway picks. This guide explains how it picks, what happens when the chosen processor doesn't process, and how to read the decision back for a sandbox transaction so you can see the reasoning rather than infer it.

You don't have to configure anything to use routing. A merchant with a single processor account routes to it every time, and everything below still describes what happened.

How a processor is chosen

Routing runs once per transaction, after the gateway has enriched the request and before it authorizes. It works on a candidate list, not a lookup:

1. The candidates are the merchant's active processor profiles, narrowed to those that can service the payment method you sent.
2. A pipeline of rules runs over the list. Each rule can strike a candidate out, or score one up. Rules are the merchant's own configuration expressed as decisions: which card brands a profile accepts, which rail an EBT transaction needs, whether a processor is switched off at the platform level, whether the merchant is pinned to a sandbox processor.
3. The highest-scoring survivor wins, and the transaction authorizes against it.
4. If nothing survives, the gateway may fall back. Some eliminations are advisory and the gateway would rather route than decline: if every candidate was struck out for a reason of that kind, it takes the first active profile anyway. Other eliminations are absolute and are never rescued, so a transaction eliminated only for those reasons is refused instead. A refusal comes back as a ProcessorNotConfigured result rather than as a decline: nothing was sent to a processor.

The reason an elimination is absolute rather than advisory is always a safety one. A merchant pinned to the sandbox simulator must never reach a real processor because something else went wrong, and a processor an operator has switched off must not take traffic because a filter misfired.

Failover

If the chosen processor answers that it didn't process the transaction, the gateway re-runs the selection with that processor excluded and authorizes once more on whatever the pipeline picks next.

Four things about this are worth building against:

• It happens once. If the second processor also doesn't process, the transaction ends as a decline. There is no third attempt.
• Only a "didn't process" answer triggers it. A decline, a timeout, or a transport failure is terminal. Those outcomes are ambiguous about whether money moved, and retrying an ambiguous authorization risks charging the cardholder twice, so the gateway doesn't.
• Nothing about the first attempt is persisted. The transaction carries the processor that actually processed it, so a later capture, refund, or void binds to the right one. You won't find a half-written attempt against the excluded processor.
• Follow-up operations never re-route. A capture, refund, reversal, or void always goes to the processor that holds the original authorization. Failover applies to the initial authorization only.

If no fallback survives the exclusion, the transaction is refused with ProcessorNotConfigured rather than declined, for the same reason as above: nothing reached a processor.

Sandbox routing

A sandbox merchant carries a processor mode, which decides what its transactions reach:

• Loopback routes every transaction to the built-in simulator. Nothing leaves WinkPG, and the response is whatever the test scenario you triggered says it is. This is the default and is what you want for almost all development.
• Processor Test routes to the merchant's real processor profiles, against those processors' own test hosts. Use it when you are certifying against a specific processor rather than developing against the gateway.

The mode is applied as a routing rule like any other, which is why it shows up in the decision: on a Loopback merchant you will see the real profiles struck out with the reason SandboxProcessorMode, and the loopback profile selected.

Reading the routing decision

For a sandbox transaction, WinkPG keeps the decision and shows it to you. Open Request log in the portal, open the API call that created the transaction, and read the Routing decision section at the bottom of the page.

It shows:

• The verdict, either routed or not routed.
• Every candidate the pipeline considered, in evaluation order, each marked selected, eliminated, or considered. An eliminated candidate carries the reason it was struck out, as a stable reason name such as SandboxProcessorMode, PaymentTypeNotSupported, ProcessorDisabled, or LoopbackOutsideSandbox.
• What each rule recorded, in the order the rules ran.

A candidate can be marked both selected and eliminated. That's the fallback described above: nothing survived, and the gateway routed anyway rather than refusing the payment.

Four limits to know before you build a habit around it:

• Sandbox only. Production transactions carry no routing decision, by design. This is a development aid, not a reporting surface.
• It's kept for a limited period. Decisions are pruned after a retention window, so an older sandbox transaction shows nothing. That's ordinary, not a fault.
• It isn't in the API response. The decision is a portal surface. Your integration shouldn't depend on reading it, and nothing about it forms part of the API contract.
• It names processors, not profiles. You see which processor a candidate was configured for and never the internal identifier of the merchant's profile. When a merchant holds two profiles on one processor, the position column is what tells the two rows apart.

Exercising failover

The quickest way to see all of this is the Exercise processor failover blueprint, which sets up a merchant with two processor profiles where the first refuses to process, and runs both outcomes: the fallback approving, and the fallback exhausted. Run it, then open the request log entry for each transaction and compare the two routing decisions.

The sandbox testing guide lists the other simulator triggers you can combine with it, including the declines and host errors that aren't failover-eligible, which is a useful thing to confirm for yourself.

What to build against

Routing isn't part of your request, by design. Don't send a processor, don't infer one from a previous transaction, and don't treat the routing decision as an API contract.

Two outcomes are worth handling explicitly:

• ProcessorNotConfigured means the gateway had nowhere to send the transaction. It's a configuration problem on the merchant, not a payment failure, and retrying the same request unchanged won't help. Surface it differently from a decline.
• A decline after failover looks exactly like any other decline. There is no field that says a second processor was tried, and your handling shouldn't depend on one.