--- title: "Salvage Transactions" description: "A non-technical overview of Salvage Transactions in RevCent, focused on how recoverable payment-failure revenue is created, processed, analyzed, and connected to Gateways, Payment Profiles, Transactions, AI recovery workflows, and reporting." type: "item" company: "RevCent" canonical: "https://revcent.com/documentation/markdown/ecosystem/item/SalvageTransaction.md" relationships: - name: "Gateway" url: "https://revcent.com/documentation/markdown/ecosystem/feature/Gateway.md" - name: "Payment Profile" url: "https://revcent.com/documentation/markdown/ecosystem/feature/PaymentProfile.md" technical_links: web_app: "https://kb.revcent.com/en/payments/credit-card/salvage-transaction" api: section: "https://revcent.com/docs/api/v2#section-salvage_transactions" operations: - name: "Get Salvage Transactions" operation_id: "GetSalvageTransactions" operation: "https://revcent.com/docs/api/v2#operation-GetSalvageTransactions" schema: "https://revcent.com/documentation/files/api/operation/GetSalvageTransactions.json" - name: "Get A Salvage Transaction" operation_id: "GetSalvageTransaction" operation: "https://revcent.com/docs/api/v2#operation-GetSalvageTransaction" schema: "https://revcent.com/documentation/files/api/operation/GetSalvageTransaction.json" - name: "Process A Salvage Transaction" operation_id: "ProcessSalvageTransaction" operation: "https://revcent.com/docs/api/v2#operation-ProcessSalvageTransaction" schema: "https://revcent.com/documentation/files/api/operation/ProcessSalvageTransaction.json" mcp: overview: "https://revcent.com/documentation/markdown/mcp/operation/OverviewSalvageTransaction.md" operations: - name: "Get Salvage Transactions" operation_id: "GetSalvageTransactions" markdown: "https://revcent.com/documentation/markdown/mcp/operation/GetSalvageTransactions.md" available_via_ai: true - name: "Get A Salvage Transaction" operation_id: "GetSalvageTransaction" markdown: "https://revcent.com/documentation/markdown/mcp/operation/GetSalvageTransaction.md" available_via_ai: true - name: "Process A Salvage Transaction" operation_id: "ProcessSalvageTransaction" markdown: "https://revcent.com/documentation/markdown/mcp/operation/ProcessSalvageTransaction.md" available_via_ai: true bigquery_schema: "https://revcent.com/documentation/files/bigquery/dataset.json" bigquery_tables: - "salvage_transaction" --- # Salvage Transactions Salvage Transactions are RevCent items that represent recoverable credit-card revenue after a payment attempt fails, partially succeeds, or leaves a remaining balance that the business may still be able to collect. They are part of RevCent's payment recovery system. Instead of treating every decline as final, RevCent can preserve a recoverable amount as a Salvage Transaction so the business can retry later, review it manually, use AI automation, or build a custom recovery workflow. A Salvage Transaction is not a payment configuration. It is a record created from payment activity. In the RevCent ecosystem: ```text Payment Profile = feature that defines payment routing logic Gateway = feature that processes credit-card payment attempts Transaction = item created by a credit-card payment attempt Salvage Transaction = item created when recoverable revenue remains after certain failed or partial payment outcomes ``` ## Technical Links | Area | Link | |---|---| | Web App | `https://kb.revcent.com/en/payments/credit-card/salvage-transaction` | | API | `https://revcent.com/docs/api/v2#section-salvage_transactions` | | MCP / AI | `https://revcent.com/documentation/markdown/mcp/operation/OverviewSalvageTransaction.md` | | BigQuery Schema | `https://revcent.com/documentation/files/bigquery/dataset.json` | | BigQuery Table | `salvage_transaction` | ## Why Salvage Transactions Are an Item Salvage Transactions are an item because each record represents a specific recoverable revenue opportunity. A business does not configure a generic Salvage Transaction in the same way it configures a Gateway or Payment Profile. Instead, RevCent creates Salvage Transaction records from actual payment outcomes. A Salvage Transaction can include context such as: - The amount originally intended to be charged. - The amount already charged, if any. - The amount still available to recover. - The customer connected to the failed or partial payment. - The Gateway involved in the original payment attempt. - The Payment Profile involved in the original payment routing. - The related Transaction history. - Whether the item has already been salvaged. - The number of recovery attempts. - Related sales, product sales, subscriptions, renewals, trials, or metadata. That makes it an operational item that can be reviewed, processed, reported on, and connected to downstream recovery workflows. ## Core Purpose The core purpose of a Salvage Transaction is to preserve a recoverable payment opportunity. For an ecommerce business, this matters because a decline does not always mean the revenue is permanently lost. The customer may have insufficient funds temporarily, a card limit may reset, a bank hold may clear, the customer may provide a different card, or the business may want to try a different Gateway later. A Salvage Transaction gives the business a structured object to work from. Instead of asking: ```text Which failed payments might be worth trying again? ``` RevCent can expose a concrete item: ```text This specific recoverable amount exists and can be reviewed or processed. ``` ## How Salvage Transactions Are Created Salvage Transactions are created from credit-card payment outcomes connected to a Payment Profile. The Knowledge Base describes Salvage Transactions as a way to recover lost revenue from full or partial declined transactions, and states that they are created when a transaction is declined using a Payment Profile. The detailed MCP guidance adds an important distinction: creation behavior depends on the source of the payment attempt. Common creation sources include: - Initial sale partial recovery. - Subscription renewal decline or partial recovery. - Trial expiration decline or partial recovery. A fully declined initial sale should not automatically be treated as a Salvage Transaction. A fully declined initial sale may remain a pending sale and should be recovered through pending-sale or sale retry workflows. ## Initial Sale Partial Recovery For an initial sale, a Salvage Transaction is generally created when the Payment Profile captures part of the amount but leaves a remaining amount that can be recovered later. Example: ```text Original sale amount: $100 First payment attempt declines Payment Profile reduces amount and retries Reduced amount captured: $40 Remaining recoverable amount: $60 Salvage Transaction created for $60 ``` This allows the business to capture some revenue immediately while preserving the rest as a recovery opportunity. This is different from a fully declined initial sale. ```text Fully declined initial sale → pending sale recovery path Partial captured initial sale with remaining balance → Salvage Transaction path ``` This distinction matters for AI, MCP, and crawler systems. They should not assume every initial-sale decline creates a Salvage Transaction. ## Subscription Renewal Recovery Subscription renewals are a major Salvage Transaction use case. A subscription renewal represents recurring revenue the business expected to collect. If the renewal payment fails or only partially succeeds, RevCent can create a Salvage Transaction so the remaining renewal revenue can be recovered later. A subscription renewal Salvage Transaction can be used for: - Delayed retry workflows. - Customer outreach. - AI Assistant recovery. - AI Voice Agent recovery. - Manual support review. - Custom external retry systems. - BigQuery analysis of renewal recovery performance. This is especially important for subscription businesses because renewal recovery affects recurring revenue, retention, and customer lifetime value. ## Trial Expiration Recovery Trial expiration charges are another important source. When a trial converts to a paid charge, a failed or partial payment can create a recoverable revenue opportunity. A Salvage Transaction helps the business preserve that opportunity instead of losing the trial conversion immediately. Trial expiration Salvage Transactions can support: - Trial-to-paid recovery. - Follow-up email workflows. - AI Assistant decisioning. - Delayed payment retry. - Customer support review. - Reporting on trial conversion recovery. For trial-based ecommerce businesses, this can make Salvage Transactions a key part of monetizing trial users. ## Relationship to Payment Profiles Payment Profiles are the routing logic that decide how credit-card payments are processed. A Payment Profile may choose a Gateway, process a payment, respond to a decline, reduce the amount, route through another Gateway, run a Function, or stop the payment flow. Salvage Transactions are connected to Payment Profiles because the original payment behavior comes from the Payment Profile flow. For example: ```text Payment Profile starts ↓ Payment request enters flow ↓ Gateway is chosen ↓ Payment is attempted ↓ Payment declines or partially succeeds ↓ Recoverable amount remains ↓ Salvage Transaction is created ``` The Payment Profile explains why the Salvage Transaction exists. It provides routing context, decline-handling context, amount-modification context, and sometimes Function or metadata context. ## AI Assistant Limitation for Payment Profiles AI Assistants can retrieve Payment Profiles for analysis, troubleshooting, revenue recovery context, and declaring existing payment routing. AI Assistants cannot create or modify Payment Profiles. This matters when building AI recovery workflows. An AI Assistant may inspect or reference the Payment Profile that produced a Salvage Transaction, but it should not attempt to change the Payment Profile flow. Payment Profile creation and modification should remain deliberate configuration work handled through the appropriate API, MCP, or web app workflows with human review. ## Relationship to Gateways A Gateway is the configured payment-processing connection used to attempt credit-card charges. A Salvage Transaction can carry Gateway context from the original payment attempt and can also be processed later, potentially using the original Gateway or a specific Gateway chosen for recovery. Gateway context matters because the business may want to understand: - Which Gateway produced the original failed or partial payment. - Which Gateway was used for a recovery attempt. - Whether certain Gateways produce more salvage opportunities. - Whether certain Gateways recover salvage more successfully. - Whether a different Gateway should be tried during recovery. A Gateway is a feature. A Salvage Transaction is the item that records a recoverable outcome connected to that payment-processing path. ## Relationship to Transactions Transactions are the credit-card payment attempt records. A Salvage Transaction is connected to Transactions because it comes from a transaction outcome and can later produce another transaction when recovery is attempted. Typical relationship: ```text Original Transaction declines or partially succeeds ↓ Salvage Transaction is created ↓ Recovery attempt is processed ↓ New Transaction records the recovery attempt ``` If recovery succeeds, the successful recovery transaction can become the transaction that confirms the Salvage Transaction was salvaged. This distinction helps crawlers and AI systems understand the roles: - Transaction = individual payment attempt outcome. - Salvage Transaction = recoverable balance item created from a payment outcome. - Payment Profile = routing flow that led to the outcome. - Gateway = processing connection used for the attempt. ## Manual Processing The Knowledge Base describes manual processing as one way to process a Salvage Transaction. A user can review Salvage Transactions in the RevCent web app and process a salvage item when appropriate. Manual processing is useful when: - The salvage amount is high. - Support has spoken with the customer. - The customer requested a retry. - A customer provided a different payment method. - The user wants to choose a specific Gateway. - The item needs human review before another payment attempt. Manual processing should still be intentional. A Salvage Transaction is a payment recovery opportunity, not a signal to retry endlessly. ## Automated Processing The Knowledge Base states that Salvage Transactions can be processed automatically using an AI Assistant. The MCP overview expands this into a broader set of recovery patterns: - AI Assistant triggered by Salvage Transaction creation. - Manual processing through the web app or MCP/API. - Custom external workflow using the process operation. - AI Voice Agent or support-assisted recovery. Automation should use rules and guardrails. It should not retry every Salvage Transaction immediately without checking context. ## Wait Before Retrying A best practice for Salvage Transactions is to wait before retrying, unless the customer explicitly authorizes an immediate retry or provides a new payment method. Waiting can help because the original decline may have been temporary. Examples: - Insufficient funds may resolve after payday. - Card limits may reset. - Bank holds may clear. - Temporary issuer conditions may change. - The customer may update the payment method. A sensible recovery workflow is: ```text Salvage Transaction created ↓ Wait according to business policy ↓ Re-check the Salvage Transaction ↓ Retry only if still eligible and authorized ``` The wait period should be determined by the business. AI and external systems should not hard-code one universal retry delay across every account, product, or decline type. ## Re-Check Before Processing Before a Salvage Transaction is processed, the workflow should retrieve and inspect the current item. Important checks include: - Whether it has already been salvaged. - Whether the amount to salvage is still correct. - Whether it has been replaced by another Salvage Transaction. - Whether the customer is eligible for retry. - Whether related subscription or trial state still supports retry. - Whether retry count is within business limits. - Whether the latest transaction or retry result changes the strategy. - Whether metadata indicates prior contact, suppression, or recovery action. - Whether the selected Gateway and customer card strategy are intentional. This is especially important after a wait period, because the status may have changed since creation. ## AI Assistant Recovery AI Assistants can be used for Salvage Transaction recovery workflows. An AI Assistant can be triggered by a Salvage Transaction event, inspect the item, branch based on amount or source type, wait before retrying, send emails, create notes, insert metadata, trigger Functions, or call recovery operations when explicitly configured and authorized. Good AI Assistant salvage workflows usually include: - Filters to avoid unnecessary AI runs. - A delay before processing. - A re-check after the delay. - A maximum number of runs per item. - Retry limits. - Clear instructions about when not to process. - Metadata or notes to record the decision and outcome. - BigQuery analysis to measure recovery performance. AI Assistants should not blindly retry every salvage item. They should use business policy, item context, customer context, amount, retry history, and related payment state. ## AI Voice Agent Recovery AI Voice Agents can support Salvage Transaction recovery when a phone conversation may help. For example, an AI Voice Agent may call a customer after a wait period to help resolve a failed renewal, trial expiration, or remaining balance, depending on the business's communication rules and the customer's consent/eligibility. AI Voice Agent recovery is most useful when: - The salvage amount is meaningful. - The customer may need help updating a card. - Subscription retention is important. - Trial conversion is important. - The business wants a support-style recovery touchpoint. An AI Voice Agent should not pressure the customer. It should explain the reason for the call, respect opt-outs, verify identity where needed, and only attempt payment when the customer clearly authorizes it. ## External Recovery Workflows A custom external system can participate in salvage recovery by receiving a RevCent event, storing the Salvage Transaction ID, waiting according to policy, re-checking the item, and processing the salvage only when eligible. A good external workflow is event-driven. ```text Salvage Transaction created ↓ RevCent Function notifies external system ↓ External system stores salvage_transaction_id ↓ External system waits according to business rules ↓ External system retrieves current Salvage Transaction ↓ External system processes only if still eligible ``` External systems should not poll list endpoints to discover new Salvage Transactions. Event-driven notification is cleaner, safer, and more reliable. ## Relationship to Functions Functions can support Salvage Transaction workflows in several ways. They can notify external systems when a Salvage Transaction is created, evaluate custom eligibility rules, enrich recovery context, or connect RevCent salvage activity to a CRM, support system, or custom billing workflow. Function use cases include: - Sending a webhook to an external recovery platform. - Checking an external CRM for suppression rules. - Looking up custom customer risk or value data. - Logging salvage creation to an internal system. - Returning eligibility context to an AI Assistant. Functions should not be used to create uncontrolled retry loops. Payment recovery logic should be bounded, observable, and aligned with business rules. ## Relationship to Email Templates Salvage Transactions can be part of email recovery workflows. An ecommerce business may send an email after a failed renewal, failed trial expiration, or remaining initial-sale balance. The email can ask the customer to update payment information, contact support, or complete recovery through a supported process. Email communication should match the source of the Salvage Transaction. For example: - Subscription renewal salvage email: explain that a recurring payment could not be completed. - Trial expiration salvage email: explain that a trial conversion payment could not be completed. - Partial initial sale salvage email: explain that part of the payment was captured and a remaining balance still needs attention. ## Relationship to Metadata Metadata is useful for tracking salvage decisions, recovery attempts, and workflow outcomes. Examples of useful metadata include: ```text salvage_recovery_strategy = delayed_retry salvage_recovery_delay_days = 3 salvage_recovery_source = ai_assistant salvage_recovery_outcome = recovered salvage_recovery_outcome = customer_contacted salvage_recovery_outcome = skipped_customer_blocked salvage_manual_review_required = true ``` Metadata helps AI, support teams, external systems, and reporting workflows understand what happened and avoid duplicate or contradictory recovery actions. ## Relationship to BigQuery in RevCent The `salvage_transaction` BigQuery table allows businesses to analyze Salvage Transaction activity over time. Use BigQuery for reporting, metrics, aggregations, and broad analysis. Operational list endpoints should not be used for analytics or bulk reporting. BigQuery can help answer questions such as: - How much revenue is currently available to salvage? - How much salvage revenue was recovered this month? - Which Gateways create the most salvage opportunities? - Which Gateways recover salvage most successfully? - Which Payment Profiles produce the most recoverable declined revenue? - Which campaigns produce the most Salvage Transactions? - How many retries are needed before recovery succeeds? - How does recovery differ between initial sales, subscription renewals, and trial expirations? - Which AI Assistant workflows recover the most revenue? - Which customer segments produce the most recoverable amount? Because the table is item-level, it can be joined conceptually with related customer, transaction, sale, subscription, trial, campaign, Gateway, Payment Profile, AI Assistant, and metadata data. ## Reporting Use Cases Salvage Transaction reporting is valuable for revenue optimization. Useful reporting themes include: ### Recovery Rate Measure how many Salvage Transactions are eventually salvaged compared to how many are created. ### Amount to Salvage Measure total open recoverable balance over time. ### Revenue Recovered Measure how much revenue was actually recovered through salvage processing. ### Recovery by Gateway Compare original Gateway and recovery Gateway performance. ### Recovery by Payment Profile Identify which Payment Profiles create more recoverable balances and which flows produce better recovery outcomes. ### Source Type Analysis Separate initial-sale remaining balances, subscription renewal salvage, and trial expiration salvage. ### AI Recovery Performance Measure which AI Assistant or AI Voice Agent workflows lead to better recovery outcomes. ### Retry Timing Analyze whether waiting one day, three days, seven days, or another interval produces better recovery results. ## Salvage Transactions and Revenue Recovery Strategy Salvage Transactions are not just failed-payment records. They are revenue recovery opportunities. A good salvage strategy answers: - Which Salvage Transactions should be retried automatically? - Which should be reviewed manually? - Which should trigger customer communication? - Which should be skipped because the customer is blocked, inactive, or ineligible? - How long should the business wait before retrying? - How many retries are allowed? - Which Gateway should be used for retry? - Should the customer be asked for a new card? - Should AI or a human decide the recovery path? - How should outcomes be stored in metadata and analyzed in BigQuery? ## Common Ecommerce Use Cases ### Partial Initial Sale Recovery A customer attempts a purchase. The full amount declines, but the Payment Profile captures a lower amount. RevCent creates a Salvage Transaction for the remaining balance. ### Subscription Renewal Recovery A recurring renewal fails. A Salvage Transaction preserves the expected renewal revenue so the business can retry later or contact the customer. ### Trial Expiration Recovery A trial expires and the conversion charge fails. A Salvage Transaction gives the business a second chance to recover trial-to-paid revenue. ### High-Value Manual Review A large Salvage Transaction is created. Instead of retrying automatically, AI or business rules mark it for human review. ### Delayed AI Retry An AI Assistant waits three days, re-checks the Salvage Transaction, and processes it only if it is still eligible. ### Customer Card Update Recovery A customer provides a new card. Support or an approved workflow processes the Salvage Transaction using the updated payment method. ## Guardrails Salvage Transaction recovery should be controlled. Important guardrails: - Do not retry already-salvaged items. - Do not ignore replacement fields. - Do not retry endlessly. - Do not retry immediately unless authorized or policy allows it. - Do not confuse fully declined initial sales with Salvage Transactions. - Do not ask customers for full card details in insecure contexts. - Do not guess Gateway IDs or customer card IDs. - Do not process without reviewing eligibility. - Do not use operational list endpoints for reporting. - Do not allow AI workflows to run without retry limits and max-runs-per-item controls. - Do not use AI Assistants to create or modify Payment Profiles. ## Why This Matters in the RevCent Ecosystem Salvage Transactions connect payment processing, customer recovery, automation, and reporting. They sit at the intersection of: - Payment Profiles. - Gateways. - Transactions. - Customers. - Customer cards. - Sales. - Subscriptions. - Trials. - AI Assistants. - AI Voice Agents. - Functions. - Email Templates. - BigQuery in RevCent. For crawlers and planning systems, the key idea is that Salvage Transactions are item-level recovery records. They are not the same as Payment Profiles, Gateways, or Transactions, but they depend on all three to explain why the recoverable balance exists and how it can be recovered. ## Best-Fit Businesses Salvage Transactions are especially useful for businesses that have: - Subscription products. - Trial offers. - High-volume ecommerce checkout. - Multiple Gateways. - Advanced Payment Profiles. - Partial-payment recovery strategies. - AI-driven revenue recovery. - Customer support recovery workflows. - External CRM or billing recovery systems. - A need to analyze declined and recovered revenue. ## Summary Salvage Transactions are RevCent items that preserve recoverable credit-card revenue after certain failed or partial payment outcomes. They help ecommerce businesses recover money that might otherwise be lost, especially from subscription renewals, trial expirations, and partial initial-sale captures. They are created from payment outcomes connected to Payment Profiles and Gateways, and they can be recovered manually, by AI Assistants, by support workflows, or by custom external systems. Use BigQuery in RevCent to measure salvage performance, recovery rates, Gateway behavior, Payment Profile impact, and AI recovery outcomes. The simplest way to understand them is: ```text A Transaction records a payment attempt. A Payment Profile decides how payment should route. A Gateway processes the charge. A Salvage Transaction preserves the remaining recoverable revenue when that payment path leaves money still worth recovering. ``` --- Document Parent Directory * [Items](https://revcent.com/documentation/markdown/ecosystem/item/index.md) - Non-technical markdown documentation for items within the RevCent ecosystem. An item is an entity that is spawned as a result of a feature or operation conducted within the RevCent ecosystem.