Decline Salvage

Decline salvage automatically retries declined transactions according to a configurable schedule, recovering revenue that would otherwise be lost.

Navigation: Sidebar > Payments > Salvage

Why Use Decline Salvage?

Many legitimate transactions decline for temporary reasons:

• Insufficient funds - Customer’s balance is low
• Network issues - Temporary processor problems
• Bank holds - Temporary fraud prevention
• Rate limiting - Too many recent attempts

By intelligently retrying these transactions, you can recover revenue that would otherwise be lost — track your actual rate in the Decline Salvage report.

How Salvage Works

When a transaction declines:

1. Evaluate eligibility

   • Confirm the profile is active and its Transaction Type covers this charge (initial or rebill)
   • Check the transaction amount against the profile’s Minimum/Maximum Amount
   • Check that the transaction’s decline code is not in the profile’s Excluded Decline Codes list

   There is no built-in notion of a “non-retryable” decline. Every decline reason is retried unless you explicitly exclude its code on the profile.

2. Schedule retry

   • Queue the original declined transaction on the dedicated salvage queue
   • Wait the greater of the delay configured for that attempt and the profile’s Min Retry Interval (default 15 minutes) - a custom 5-minute first attempt actually runs at 15 minutes
   • The gateway is resolved when the retry runs, not when it is scheduled

3. Execute retry

   • Re-charge the order’s full cart total - the whole cart including shipping and tax, not just the amount of the charge that declined - and re-attach every cart product to the new transaction
   • Record the result

   This full-cart re-charge is why upsell transactions are never salvaged: retrying one would re-bill items the initial charge already covered.

4. Handle result

   • Success: Transaction completes normally
   • Decline: Schedule next retry or mark as failed

Salvage Profile Types

Standard

Pre-configured retry schedule optimized for common scenarios.

Default Schedule:

Best for:

• Getting started quickly
• Most transaction types
• General use

Custom Schedule

Define your own retry timing.

Best for:

• Specific business requirements
• Different product types
• Subscription vs one-time optimization

Creating a Salvage Profile

Step 1: Navigate to Salvage

1. Go to Payments > Salvage in the sidebar
2. Click New Profile or Add Profile button

Step 2: Configure Basic Settings

Transaction Type Options

Step 3: Configure Retry Schedule

For Custom Schedule type, define your retry attempts:

1. Click Add Retry Attempt to add an attempt
2. Set the delay (in minutes) for each attempt
3. Attempts are numbered in the order you add them. Remove one with the trash icon - the first attempt cannot be removed - and the remaining attempts renumber automatically. There is no way to reorder attempts; delete and re-add them to change the order.

Example Custom Schedule - each delay is the wait after the previous attempt, not an offset from the original decline:

Because the delays are cumulative, check the running total against Max Retry Window (default 4320 minutes / 3 days), which is measured from the original declined transaction.

Step 4: Configure Limits

Step 5: Configure Exclusions

Exclude certain decline codes from salvage:

Select decline codes that should never be retried. The available options are:

• Insufficient Funds
• Card Declined
• Expired Card
• Invalid Card
• Suspected Fraud
• Lost Card
• Stolen Card
• Invalid Expiry
• Invalid CVC
• Processing Error

The usual hard declines to exclude are Lost Card, Stolen Card, Suspected Fraud and Invalid Card.

Step 6: Save

Click Create Profile to save the new profile (the same button reads Update Profile when you are editing an existing one).

Managing Salvage Profiles

Profile List

The list shows all configured profiles:

The list paginates at 10 profiles per page.

Editing a Profile

1. Find the profile in the list
2. Open the row’s ⋯ (ellipsis) menu and choose Edit
3. Modify settings
4. Click Update Profile

Deleting a Profile

1. Find the profile in the list
2. Open the row’s ⋯ (ellipsis) menu and choose Delete
3. Type the profile name in Confirm Profile Name (case-insensitive)
4. Click Delete Profile

Deletion is a soft delete: creating a profile with the same name later restores and updates the old record.

Warning: Ensure no campaigns are using this profile before deleting.

