Routing payments
Define processor routes—ordered lists of payment processors—to control how payments are attempted. When a customer pays, PaymentKit tries each processor in order until one succeeds.
Before you begin
Make sure you have:
- At least two connected payment processors.
- Processor IDs handy (find them in Developers > Payment Processors or via
GET /v1/processors).
If you only have one processor connected, PaymentKit will only use your default processor. At this time, payment routes can only be defined via the API.
How payment routes work
PaymentKit will try each processor in the order of your defined route until one succeeds. If a processor is unavailable or doesn’t support the currency, PaymentKit skips to the next processor automatically.
Without a defined route, PaymentKit will first try your default processor, and then fall back to other connected processors by connection order.
Create a route
Response:
Use a route in checkout
Pass a single processor_route_id when creating a checkout session. The route itself contains an ordered list of processors — PaymentKit tries each one sequentially until a payment succeeds. You don’t pass multiple processor IDs directly; instead, define the processor list inside the route and reference the route by its ID.
One route ID, multiple processors. The processor_route_id field accepts a single route ID (e.g., proute_xyz789), not an array of processor IDs. To control which processors are used and in what order, configure them within the route via POST /v1/processor-routes. For cascade pricing, each tier can specify its own processor_route_id to use a different fallback chain.
Pass the processor_route_id when creating a checkout session:
Set a default route (optional)
Apply a route to all checkout sessions without needing to specify it each time.
Manage routes
List all routes:
Update a route:
Delete a route:
Routes currently referenced by checkout sessions or set as account default cannot be deleted.