High Wire Lift
Products / Lift
High Wire LiftThe acceptance suite: tokens, updater, retries, and cascading
Most lost revenue is not fraud. It is good payments that fail: an expired card on a subscription, an issuer that says no for a reason that would not apply a minute later, or a processor having a bad hour. This is the set of tools that recovers them.
Six tools working on the same payment.
Each one helps on its own. Together they decide whether a payment that should succeed actually does.
Network tokens, requested where it counts.
A credential issued by the card network in place of the card number. When a customer's card is replaced, it keeps working, so stored cards and subscriptions do not break. The card number stays as a fallback and is retried when a token attempt fails.
Sample data
Around four in ten cards are replaced each year. We refresh the details before the billing date instead of waiting for the decline.
Driven by the decline code and the issuer's behavior, not a fixed schedule. A soft decline is treated differently from a "do not honor."
When one processor declines or stops answering, the payment is re-sent to another MID that can take it. The customer sees one attempt.
Attempts are capped per card, per issuer, and per window, and we report what the retries actually earned.
Processors perform differently with the same issuer and BIN range. Routing follows the evidence and updates as it changes.
High Wire Vault
Where your stored cards actually live.
A stored card base living inside one processor's vault is the quietest form of lock-in in payments. Moving it later is a regulated-data migration with a coordinated cutover, which is why few businesses ever do it, and why processors stay relaxed about your pricing conversations.
High Wire keeps the vault, so your stored cards are held independently of any one processor. How freely a given credential moves depends on who requested it, and we tell you which of your processors share network tokens and which keep their own reference behind one. Where a processor abstracts the credential, moving that volume is a card data migration, and we run it rather than leave you to negotiate it.
| Credential type | Who requested it | Can it be charged on another processor? |
|---|---|---|
| Processor reference | The processor, under its own credentialsCommon. You receive an identifier that only that processor understands | No. Moving means a card data migration between PCI-compliant providers, which we run for you |
| Network token requested by a processor | The processor, under its own token requestor ID | Not in practice. Lifecycle updates and cryptograms still come through that processor |
| Network token requested independently | A token requestor ID that is not tied to one processorWhere we are heading: tokenizing the card before the payment reaches any processor | Yes. The same credential can be presented to whichever processor you route to |
| PCI scope | Reduced, and tied to that processor | Reduced, and not tied to one processor |
Roadmap: requesting network tokens ourselves, so a card is tokenized before the payment reaches any processor and the same credential can be routed to any of them. Until that is live, portability is per processor, and we tell you which is which before you board.
A better model for stored card data.
Three properties decide whether a stored card base is an asset or a liability. Most setups get one of them.
The card is collected once, by us, and presented to whichever processor a payment is routed to. Adding a processor does not mean collecting cards again or running two vaults side by side.
A vault that belongs to your processor makes leaving a migration project. Ours does not. Where a processor abstracts the credential, we run the migration for you rather than leaving you to negotiate it.
Card data is collected in a component that keeps it off your servers, so the control set you have to satisfy shrinks. See what that means for your questionnaire Preview.
What happens to a declined payment.
Not every decline should be retried, and the ones that should are not all retried the same way. The ladder below is what runs before a customer ever sees a failure.
Sample flow. Attempt caps and retry windows are configurable per merchant.
Subscriptions lose customers to expired cards, not cancellations.
Involuntary churn is the quietest revenue leak in recurring businesses. Updated credentials, network tokens, and retry timing tuned to the billing cycle keep customers who never intended to leave.
What it does
- Network tokens, with the card number kept as a fallback
- Card account updater run ahead of the billing date
- Adaptive retries classified by decline code and issuer behaviour
- Cascading to a second processor when the first says no
- Attempt caps per card, issuer, and window
- Split-tested routing changes before they go to all traffic
What you get
- Fewer declines on stored cards, because credentials stay current
- Recovered revenue from soft declines that would otherwise be lost
- Less involuntary churn on subscriptions, which is the quietest leak in recurring billing
- Retry costs that stay in proportion to what they recover
- Evidence for every change, measured on your own traffic
Prove it, then tune it.
Every claim on this page should be visible in your own data, by processor, market, card type, and issuer. Routing changes can be split-tested before they are applied to all traffic.
Compare processors on the same traffic, with the difference expressed in approved volume rather than percentage points alone.
Send a share of traffic down an alternative route, measure, then promote the winner. No code change and no engineering cycle.
What retries recovered, what they cost, and which decline codes are worth pursuing for your book.
Lift approvals on the traffic you already have.
Most of the gain is in payments you are already sending. Start by measuring where they fail.