Skip to content

Version 1.3.5 - Cascade Profiles and Hosted Tokenization

Automatic gateway cascading on declines, hosted card tokenization, and the Swiparas and BridgePay gateways

Released on July 14, 2026

This entry records features that shipped between July 3 and July 14, 2026 and were not documented at the time.

Declines can now cascade automatically to backup gateways, card data can be tokenized without touching your servers, and two more gateways are available.

Highlights

Cascade Profiles

A cascade profile gives a gateway an ordered list of backup gateways to try when a payment declines. Where decline salvage retries on a schedule, cascading retries immediately, within the same checkout, so a recoverable decline can still convert before the customer leaves.

Each profile attaches to one source gateway and defines:

  • Cascade gateways — the ordered list of gateways to try after a decline.
  • Applies to — which payment types cascade: initial sales, rebills, upsells, or any combination.
  • Respect sticky MID — whether a subscription pinned to a specific gateway may cascade off it.
  • Allow cascade on forced gateway — whether a transaction that explicitly named a gateway may still cascade.
  • Override orchestrator failover — whether this profile takes precedence over the orchestrator’s own failover routing.

A transaction makes at most three cascade attempts, and never retries a gateway it has already attempted in the same cascade. Each gateway supports one active profile at a time, and profiles can be deactivated without deleting them.

Hosted Tokenization

Card details can be collected through a hosted iframe served from a dedicated secure subdomain, so raw card numbers never reach your servers or your checkout page’s JavaScript. Your page receives a single-use token and sends that to the API in place of the card.

Tokens are consumed on a successful charge and survive a decline, so a customer can correct a detail and retry without re-entering the card. See Hosted Payments for the embed snippet and publishable key setup.

Swiparas Gateway

Swiparas is available as a gateway type, configured with an API key, merchant account, and optional store ID. Where a CSE public key is supplied, card data is encrypted client-side before transmission. An optional webhook HMAC key verifies inbound payment notifications.

BridgePay Gateway

BridgePay is available as a gateway type, taking a username, password, and merchant account code, with a test mode toggle for sandbox processing.

Breaking Changes

None. Cascading is inactive until you create a profile, and existing gateway routing, decline salvage, and orchestrator behavior are unchanged for gateways without one.

Navigation

Type to search…

↑↓ navigate↵ selectEsc close