Assigning Profiles to Campaigns

To point a campaign at a specific salvage profile:

1. Go to CRM > Campaigns
2. Edit the campaign
3. In the Settings tab, under Decline Salvage Settings, choose a Salvage Profile
4. Save the campaign

Assigning a profile is optional - a campaign with no profile selected falls back to the team’s default salvage profile. To stop salvage for a campaign entirely, tick Disable decline salvage in Decline Salvage Settings; that overrides the team default and hides the profile dropdown.

Salvage Reporting

Track salvage effectiveness:

Salvage Report

Navigation: Reports > Decline Salvage

The report shows five summary cards:

• Total Attempts
• Successful Salvages
• Revenue Generated
• Success Rate
• Avg Revenue/Success

It counts salvage retry transactions only (retry_attempt > 0) - the pool of original declines eligible for salvage is not reported here. The report also excludes test orders and any order marked throttled, so its totals can sit below what you see elsewhere.

Key Metrics

Best Practices

Profile Configuration

Start with Standard:

• Use Standard type initially
• Monitor results for 2-4 weeks
• Create Custom only if data supports changes

Set Reasonable Limits:

• Max Attempts: 4-6 (more can annoy banks)
• Retry Window: 3-7 days max
• Minimum Interval: 15+ minutes

Exclude Hard Declines:

• Never retry stolen/lost cards
• Never retry fraud declines
• Never retry Invalid Card declines

Transaction Types

Initial Transactions:

• More aggressive salvage acceptable
• Customer expects the charge
• Higher recovery potential

Rebills (Subscriptions):

• More conservative approach
• Customer may have forgotten
• Balance retry with communication

Monitoring

Review weekly:

• Success rate by profile
• Revenue generated
• Decline reasons being salvaged

Adjust based on data:

• Increase delays if recovery low
• Reduce attempts if lots of failures
• Add exclusions for stubborn declines

Salvage and Gateway Selection

When a salvage retry occurs:

Same Gateway Retry

Unless a Custom Schedule sets a gateway for that attempt, the retry is submitted to the same gateway that received the original decline.

Why:

• Card may be on file
• Bank may approve second attempt
• Simplest approach

Retrying on a different gateway

Salvage retries do not re-run orchestrator routing. The retry is submitted with an explicit gateway - the gateway that took the original decline, or the per-attempt gateway from a Custom Schedule - and an explicit gateway bypasses the orchestrator entirely.

To move a retry to a different processor, set the Gateway on that attempt in a Custom Schedule. If the configured gateway is missing, belongs to another team, or is not Active, the retry falls back to the original decline’s gateway.

Benefits:

• Different processor may approve
• Avoids same-gateway rate limiting
• Optimizes for approval

Troubleshooting

Salvage Not Running

Check the profile:

• Profile is Active
• Transaction amount is within the profile’s Minimum/Maximum Amount
• Transaction Type covers this charge (initial vs rebill)
• Decline code is not in Excluded Decline Codes
• The retry schedule defines a delay for this attempt number, and Max Attempts / Max Retry Window are not exhausted

Check the campaign:

• The campaign has a profile assigned, or the team has an active default profile
• Disable decline salvage is unchecked on the campaign

Check the transaction - these are never salvaged:

• Upsell transactions
• Alternative-payment transactions (e.g. PayPal)
• Salvage retries themselves
• Transactions on an order that already has a completed or authorized charge, or whose status is already Completed or Processing
• Declines that are not the most recent declined charge on the order
• Subscriptions no longer in Salvaging status (or already Salvage Failed)
• Transactions with no stored payment method to re-charge

Low Recovery Rate

Consider:

• Retry delays may be too short
• Wrong decline types being retried
• Card data may be fundamentally bad

Too Many Retries

Check:

• Max attempts setting
• Retry window setting
• Exclusion list completeness

Related Topics

• Decline Mappings - Standardize decline codes
• Payment Gateways - Gateway configuration
• Payment Orchestrators - Failover routing
• Cascade Profiles - Immediate retries, before the customer leaves