Get Payment Route

View as Markdown

The payment’s pinned route, what would apply without a pin, and whether a pin would be accepted (pinnable) so the dialog need not try to find out.

Authentication

AuthorizationBearer

Bearer authentication of the form Bearer <token>, where token is your auth token.

Path parameters

intent_idstringRequired
account_idstringRequired

Response

Successful Response
engine_enabledboolean

Whether the configurable-routing engine is switched on for this account. When False the pin is stored but has no effect: the resolver returns before reading any pin, and processor selection stays on the legacy path. would_apply is still computed so the dialog can describe the engine’s decision, but the dialog should warn that it is not live.

pinnableboolean

Whether a POST on this resource would be accepted. False for a payment no charge path reads the pin of: created from an invoice or a migration, already in a terminal state, or checked out through a session that names its own route (which outranks a payment pin). Always True for a subscription. not_pinnable_reason says why when False.

would_applyobject

What routing would decide for a payment or subscription right now.

Backs the pin/unpin confirm dialog, which the spec requires to show “what rule or default would have applied”.

route_idstring or nullOptional
The pinned route, or null when not pinned
route_namestring or nullOptional
not_pinnable_reasonstring or nullOptional

Why pinnable is False; null when it is True

Errors

422
Unprocessable Entity Error