Business Route Map
Merchant segments, integration routes, and a sandbox-first production readiness approach.
The purpose of this map is to read HSRC Pay by "what business need?" not "which API folder?". The same infrastructure offers different starting points for a retailer that wants fast checkout, a SaaS that keeps its own UI, or a marketplace trying multiple providers.
What is a Business Route?
A Business Route is a decision map showing which product path a merchant should follow inside HSRC Pay.
Typical sequence:
- Rehearse behavior with Sandbox Network.
- Choose Hosted Checkout or API-only integration model.
- Validate payment lifecycle and webhook handling.
- Prepare provider/routing settings with production separation.
- In live operations, do monitoring, trace, reconciliation, and routing optimization.
Customer segments
| Segment | Need | Recommended integration | Core pages to use | Watch out for |
|---|---|---|---|---|
| New merchant | Fast, controlled payment acceptance | Hosted Checkout | Checkout Session, Sandbox Cards | Redirect result must be verified with webhook |
| SaaS platform | Payment management across customer/account boundaries | API + Checkout mix | Payment Lifecycle, Data Models | Tenant/account boundaries must stay clear |
| Marketplace | Multiple payment methods and operational visibility | API-only + webhook-first | Business Flow, Webhook Delivery | Payment/charge attempt split must be preserved in reporting |
| High-volume business | Routing, fallback, decline, and operational control | API-only + routing simulation | Routing Simulation, Testing Declines | Retry/fallback behavior must be idempotent |
| Enterprise with custom provider needs | Bind provider behavior to standard lifecycle | Provider catalog + config + adapter | Provider and Adapter Model, Sandbox Network | Credentials and internal registry must not leak to public surfaces |
Use cases
Fast payment acceptance
The merchant starts with hosted checkout. HSRC Pay makes the payment form, payment method collection, secure mode handling, and redirect/return behavior more manageable.
API-only orchestration
The technical team keeps its own UI: create, confirm, REQUIRES_ACTION, decline, capture, refund, cancel, and webhook in its own flow.
Routing and fallback-focused operations
The merchant works with multiple providers or provider configs. The routing engine makes route decisions testable with inputs such as provider capability, rules, amount, currency, payment method, and sandbox scenario.
Integration routes
| Route | When to choose | Technical outcome |
|---|---|---|
| Sandbox-first hosted checkout | Fast go-live and low frontend load | Checkout Session, sandbox cards, webhook verification |
| API-only payment flow | UI stays entirely on merchant side | Payment create/confirm, next action handling, webhook-first state |
| Provider config route | Provider behavior management is critical | Provider catalog, config, adapter execution, normalized result |
| Routing simulation route | Multi-provider and fallback behavior will be tested | Candidate plan, route trace, retry/fallback validation |
Sandbox-first approach
Sandbox is not a toy; it is the engineering space where you rehearse payment behavior before production.
In sandbox, test these behaviors, not only successful payments:
- 3DS challenge and resume
- Hard decline and soft decline
- Provider timeout and issuer unavailable
- Capture/refund/void
- Webhook retry and idempotency
- Routing fallback
Production readiness
Before moving to production:
- Separate sandbox and production credentials.
- Keep provider credentials out of public docs and app logs; store them in secure secret management boundaries.
- Payment/charge state transitions must be understood by the team.
- Webhook handler must tolerate duplicate delivery.
- Provider attempts must be visible via dashboard/trace.
Post-launch operations
Live operations is not only collecting payments. Payment infrastructure teams should monitor:
- Provider-level success/decline distribution
- Fallback usage rate
- 3DS requires_action completion rate
- Webhook delivery failure and retry count
- Refund, void, and capture operations
- Trace-based incident analysis
Which customer should choose which route?
If you want to start fast, use Hosted Checkout. If you need UI control and a custom backend flow, use API-only. If provider behavior, routing, and fallback are critical, follow the Provider and Adapter model + Routing Simulation route.
Do not treat anything not marked on the roadmap or as a future capability as a production guarantee; verify current API Reference and environment settings before live integration.
Next steps
- Hosted payments: Checkout Session Guide
- API flows: Payment Flows
- Sandbox rehearsal: Sandbox Network
- Production checks: Integration Readiness