Skip to main content

VORA — Payment Routing

VORA is Von Payments' gateway-orchestration layer. It picks the underlying payment processor at payment time so you don't have to.

From your perspective as a developer, VORA is transparent. You always call the same endpoint — POST /v1/sessions — and we handle processor selection, failover, and reconciliation. You do not need to know which processor fires a given charge.

Why it exists​

Every merchant on Von Payments is attached to exactly one "entry point" for their payments. That entry point is one of three things:

Entry pointWhat happens at payment time
Direct gatewayWe call a single processor directly. No router in between.
VORA routerWe hand the payment to VORA, which internally picks a processor based on cost, geography, and failover rules.
Third-party router (legacy)We hand the payment to an external orchestrator.

From your code, all three look identical. POST /v1/sessions returns a checkoutUrl and the buyer pays on our hosted page.

Note: The active entry point also determines the submit semantics of the Embedded Fields SDK (vora.js). On some entry points, calling submit is pure tokenization — it returns a reusable vp_pmt_* token and charges nothing. On the charge-and-save flow, submit charges the card on the spot and (with a buyer on the session) also vaults a reusable token in the same step. Your Embedded Fields code must handle both, so it discriminates on the result shape rather than assuming a token is always returned. See Charge-and-save for the result-shape contract.

What changes in your integration​

Nothing. Session creation is unchanged, session retrieval is unchanged, return-signature verification is unchanged. VORA is entirely server-side inside Von Payments — none of its state is exposed on the merchant API.

Processor selection state (which processor handled a charge, the processor-side merchant ID, etc.) lives in internal Von Payments systems and surfaces only to merchants through the Dashboard and Ops tooling — not through the public API.

What you don't need to do​

  • Choose a processor. VORA does that.
  • Handle processor-specific failure codes. The SDK normalises errors into a single VonPayError.code union.
  • Build any failover logic. VORA routes around processor outages for you.
  • Change your signed-redirect verification. The return signature is the same regardless of which processor was used.

When you might care which processor fired​

You usually don't. If you need processor-side reconciliation (matching Von Payments transactions against a processor statement) or support escalation context, contact support with your session ID — we can surface the processor-side transaction ID for that specific session. There is no API surface for bulk processor-level reporting on the merchant side today.