--- title: "Pending Refunds" description: "A non-technical ecosystem overview of Pending Refunds, also known as Refunds, in RevCent, focused on why refunds are called pending, how processor settlement can affect refund timing, how RevCent tracks refunds across payment types, and how Pending Refunds connect Sales, Product Sales, Shipping, Tax, Subscription Renewals, Transactions, PayPal Transactions, Offline Payments, support, accounting, automation, and BigQuery reporting across the RevCent relationship graph." type: "item" company: "RevCent" canonical: "https://revcent.com/documentation/markdown/ecosystem/item/PendingRefund.md" relationships: - name: "Sale" url: "https://revcent.com/documentation/markdown/ecosystem/item/Sale.md" - name: "Product Sale" url: "https://revcent.com/documentation/markdown/ecosystem/item/ProductSale.md" - name: "Shipping" url: "https://revcent.com/documentation/markdown/ecosystem/item/Shipping.md" - name: "Tax" url: "https://revcent.com/documentation/markdown/ecosystem/item/Tax.md" - name: "Subscription Renewal" url: "https://revcent.com/documentation/markdown/ecosystem/item/SubscriptionRenewal.md" - name: "Transaction" url: "https://revcent.com/documentation/markdown/ecosystem/item/Transaction.md" - name: "PayPal Transaction" url: "https://revcent.com/documentation/markdown/ecosystem/item/PayPalTransaction.md" - name: "Offline Payment" url: "https://revcent.com/documentation/markdown/ecosystem/item/OfflinePayment.md" technical_links: web_app: "https://kb.revcent.com/en/payments/pending-refund" api: section: "https://revcent.com/docs/api/v2#section-pending_refunds" operations: - name: "Get Pending Refunds" operation_id: "GetPendingRefunds" operation: "https://revcent.com/docs/api/v2#operation-GetPendingRefunds" schema: "https://revcent.com/documentation/files/api/operation/GetPendingRefunds.json" - name: "Get A Pending Refund" operation_id: "GetPendingRefund" operation: "https://revcent.com/docs/api/v2#operation-GetPendingRefund" schema: "https://revcent.com/documentation/files/api/operation/GetPendingRefund.json" - name: "Search Pending Refunds" operation_id: "SearchPendingRefunds" operation: "https://revcent.com/docs/api/v2#operation-SearchPendingRefunds" schema: "https://revcent.com/documentation/files/api/operation/SearchPendingRefunds.json" mcp: overview: "https://revcent.com/documentation/markdown/mcp/operation/OverviewPendingRefund.md" operations: - name: "Get Pending Refunds" operation_id: "GetPendingRefunds" markdown: "https://revcent.com/documentation/markdown/mcp/operation/GetPendingRefunds.md" available_via_ai: true - name: "Get A Pending Refund" operation_id: "GetPendingRefund" markdown: "https://revcent.com/documentation/markdown/mcp/operation/GetPendingRefund.md" available_via_ai: true - name: "Search Pending Refunds" operation_id: "SearchPendingRefunds" markdown: "https://revcent.com/documentation/markdown/mcp/operation/SearchPendingRefunds.md" available_via_ai: true bigquery_schema: "https://revcent.com/documentation/files/bigquery/dataset.json" bigquery_tables: - "pending_refund" --- # Pending Refunds Pending Refunds, also known simply as Refunds, are RevCent's refund-tracking items. A Pending Refund is created when a refund is requested or when a larger action, such as voiding a Sale, creates refund activity. It gives RevCent, the business, support teams, accounting teams, AI workflows, and reporting systems a durable record that a refund exists and is connected to specific commerce activity. The word **pending** is important, but it can be misunderstood. In RevCent, a Pending Refund does not automatically mean something is wrong. It means RevCent has created a refund record and is tracking the refund through its lifecycle. In many cases, the refund may be processed immediately. In other cases, RevCent may need to wait for the original payment processor to allow the refund. At the simplest level: ```text Refund requested ↓ RevCent creates a Pending Refund record ↓ Refund may process immediately, or wait until the original processor allows it ↓ Refund status becomes part of the customer, sale, payment, support, accounting, and reporting history ``` For ecosystem graphing, Pending Refunds are important because they connect the refund action back to the original business context: the Sale, product line item, shipping, tax, subscription renewal, transaction, PayPal payment, offline payment, customer, campaign, shop, metadata, and payment processor path. ## Why Pending Refunds Are an Item Pending Refunds are an item because they are created from real refund activity. A business configures Products, Payment Profiles, PayPal Accounts, Shops, Shipping Profiles, Tax, Email Templates, Functions, AI Assistants, and other RevCent features. Those features help determine how commerce is processed. A Pending Refund is what exists after money needs to be returned, or after RevCent needs to record that a refund has been initiated. The distinction is important: ```text Sale = the purchase event Product Sale = the product line item inside the Sale Transaction / PayPal Transaction / Offline Payment = how the money was paid Pending Refund = the refund record connected back to the original commerce context ``` A Pending Refund is not just a payment-processor response. It is a RevCent item that helps preserve the refund's meaning inside the broader ecommerce ecosystem. ## Core Purpose The core purpose of Pending Refunds is to give RevCent a consistent refund-tracking layer across payment methods, processors, and refund sources. This matters because different payment processors behave differently. Some can accept a refund immediately. Others may require the original payment to settle before a refund can be issued. Some refunds may also be recorded as having happened outside RevCent. Pending Refunds allow RevCent to track all of these cases in one consistent way. A Pending Refund helps answer questions such as: - Was a refund requested? - What amount was refunded or scheduled to be refunded? - Which customer is connected to the refund? - Which Sale or payment does the refund belong to? - Was the refund tied to a product, shipping, tax, or subscription renewal? - Was the refund connected to a credit card Transaction, PayPal Transaction, Offline Payment, or other payment path? - Is the refund still processing, complete, or in an error state? - Was the refund handled through RevCent or recorded as refunded offsite? - Which campaign, shop, gateway, PayPal account, support action, or metadata context is connected to the refund? - How should support, finance, operations, and reporting understand the refund? This makes Pending Refunds useful for customer support, accounting, revenue analysis, refund audits, automation, and lifecycle reporting. ## Why They Are Called Pending Pending Refunds are called **pending** because the refund record may exist before the payment processor has completed the refund. Some payment processors do not allow a refund to be issued immediately after the original payment. A common example is a credit card processor that requires the original transaction to settle before it can accept a refund. RevCent handles this by creating the refund record immediately, then processing the actual payment-processor refund when the original processor allows it. Conceptually: ```text Customer refund is requested ↓ RevCent records the refund immediately ↓ Processor may accept the refund now, or require settlement first ↓ RevCent processes or completes the refund based on processor behavior ``` This protects the business from losing track of refund intent just because a processor is not ready to accept the refund yet. ## Pending Does Not Always Mean Delayed The word pending does not mean every refund waits. Many Pending Refunds are processed immediately because the original payment processor allows the refund right away. Other Pending Refunds may wait because the original transaction has not settled, the processor has timing rules, or the refund path depends on the payment method. The practical meaning is: ```text Pending Refund = RevCent refund tracking item Processing time = depends on the original payment processor and payment state ``` This distinction matters for support teams. A customer may ask, "Has my refund been issued?" A support user should understand the difference between: - The refund was requested. - The Pending Refund record exists in RevCent. - The processor-level refund has completed. - The refund may still need time to appear with the customer's bank or payment provider. RevCent gives the business visibility into that refund lifecycle instead of treating the refund as a one-time opaque event. ## Settlement and Processor Timing Payment processors may have settlement rules. A payment may be authorized or captured, but not yet fully settled in the processor's environment. If the processor does not allow immediate refunds before settlement, the refund cannot be completed at the processor level until the processor is ready. RevCent's Pending Refund system accounts for this reality. For credit card payments, this is especially important because some merchant gateways do not allow a newly processed payment to be refunded until enough time has passed for settlement. When settlement timing matters, RevCent can keep the refund in a pending/processing state and automatically handle the refund once it is allowed. For other payment types, such as PayPal, Offline Payments, or Check Direct payments, timing can differ based on how that original payment source works. The benefit is that the business does not need separate mental models for every processor. RevCent uses Pending Refunds as the common refund record. ## Where Pending Refunds Fit in the RevCent Ecosystem Pending Refunds sit after the original purchase or payment activity. They connect back to the item that caused the refund and the payment path used to return or record money. Conceptually: ```text Sale ↓ Product Sales, Shipping, Tax, Subscription Renewals, Payments ↓ Refund requested ↓ Pending Refund ↓ Processor outcome, support history, accounting visibility, and reporting context ``` Pending Refunds can be connected to many parts of RevCent because a refund can happen at different levels of the commerce lifecycle. ## Technical Links | Area | Link | |---|---| | Web App | `https://kb.revcent.com/en/payments/pending-refund` | | API | `https://revcent.com/docs/api/v2#section-pending_refunds` | | MCP | `https://revcent.com/documentation/markdown/mcp/operation/OverviewPendingRefund.md` | | BigQuery Table | `pending_refund` | These links identify where Pending Refunds are documented or represented technically. This ecosystem document stays focused on meaning, purpose, relationships, and business value rather than implementation details. ## Relationship to Sales Sales are the parent purchase events in RevCent. Pending Refunds often trace back to a Sale because refunds usually happen after a customer has purchased something. A full Sale refund may create Pending Refund records for the related parts of the Sale, such as product line items, shipping, and tax. This relationship matters because support and finance teams usually start with the Sale when investigating a refund. For example: ```text Customer asks about a refund ↓ Support finds the Sale ↓ Sale shows related Product Sales, Shipping, Tax, Payments, and Pending Refunds ↓ Support can explain what was refunded and where the refund stands ``` A Sale-level view is useful when the business needs to understand the entire order. A Pending Refund view is useful when the business needs to understand the refund record and its status. ## Full Sale Refunds When a business wants to refund an entire paid Sale, the refund usually belongs at the Sale level. A full Sale refund can affect all refundable parts of the Sale: - Product Sales - Shipping - Tax - Related payment records - Subscription or trial outcomes when applicable This is different from a partial refund. A full Sale refund says: ```text The entire purchase should be reversed or refunded. ``` A partial refund says: ```text Only a specific part of the purchase should be refunded. ``` Pending Refunds help preserve which kind of refund occurred and which items were affected. ## Relationship to Product Sales Product Sales are the line items inside a Sale. A Product Sale refund is useful when the customer should be refunded for a specific product, not the entire Sale. For example, a customer may buy three products but only return one. Refunding the Product Sale helps RevCent preserve product-level refund visibility. Conceptually: ```text Sale with multiple Product Sales ↓ Customer returns one product ↓ Refund is tied to that Product Sale ↓ Pending Refund records the product-specific refund ``` This matters for business reporting because a product-level refund helps answer: - Which products are refunded most often? - Which products drive the most refund volume? - Which products have strong sales but weak net performance after refunds? - Which campaigns or shops are producing product-level refunds? - Which products may have fulfillment, quality, sizing, billing, expectation, or customer satisfaction issues? Product Sale-level refunds are one of the best ways to keep refund reporting accurate at the product level. ## Relationship to Shipping Shipping can be refunded separately from the product itself. A customer may keep the product but receive a shipping refund because of a fulfillment delay, shipping service issue, customer service adjustment, or promotion correction. In that case, the Pending Refund should be connected to Shipping rather than only to the full Sale or Product Sale. Conceptually: ```text Sale includes product and shipping ↓ Only shipping should be refunded ↓ Pending Refund connects to Shipping ``` This is useful because ecommerce businesses often need to understand shipping-specific refunds separately from product refunds. Shipping refund visibility can help answer: - Are shipping refunds increasing? - Which fulfillment paths create the most shipping refunds? - Which shops or campaigns produce more shipping adjustments? - Are customers being refunded because of shipping delays or delivery problems? ## Relationship to Tax Tax can also be refunded separately. A tax refund may occur when a product, shipping amount, or sale amount is adjusted. It may also be part of a larger refund where the tax component needs its own record. Separating tax refunds helps preserve accurate tax and accounting context. Conceptually: ```text Sale includes tax ↓ Refund affects taxable amount or tax itself ↓ Pending Refund connects to Tax ``` This helps businesses understand tax refund activity without confusing it with product revenue or shipping adjustments. ## Relationship to Subscription Renewals Subscription Renewals are recurring billing events that happen after a Subscription begins. A customer may request a refund for a renewal while keeping the original Sale history intact. In that case, the refund belongs to the Subscription Renewal lifecycle rather than the original initial Sale alone. Conceptually: ```text Initial Sale creates Subscription ↓ Subscription Renewal occurs later ↓ Renewal is refunded ↓ Pending Refund connects to the Subscription Renewal ``` This relationship matters for subscription businesses because renewal refunds are different from initial-sale refunds. Renewal refund reporting can help answer: - Which subscription products produce renewal refunds? - Which renewal cycles create customer dissatisfaction? - Which campaigns generate subscriptions that later refund? - Are refunds tied to trial conversions, renewal timing, support issues, or fulfillment issues? Pending Refunds preserve the connection between refund activity and the recurring revenue lifecycle. ## Relationship to Credit Card Transactions Credit card Transactions are payment records created when RevCent processes card payments through merchant gateways. A Pending Refund may be connected to a credit card Transaction when the refund is being issued through the original card payment path. This is where the word **pending** is often most important, because credit card processors may require the original transaction to settle before accepting a refund. Conceptually: ```text Credit card Transaction created ↓ Refund requested ↓ Pending Refund records the refund immediately ↓ Processor refund completes when allowed by the gateway/payment processor ``` This relationship helps support and finance teams understand whether a refund is connected to the original card processor, whether timing is controlled by settlement, and whether the refund has completed at the processor level. ## Relationship to PayPal Transactions PayPal Transactions can also have related Pending Refunds. When a PayPal payment is refunded through RevCent, the Pending Refund helps connect the refund back to the PayPal Transaction and the surrounding Sale context. Conceptually: ```text PayPal Transaction ↓ Refund requested ↓ Pending Refund connects PayPal payment activity to RevCent refund tracking ``` This is useful because PayPal payment activity may have its own processor behavior, dispute lifecycle, and account context. Pending Refunds let PayPal refunds appear in the same RevCent refund ecosystem as card, offline, and check-related refunds. ## Relationship to Offline Payments Offline Payments represent alternate payment activity, including payments not processed through RevCent's standard credit-card gateway flow and payments from supported alternate providers. Pending Refunds can connect to Offline Payments when the refund relates to an offline or alternate payment path. This is important because offline and alternate payment providers may not behave exactly like card processors or PayPal. Some refunds may be tracked in RevCent while money movement happens through an external provider or manual process. Conceptually: ```text Offline or alternate payment recorded ↓ Refund is needed ↓ Pending Refund provides RevCent refund visibility even when the original payment path is external or alternate ``` This helps businesses keep refund history unified even when not every payment type behaves the same way. ## Relationship to Customers Every refund ultimately matters because of the customer relationship. Pending Refunds help customer support understand whether a customer has a refund in progress, completed, errored, or recorded offsite. This supports better customer communication. Instead of saying only: ```text We will refund you. ``` Support can understand and communicate the lifecycle more clearly: ```text The refund has been initiated in RevCent. Depending on the original payment processor, it may process immediately or after the processor allows the refund. Once processed, the time it takes to appear to the customer may also depend on the bank or payment provider. ``` This avoids overpromising and gives support teams a more accurate view of the refund's status. ## Relationship to Campaigns and Shops Pending Refunds can also be connected to campaigns and shops. This is important for ecommerce businesses because refund activity is not only a support issue. It can reveal business patterns. Campaign and shop context can help answer: - Which campaigns produce the most refunds? - Which shops have higher refund volume? - Are certain offers generating more partial refunds? - Are refunds tied to a specific storefront, funnel, product line, or traffic source? - Are certain payment types or processors creating more refund delays? This makes Pending Refunds useful for more than customer support. They also help with marketing, operations, finance, and revenue analysis. ## Relationship to Metadata Metadata can add business-specific context to refund activity. For example, a business might use metadata to track a refund reason, support workflow, customer communication outcome, promotion correction, return authorization, external refund reference, or special handling note. Metadata makes refund records more useful across the RevCent ecosystem because it can connect refund activity to the business's own operating language. Conceptually: ```text Pending Refund ↓ Metadata adds business-specific meaning ↓ Support, reporting, AI, and finance can understand why the refund happened ``` ## Relationship to AI Assistants and AI Voice Agents Pending Refunds can be part of AI-powered workflows. An AI Assistant may help analyze refund patterns, create notes, insert metadata, notify support, or identify older unprocessed refunds that need review. An AI Voice Agent may help explain refund status to a customer during a support or recovery call when configured to do so. Possible AI-related refund use cases include: - Summarizing a customer's refund history. - Explaining whether a refund is pending, complete, or errored. - Creating a support note after a refund conversation. - Adding metadata to indicate a refund reason or customer outcome. - Alerting staff when pending refund volume increases. - Finding refund patterns by campaign, product, shop, or payment type. - Helping support teams understand which original Sale or payment record caused a refund. Refund actions are financial actions, so AI workflows should only initiate or modify refund-related activity when they are intentionally configured with appropriate permissions, business rules, and safeguards. ## Relationship to Functions Functions can support refund-related workflows when the business needs custom automation. Examples include: - Notify a support team when a refund enters an error state. - Send refund information to an external accounting system. - Tag a refund with metadata based on business rules. - Alert operations when shipping refunds exceed an expected threshold. - Connect offsite refund records to an external provider reference. - Trigger an internal workflow when a high-value refund is created. In the ecosystem graph, Functions are not the refund itself. They are automation that can respond to refund activity or enrich refund context. ## Relationship to Email Templates Pending Refunds can also matter for customer communication. A business may want to send emails related to refund initiation, refund completion, support follow-up, return instructions, or refund exceptions. Email Templates can help standardize customer-facing communication around refund events and related lifecycle activity. This is useful because refund communication must be clear and careful. Customers often care about whether the refund was requested, whether it has processed, and when they should expect to see the money. A good refund communication should avoid overpromising. It should distinguish between: ```text Refund initiated in RevCent Refund processed by the payment provider Refund visible to the customer through their bank or provider ``` ## Refund Status Pending Refunds can move through different statuses. Common business-level statuses include: | Status | Meaning | |---|---| | Processing | RevCent has the refund record and the refund is still being processed or waiting for processor requirements. | | Complete | The refund has completed at the processor level or has otherwise reached its completed refund state. | | Error | RevCent attempted the refund path, but something went wrong and the refund may need review. | Status is important because it tells the business whether a refund exists, whether it completed, or whether a support/operations review may be needed. ## Refunds Cannot Be Treated Casually Refunds are consequential financial records. Once a Pending Refund has been created in RevCent, it should be treated as a serious accounting and customer-support item. The KB guidance notes that a created Pending Refund cannot simply be cancelled, disabled, or reversed. This matters because a refund record can affect: - Customer expectations. - Revenue reporting. - Product-level refund metrics. - Accounting workflows. - Payment processor activity. - Support communication. - Subscription and trial lifecycle understanding. - Chargeback and dispute prevention. For this reason, refund actions should be intentional and tied to the correct item. ## Choosing the Right Refund Level The level where a refund is created matters. If the entire Sale should be refunded, the refund belongs at the Sale level. If only one product should be refunded, the refund belongs at the Product Sale level. If only shipping or tax should be refunded, the refund belongs to Shipping or Tax. If a recurring billing event should be refunded, the refund belongs to the Subscription Renewal. If the business wants to refund the payment directly, the refund may connect to a Transaction or PayPal Transaction. Conceptually: ```text Refund the whole order → Sale Refund one product → Product Sale Refund shipping only → Shipping Refund tax only → Tax Refund a recurring charge → Subscription Renewal Refund a card payment directly → Transaction Refund a PayPal payment directly → PayPal Transaction Record or track alternate payment refund → Offline Payment / related entities ``` Choosing the right level improves reporting. For example, if a customer returns one product from a multi-product order, refunding the Product Sale gives the business better product-level refund visibility than only treating the refund as an order-level adjustment. ## Pending Refunds and Partial Refunds Pending Refunds are especially useful for partial refunds. Partial refunds are common in ecommerce: - A customer returns one product from a larger order. - A customer receives a partial goodwill adjustment. - Shipping is refunded because delivery was delayed. - Tax needs to be adjusted. - A subscription renewal is partially refunded. - A payment is partially refunded through the original processor. Partial refunds are not just smaller full refunds. They often need more precise relationship context so reporting stays meaningful. For example: ```text Sale total includes product + shipping + tax ↓ Only shipping is refunded ↓ Pending Refund should connect to Shipping so reports show shipping refund activity accurately ``` This is why RevCent's itemized refund relationships are valuable. ## Pending Refunds and Full Refunds Full refunds are different. A full Sale refund usually means the entire purchase should be reversed or refunded. In that case, RevCent may create refund records connected to all applicable refundable parts of the Sale. This can include product line items, shipping, tax, and payment records. The business benefit is that the full refund can still preserve detailed item-level history instead of hiding all refund activity inside a single vague order adjustment. ## Pending Refunds and Payment Types Pending Refunds provide a common refund layer across different payment types. Refunds may relate to: - Credit card payments. - PayPal payments. - Offline or alternate payments. - Check direct payments. Each payment type may have different timing, settlement, and processor behavior. RevCent's Pending Refund item makes those differences easier to manage by giving the business one refund record type that can connect back to the appropriate payment path. ## Pending Refunds and Refunded Offsite Activity Sometimes a refund is handled outside RevCent. Examples may include: - Refund handled directly inside PayPal. - Manual refund from another processor dashboard. - Mailed check. - Bank adjustment. - External payment provider refund. - Rapid dispute or external resolution process. In these cases, RevCent may need to record the refund for customer history, accounting, and reporting even though RevCent did not send the money through the payment processor itself. This is important because the business still needs the refund reflected in RevCent's ecosystem. Conceptually: ```text Refund happened outside RevCent ↓ RevCent records the refund context ↓ Customer history, Sale history, product metrics, and reporting stay accurate ``` ## Pending Refunds and Accounting Pending Refunds are valuable for accounting because they show the timing gap between refund intent and refund completion. Accounting teams may need to understand: - When a refund was requested. - Whether the refund has completed. - Which payment type was involved. - Whether it was handled offsite. - Which customer, campaign, shop, Sale, product, shipping, tax, renewal, or payment record was affected. - Whether the refund should be reconciled against processor reports. - Whether a refund is still waiting because of settlement or processor rules. This makes Pending Refunds useful for reconciliation and audit trails. ## Pending Refunds and Customer Support Pending Refunds give support teams a concrete item to reference when helping customers. Support can use Pending Refunds to understand: - Whether a refund was initiated. - Whether it is still processing. - Whether it completed. - Whether it errored. - Which item or payment was refunded. - Whether processor timing may explain a delay. - Whether the refund was recorded offsite. This improves customer conversations because support does not have to guess. A good customer-facing explanation is: ```text The refund has been initiated in RevCent. Some processors process refunds immediately, while others require the original payment to settle first. RevCent tracks the refund and processes it according to the original processor's rules. ``` ## Pending Refunds and Revenue Quality Refunds are not only negative events. They are signals. Pending Refunds can help a business understand revenue quality. Refund activity may reveal: - Product expectation issues. - Shipping delays. - Billing confusion. - Trial or subscription cancellation friction. - Campaigns attracting lower-quality buyers. - Shops or funnels producing more refunds. - Payment methods with more refund delay. - Customer service patterns. - Chargeback-prevention opportunities. In this way, Pending Refunds help ecommerce businesses improve operations, not just track money returned. ## BigQuery Reporting Context The `pending_refund` BigQuery table is useful for reporting and relationship visibility. For ecosystem graphing, the table helps show that Pending Refunds can connect to many other RevCent items, including Sales, Product Sales, Shipping, Tax, Subscription Renewals, Transactions, PayPal Transactions, Offline Payments, Customers, Campaigns, Gateways, PayPal Accounts, Shops, Metadata, and API/automation context. At a business level, BigQuery can help answer questions such as: - How much refund volume is pending or completed? - Which products generate the most refunds? - Which campaigns or shops have higher refund rates? - Which payment types produce more refund delay? - Which refunds are related to shipping, tax, or subscription renewals? - Which refunds were recorded offsite? - How many refunds are still processing? - Which customers have repeated refunds? - Are refund trends changing over time? - Are certain processors or payment paths slower to complete refunds? This document does not list the full table schema or example queries. The table is referenced here as a reporting and relationship source for understanding how Pending Refunds fit into the RevCent ecosystem. ## Relationship Graph A Pending Refund can be thought of as a refund node connected to the original commerce context. ```text Pending Refund ├─ Sale ├─ Product Sale ├─ Shipping ├─ Tax ├─ Subscription Renewal ├─ Transaction ├─ PayPal Transaction ├─ Offline Payment ├─ Customer ├─ Campaign ├─ Shop ├─ Gateway or PayPal Account context ├─ Metadata ├─ API / MCP / AI / Function context when applicable └─ BigQuery reporting ``` This is why Pending Refunds are important for relationship graphing. They do not exist alone. They explain how money returned to the customer relates back to the original purchase, payment, product, fulfillment, tax, subscription, support, and reporting context. ## Common Business Questions Pending Refunds Help Answer Pending Refunds help answer practical ecommerce questions: - What refunds have been created? - Which refunds are still processing? - Which refunds completed? - Which refunds errored? - Why is a customer still waiting? - Was this refund tied to one product or the entire Sale? - Was the refund related to shipping or tax? - Did this refund come from a subscription renewal? - Was the original payment credit card, PayPal, offline, or check direct? - Was the refund handled inside RevCent or offsite? - Which campaign, shop, product, or payment path is producing refunds? - Are refund delays processor-related? - Are refunds increasing for a certain product or offer? These are the kinds of questions that make Pending Refunds valuable beyond the refund action itself. ## Benefits for Ecommerce Businesses Pending Refunds give ecommerce businesses several benefits: ### Better Support Visibility Support teams can see that a refund exists and whether it is still processing, completed, or errored. ### Cleaner Refund Attribution Refunds can be connected to the correct item, such as a Product Sale, Shipping, Tax, Subscription Renewal, Transaction, PayPal Transaction, or Offline Payment. ### More Accurate Reporting Refunds can be reported by product, campaign, shop, payment type, customer, processor, or refund reason when metadata is used. ### Processor-Timing Protection If a processor does not allow immediate refunds, RevCent still records the refund and can complete it when allowed. ### Better Customer Communication Support can explain refund timing without guessing or overpromising. ### Improved Accounting Context Finance teams can reconcile requested refunds, completed refunds, offsite refunds, and processor-level outcomes. ### Stronger Operations Refund patterns can reveal operational issues with products, shipping, offers, processors, subscriptions, or customer expectations. ## Best Practices - Treat Pending Refunds as serious financial records. - Choose the correct refund level: Sale, Product Sale, Shipping, Tax, Subscription Renewal, Transaction, PayPal Transaction, or Offline Payment. - Use Product Sale-level refunds when the refund is tied to a specific product. - Use Shipping or Tax-level refunds when only those components are being adjusted. - Use full Sale refunds when the entire purchase should be reversed. - Do not assume a pending refund means failure; it may simply be waiting on processor settlement or timing rules. - Do not promise that money has already reached the customer unless the refund status supports that conclusion. - Preserve metadata and reason context when the business needs better reporting. - Use BigQuery for refund reporting, trends, and relationship analysis. - Use Pending Refund relationships to understand the original commerce context before explaining or analyzing a refund. ## Common Misunderstandings ### Pending Means Failed Pending does not necessarily mean failed. A Pending Refund may simply be waiting for the original processor to allow the refund or may be in the middle of normal processing. ### Refund Requested Means Money Already Returned A refund request and a completed processor refund are not always the same moment. RevCent may record the refund immediately while the payment processor completes it according to its own rules. ### All Refunds Behave the Same Refund timing depends on the original payment processor and payment type. Credit card, PayPal, Offline Payment, and Check Direct refund paths may behave differently. ### Order-Level Refunds Are Always Best Not always. If only one product, shipping charge, tax amount, or subscription renewal should be refunded, item-level refunding gives the business better reporting and cleaner history. ### Offsite Refunds Are Processor Refunds Through RevCent An offsite refund means the refund was handled outside RevCent and recorded in RevCent for visibility, customer history, and reporting consistency. ## Summary Pending Refunds are RevCent's refund-tracking items. They are called pending because RevCent records the refund immediately, while the actual processor-level refund may complete immediately or later depending on the original payment processor, settlement rules, payment type, and refund workflow. Pending Refunds are valuable because they connect refund activity back to the real ecommerce context: ```text Customer ↓ Sale ↓ Product Sales, Shipping, Tax, Subscription Renewals, Transactions, PayPal Transactions, Offline Payments ↓ Pending Refunds ↓ Support, accounting, automation, and reporting ``` For ecommerce businesses, Pending Refunds make refunds easier to track, explain, reconcile, audit, and analyze. They also preserve the relationships needed to understand which products, campaigns, shops, payment types, processors, customers, and operational workflows are connected to refund activity. --- 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.