HSRCPAY Documentation

Routing Simulation

Provider selection, fallback, retry, and routing trace tests in sandbox.

Routing simulation is how you answer "which provider, in what order, and why?" before production. In sandbox there is no money movement; the decision mechanism and event/webhook behavior run close to the real flow.

Sandbox vs Production

SandboxProduction
OutcomeSimulated / testReal provider response
MoneyNoneReal
PurposeIntegration and fallback validationReal collection

Sandbox success rate is not a promise of live approval rate.

Routing Inputs

InputEffect
Payment method / card networkCapability matching
Country / issuerLocal or 3DS-required route
Amount / currencyMin-max and fee rules
routing_strategyNarrow or multi-candidate list
Secure modeFilter for 3DS-capable providers
Provider "health" testDegraded / timeout scenarios

Rule Logic (Verbal)

Example thought experiments (your account rules may differ):

  • TR + local network → preferred local sandbox provider
  • Secure mode enabled → 3DS-capable candidate required
  • High amount → stricter capability or extra step

Fallback and Retry

  • If the first candidate is not suitable or there is a transient error, the next candidate may be tried.
  • Hard decline: Do not loop with the same card; request a new method.
  • Soft decline: Fallback or controlled retry; verify status with payment GET.

3DS Routes

When secure mode is enabled, candidates that do not support 3DS are filtered out. Getting REQUIRES_ACTION in sandbox shows whether integration can handle challenge and callback.

Observability

After each confirm, ask:

  • Which candidate was selected, which was filtered out?
  • When did fallback kick in?
  • How many charge attempts were created?
  • Which webhook/event arrived?

Example Scenario Table

ScenarioExpectation
TR cardLocal route
Secure mode3DS-capable candidate
Provider degradedSecond candidate
Soft declineNext candidate or REQUIRES_PAYMENT_METHOD
Unsupported currencyConfig filtered out

On this page