# RevCent Offline Payment Method Overview This document explains Offline Payments in RevCent at a broad level: what they are, how they work, how they can represent third-party payment sources, what data RevCent stores for them, and why they are useful for ecommerce businesses. This is not a single operation guide. It is an overview of Offline Payments as a RevCent payment method and record type. Sources: - RevCent operation schema for `GetOfflinePayment` - RevCent operation schema for `GetOfflinePayments` - RevCent operation schema guidance for `BigQueryRunQuery` --- # What Is an Offline Payment in RevCent? An Offline Payment is a RevCent payment record used when payment is completed outside the normal credit-card transaction flow. In a normal credit-card payment, RevCent processes a card transaction through a gateway. In an Offline Payment, the payment source may be external, alternate, manual, or not represented by a RevCent credit-card transaction. Conceptually: ```text Customer purchases or pays through a non-credit-card / external method ↓ RevCent records the sale/payment as an offline payment ↓ The offline payment is associated with a customer, sale, campaign, shop, metadata, and/or third-party integration ↓ The business can retrieve, search, filter, report, and analyze the offline payment later ``` Offline Payments allow RevCent to support ecommerce payment flows beyond direct card processing. --- # Why Offline Payments Matter Ecommerce businesses often accept payment methods that do not behave like standard credit-card gateway transactions. Examples: ```text Buy Now Pay Later providers Manual payments External payment processors Third-party shops Alternative payment networks Invoice-based payment flows Payment methods completed outside RevCent's direct card gateway flow ``` Offline Payments allow these payments to still be represented inside RevCent so they can be connected to: ```text Customers Sales Campaigns Shops Metadata Products Shipping Invoices Note: offline payments may have contextual relationships with subscription-related records, but offline payments are not subscription-capable. Only credit card sales/payments support RevCent subscription billing. Discounts Taxes BigQuery reporting Customer history ``` This makes RevCent more complete as a customer, order, and revenue system. --- # Third-Party Payment Sources Offline Payments are especially useful for third-party payment sources. Examples include: ```text Sezzle Klarna Affirm Afterpay Amazon Pay Other Buy Now Pay Later providers External checkout/payment providers Third-party shop payment systems Other alternate payment providers ``` The `GetOfflinePayment` and `GetOfflinePayments` response schemas include a `third_party_integration` object, described as information about the offline payment when associated with a third party such as AfterPay, Sezzle, and similar providers. That object can include: ```text id name third_party.id third_party.name ``` This gives RevCent a way to show that an offline payment is associated with a configured third-party integration. Example conceptual object: ```json { "third_party_integration": { "id": "USER_THIRD_PARTY_ID", "name": "Sezzle Main Account", "third_party": { "id": "SYSTEM_THIRD_PARTY_ID", "name": "sezzle" } } } ``` This is useful because the business can track which external provider was responsible for the payment. --- --- # Supported Third-Party Offline Payment Integrations RevCent supports native third-party integrations for offline payment processing. The supported `offline_payment` site third-party integrations currently include: | Third Party | Integration Type | Credential Fields / Options | |---|---|---| | Affirm | `offline_payment` | Public API Key, Private API Key | | Afterpay | `offline_payment` | Merchant ID, Secret Key | | Amazon Pay | `offline_payment` | Merchant ID, Public Key, Private Key; Region option: `us`, `eu`, or `jp` | | Klarna | `offline_payment` | API Username, API Password | | Sezzle | `offline_payment` | Public Key, Private Key | These are site third-party integrations, meaning RevCent natively knows how to connect to these providers once the user creates and configures their own user third-party integration with the required credentials. Conceptually: ```text Site Third Party Integration = RevCent-supported provider type. User Third Party Integration = the user's configured account/credentials for that provider. ``` --- ## Why Native Third-Party Offline Payment Integrations Matter Offline Payments from supported third-party providers are directly integrated between the provider and RevCent. This is different from simply writing down that a customer paid somewhere else. When the third-party offline payment provider is connected in RevCent: ```text RevCent can connect directly to the provider's API. RevCent can retrieve details about the payment. RevCent can associate payment details with the customer, sale, campaign, shop, metadata, and related items. RevCent can expose the third-party integration context on the offline payment record. RevCent can support refunding the payment from RevCent without requiring the user to log into the third-party provider dashboard. ``` This gives ecommerce businesses a more centralized workflow for alternate payment methods. Instead of managing card payments in RevCent and BNPL/alternate payments only in external dashboards, RevCent can act as the operational hub for supported offline payment providers. --- ## Supported Provider Examples ### Affirm Affirm can be connected as an offline payment integration. Useful for: ```text Buy Now Pay Later checkout. Larger-ticket purchases. Customer financing-style payment options. Alternative payment reporting. ``` ### Afterpay Afterpay can be connected as an offline payment integration. Useful for: ```text Installment-style payment options. BNPL ecommerce checkout. Third-party payment reporting and reconciliation. ``` ### Amazon Pay Amazon Pay can be connected as an offline payment integration. Amazon Pay includes a region option: ```text us eu jp ``` Useful for: ```text Alternative checkout. Amazon Pay customer payment flows. Regional Amazon Pay configuration. ``` ### Klarna Klarna can be connected as an offline payment integration. Useful for: ```text Buy Now Pay Later checkout. Installment-style payment options. Alternate payment reporting. Customer support visibility into Klarna-paid orders. ``` ### Sezzle Sezzle can be connected as an offline payment integration. Useful for: ```text Buy Now Pay Later checkout. Alternative payment flows. Sezzle-specific order/payment visibility in RevCent. ``` --- ## Payment Detail Retrieval Offline payment records can include a `third_party_integration` object. This object helps identify which configured provider/integration is associated with the payment. The object can include: ```text third_party_integration.id third_party_integration.name third_party_integration.third_party.id third_party_integration.third_party.name ``` This allows RevCent users, MCP clients, AI workflows, and reports to understand which third party powered the offline payment. Example conceptual object: ```json { "third_party_integration": { "id": "USER_THIRD_PARTY_INTEGRATION_ID", "name": "Klarna Main Account", "third_party": { "id": "SITE_THIRD_PARTY_INTEGRATION_ID", "name": "Klarna" } } } ``` Because the offline payment is connected to the third-party integration, RevCent can retrieve details about the payment from the provider rather than treating it as a disconnected manual-only record. --- ## Refunds Without Logging Into the Third Party For supported third-party offline payment integrations, RevCent can provide the ability to refund the payment from within RevCent. This matters operationally because ecommerce teams should not need to switch between multiple third-party dashboards just to manage refunds. Conceptually: ```text Customer pays with Klarna / Affirm / Sezzle / Afterpay / Amazon Pay ↓ RevCent records the payment as an offline payment connected to the third-party integration ↓ Support or automation reviews the payment in RevCent ↓ A refund can be initiated through RevCent ↓ RevCent communicates with the third-party provider ``` Business value: ```text Centralized support workflow. Faster refunds. Less provider-dashboard switching. Cleaner reporting. Better customer service. Better operational control over alternate payments. ``` This is one of the key reasons offline payment integrations are more powerful than simply recording external payments manually. --- ## MCP/AI Guidance for Supported Third Parties When helping a user with offline payment third-party providers, MCP/AI should: 1. Use `GetSiteThirdPartyIntegrations` to identify supported integrations where `integration_type = offline_payment`. 2. Present the supported offline payment providers to the user. 3. Explain that the user must configure a user third-party integration with the required credentials. 4. Explain that connected offline payment providers allow RevCent to retrieve payment details. 5. Explain that supported provider payments can be refunded through RevCent rather than requiring the user to log into the provider dashboard. 6. Use `GetOfflinePayment` to retrieve details of a specific offline payment. 7. Use `GetOfflinePayments` for paginated retrieval and filtering. 8. Use `BigQueryRunQuery` for reporting, aggregation, and analytics. 9. Review `third_party_integration`, `third_party_shop`, `metadata`, campaign data, customer data, and related item IDs when analyzing an offline payment. # Offline Payments as an Additional Payment Method Offline Payments make it possible for RevCent to represent payments that were not processed through a RevCent credit-card gateway. This helps ecommerce businesses support more payment options without losing visibility in RevCent. Examples: ```text A customer pays through Klarna. A customer pays through Affirm. A customer pays through Sezzle. A customer pays through AfterPay. A sale is imported from a third-party shop with an external payment source. An order is paid manually outside the normal credit-card gateway flow. ``` Instead of losing the transaction context, RevCent can retain a record of the payment as an Offline Payment. This is valuable because the business still needs to know: ```text Who paid? How much was paid? Which campaign or shop generated the payment? Which third-party payment source was involved? Which sale/product/shipping/subscription records are related? What metadata applies? What was the status? When did it happen? ``` --- # Core Offline Payment Fields Offline Payment detail/list responses expose important business fields. Common fields include: | Field | Meaning | |---|---| | `id` | 20-character offline payment ID. | | `created_date_unix` | When the offline payment record was created. | | `updated_date_unix` | When the offline payment record was last updated. | | `amount` | Offline payment amount. | | `status` | Offline payment status. | | `campaign_id` | Campaign associated with the offline payment. | | `campaign_name` | Campaign name. | | `customer` | Customer object associated with the offline payment. | | `third_party_integration` | Third-party payment provider/integration context if applicable. | | `third_party_shop` | Originating user shop if applicable. | | `metadata` | Metadata name/value pairs associated with the offline payment. | Offline Payment detail responses can also include arrays of related item IDs, such as: ```text sales product_sales shipping tax discounts trials subscriptions subscription_renewals invoices transactions paypal_transactions offline_payments salvage_transactions pending_refunds chargebacks fraud_detections api_calls ``` These related IDs allow MCP/API workflows to retrieve connected records using the relevant `Get...` operations. --- # Customer Context Offline Payments are associated with customer data. The response can include customer details such as: ```text id email first_name last_name phone address_line_1 address_line_2 city state zip country company internal_id enabled blocked metadata created_date_unix updated_date_unix ``` This is important because third-party payment methods should still contribute to customer history. For ecommerce businesses, this means customers who pay through Klarna, Sezzle, Affirm, AfterPay, or other external payment methods can still be part of: ```text Customer purchase history Customer support workflows Customer lifetime value analysis Customer segmentation Customer group logic AI Assistant context AI Voice Agent context BigQuery reporting ``` --- # Campaign and Shop Context Offline Payments can include campaign and shop context. Campaign fields: ```text campaign_id campaign_name ``` Shop field: ```text third_party_shop ``` The `third_party_shop` object can include: ```text id name ``` This is useful for ecommerce businesses that operate: ```text Multiple campaigns Multiple brands Multiple websites Multiple third-party shops Multiple storefronts Multiple checkout sources ``` Example uses: ```text Report Klarna sales by campaign. Compare Affirm payments by shop. Analyze Sezzle usage by website. Understand which campaigns generate the most third-party payment volume. ``` --- # Metadata on Offline Payments Offline Payments can include metadata. Metadata is useful for attaching custom name/value context such as: ```text payment_provider = klarna external_order_id = abc123 checkout_page = version_b affiliate_id = partner_123 shop_order_source = imported_shopify bnpl_plan = pay_in_4 manual_payment_reason = invoice_paid ``` Metadata can support: ```text Search BigQuery reports Customer segmentation External reconciliation AI workflows Support workflows Payment-source analysis ``` Example: ```json { "metadata": [ { "name": "payment_provider", "value": "klarna" }, { "name": "external_order_id", "value": "shop_12345" } ] } ``` --- # Filtering Offline Payments `GetOfflinePayments` supports filters useful for retrieving specific offline payment records. Input filters include: ```text date_start date_end limit page campaign_filter currency_filter shop_filter metadata_filter customer_id ``` This allows MCP/API clients to retrieve offline payments by: ```text Date range Campaign Currency Shop Metadata Customer ``` Examples: ```text Get offline payments for a specific customer. Get offline payments from a specific campaign. Get offline payments from a specific shop. Get offline payments with payment_provider = klarna metadata. Get offline payments within a date range. ``` Important: ```text GetOfflinePayments is for paginated retrieval, not analytics. For counting, aggregations, metrics, data mining, bulk retrieval, or reporting, use BigQueryRunQuery. ``` --- # BigQuery and Offline Payment Reporting For ecommerce analytics, Offline Payments should often be analyzed with `BigQueryRunQuery`. Use BigQuery for questions like: ```text How much revenue came through Klarna this month? How many Sezzle payments were created by campaign? Which shop produced the most Affirm payment volume? What is the average offline payment amount by provider? How many offline payments are associated with each campaign? How many offline payments have subscription-related context? Remember: offline payments are not subscription-capable. How many offline payments came from third-party shops? What customers have the most offline payment volume? ``` Recommended workflow: ```text 1. Use GetBigQueryTables to inspect available table schemas. 2. Identify the offline payment table and relevant related tables. 3. Build BigQuery Standard SQL using fully qualified table references. 4. Use BigQueryRunQuery for counts, sums, grouping, and analysis. ``` BigQuery rules: ```text Use BigQuery Standard SQL. Use fully qualified table references. Wrap table references in backticks. Use GetBigQueryTables before writing queries. Optimize queries to avoid 30-second timeouts. Avoid COALESCE. When using TIMESTAMP_SUB, only use INTERVAL in DAY. ``` --- # Offline Payments vs Credit Card Transactions Offline Payments and credit-card transactions are different record types. | Concept | Meaning | |---|---| | Credit card transaction | Payment processed through a RevCent credit-card gateway/MID. | | Offline payment | Payment represented in RevCent but completed through an external/manual/alternate method. | Credit-card transaction examples: ```text Visa payment through NMI Mastercard payment through Authorize.net Subscription renewal charged through a gateway ``` Offline payment examples: ```text Klarna order Sezzle order Affirm payment AfterPay payment Manual external payment Third-party shop payment source ``` Both can be important parts of customer revenue history. --- # Offline Payments and Third-Party Shops Offline Payments can be associated with a third-party shop. This is useful when sales or payments originate outside RevCent but should still be represented in RevCent. Examples: ```text Third-party ecommerce platform sends order/payment data to RevCent. A shop order is paid through an external payment method. The payment is tracked as an offline payment with the shop as the origin. ``` This helps the business preserve: ```text Shop attribution Customer purchase history Campaign reporting Payment method visibility Fulfillment and product context Support context ``` --- # Offline Payments and Customer Support Support teams benefit from Offline Payments because external payment methods still appear in the customer’s RevCent history. Support users can understand: ```text The customer paid through Klarna/Sezzle/Affirm/AfterPay. The payment amount. The payment status. The related sale or product sale. The originating shop. The campaign context. Any metadata or external reference. ``` This helps when customers ask questions like: ```text I paid with Klarna. Where is my order? I used Affirm. Why does RevCent show this sale? I paid through Sezzle. Can you find my purchase? I ordered through your third-party shop. Is my payment recorded? ``` --- # Offline Payments and Fulfillment Offline Payments may be related to sales, product sales, and shipping records. This matters because external payment methods should still support ecommerce fulfillment workflows. Example: ```text Customer pays through Sezzle. RevCent records the sale/offline payment. Shippable products are connected. Shipping/fulfillment records are created or related. Support and fulfillment teams can track the order. ``` Offline Payments help keep alternate payment methods connected to operational fulfillment. --- --- # Offline Payments Are Not Compatible With Subscription Billing Offline payment methods are not compatible with RevCent subscription billing. Important: ```text Subscriptions and subscription billing in RevCent require credit card sales/payments. Offline payment methods are not subscription-capable. ``` This means offline payment sources such as: ```text Affirm Afterpay Amazon Pay Klarna Sezzle Manual external payments Third-party shop payment sources Other alternate/offline payment methods ``` should not be treated as valid payment methods for recurring subscription billing, subscription renewals, or trial expiration billing. Offline payments are useful for: ```text One-time alternate payment records. Buy Now Pay Later / third-party payment records. Manual or external payment flows. Third-party shop order/payment visibility. Customer support context. Fulfillment and order visibility. Refund handling through associated entities. Offline payment reporting and reconciliation. ``` But they are not a replacement for the credit card payment capability required for subscriptions. --- ## Why This Distinction Matters RevCent subscriptions require a subscription-capable payment method that can support future recurring billing attempts. Offline payment methods represent payments completed through an alternate or external payment source. They may be useful for one-time purchases, third-party payment visibility, and customer/order history, but they do not provide the same recurring billing behavior as credit card payments. Correct guidance: ```text Use credit card sales/payments for subscription-capable billing. Use offline payments for alternate/external payment records and related one-time payment visibility. ``` MCP/AI should not recommend creating or managing a recurring subscription using an offline payment method. --- ## How to Interpret Subscription-Related Offline Payment Data Offline payment records may expose related IDs such as: ```text subscriptions subscription_renewals ``` These should be treated as contextual relationships only. They do not mean that offline payments can bill subscriptions. For example, an offline payment may be associated with customer history or related records that include subscription context, but the offline payment method itself should not be used as the recurring billing source. MCP/AI should explain this clearly when a user asks whether Klarna, Affirm, Sezzle, Afterpay, Amazon Pay, or another offline payment source can be used for subscription billing. --- ## MCP/AI Rule When a user asks about subscriptions and offline payments: ```text Do not state or imply that offline payments are subscription-capable. Do not recommend BNPL/offline payment providers for recurring subscription billing. Explain that only credit card sales/payments are subscription-capable in RevCent. Use offline payments for one-time alternate/external payment visibility, not subscription billing. ``` # Offline Payments and Subscriptions Offline Payments may appear alongside subscription-related context in RevCent records, but they are not compatible with subscription billing. Important: ```text Only credit card sales/payments are subscription capable in RevCent. Offline payments cannot be used as the payment method for recurring subscription billing, subscription renewals, or trial expiration billing. ``` If an offline payment detail response includes related arrays such as: ```text subscriptions subscription_renewals ``` MCP/API workflows may retrieve those related records for context, but should not interpret those relationships as subscription billing support. Correct interpretation: ```text Offline payment record has relationship/context visibility. Credit card payment capability is still required for subscription billing. ``` # Offline Payments and Metadata-Based Analysis Metadata can make Offline Payments much more useful. Examples: ```text payment_provider = klarna bnpl_provider = affirm external_order_id = shop_12345 shop_platform = woocommerce checkout_source = third_party_shop manual_payment_type = invoice ``` These can support BigQuery reports such as: ```text Offline payment amount by provider. Offline payments by shop platform. Offline payment volume by external campaign. Refund/chargeback/support issue rate by payment provider. Customer lifetime value including offline payment sources. ``` --- # Practical Ecommerce Use Cases ## Buy Now Pay Later Support Offline Payments can represent providers such as: ```text Sezzle Klarna Affirm AfterPay ``` Business value: ```text Offer customers more ways to pay while preserving RevCent visibility. ``` ## Third-Party Shop Order Visibility Payments from external shops can still be recorded in RevCent. Business value: ```text Keep customer and order history centralized. ``` ## Manual or External Payment Tracking Offline Payments can represent payments handled outside normal card gateway flow. Business value: ```text Record revenue even when it did not pass through a RevCent credit-card transaction. ``` ## Campaign and Shop Reporting Offline Payments can be tied to campaign/shop context. Business value: ```text Understand which campaigns and storefronts generate alternate payment volume. ``` ## Customer Service Support teams can view alternate payment context on customer-related records. Business value: ```text Faster, more accurate support for customers using external payment methods. ``` ## BigQuery Revenue Reporting Offline Payments can be analyzed with BigQuery. Business value: ```text Report total alternate payment volume, average amount, provider distribution, and customer behavior. ``` --- # Caveats and Best Practices ## 1. Do Not Treat GetOfflinePayments as a Reporting Operation `GetOfflinePayments` is for paginated retrieval. For: ```text Counts Aggregations Metrics Dashboards Bulk analysis Revenue reports Data mining ``` use: ```text BigQueryRunQuery ``` ## 2. Use Metadata Consistently If metadata is used to identify providers or external order IDs, keep names consistent. Good: ```text payment_provider = klarna external_order_id = shop_12345 ``` Avoid inconsistent naming: ```text provider paymentProvider payment_provider offline_provider ``` unless intentionally different. ## 3. Preserve External References When integrating external payment systems, store useful references such as: ```text external_order_id external_payment_id external_provider third_party_shop ``` This helps reconciliation and support. ## 4. Use Customer ID Filtering for Customer-Specific Retrieval If the goal is to retrieve offline payments for one customer, use the `customer_id` filter in `GetOfflinePayments`. ## 5. Use Campaign and Shop Filters for Business Segmentation Use: ```text campaign_filter shop_filter currency_filter metadata_filter ``` to retrieve specific slices of offline payments. ## 6. Retrieve Related Records When Needed Offline Payment details may include related IDs. Use the relevant `Get...` operations to retrieve: ```text sales product_sales shipping subscriptions subscription_renewals invoices transactions paypal_transactions pending_refunds chargebacks fraud_detections ``` ## 7. Use BigQuery for Cross-Record Questions If the user asks: ```text How many? How much? Which provider? Which shop? Which campaign? Trend over time? Average amount? Top customers? ``` use BigQuery. --- # MCP/AI Guidance When helping a user with Offline Payments: 1. Determine whether the user wants a single offline payment, a paginated list, or a report. 2. Use `GetSiteThirdPartyIntegrations` to identify supported offline payment providers where `integration_type = offline_payment`. 2. Use `GetOfflinePayment` when the offline payment ID is known. 3. Use `GetOfflinePayments` for filtered/paginated retrieval. 4. Use `BigQueryRunQuery` for counts, sums, reports, aggregations, and analytics. 5. Use `GetBigQueryTables` before writing SQL. 6. Review `third_party_integration` to identify providers like Sezzle, Klarna, Affirm, AfterPay, or other alternate payment integrations. 7. Review `third_party_shop` to identify the originating shop/storefront. 8. Review `metadata` for external references, provider labels, checkout context, and custom reporting fields. 9. Retrieve related records when deeper context is needed. 10. Do not confuse Offline Payments with credit-card transactions. 11. Explain that Offline Payments allow RevCent to represent payments completed outside the normal card-gateway flow. 12. Explain that offline payments are not compatible with RevCent subscription billing; only credit card sales/payments are subscription capable. --- # Summary Offline Payments in RevCent represent payments completed through external, manual, alternate, or third-party payment sources rather than a standard RevCent credit-card gateway transaction. Supported offline payment integrations currently include Affirm, Afterpay, Amazon Pay, Klarna, and Sezzle. Offline payments are not compatible with subscription billing. Only credit card sales/payments are subscription capable in RevCent. They are useful for ecommerce businesses because they allow RevCent to track and connect payment activity from sources such as: ```text Sezzle Klarna Affirm Afterpay Amazon Pay Third-party shops Manual/external payment flows Alternate checkout providers ``` Offline Payments can include: ```text Amount Status Customer details Campaign details Third-party integration details Third-party shop details Metadata Related sale/product/shipping records, plus possible subscription-related context. Offline payments are not subscription-capable. ``` They help businesses: ```text Offer more payment options. Centralize customer purchase history. Support BNPL and external payment providers. Improve customer support. Connect external payments to sales and fulfillment. Run BigQuery reports on alternate payment volume. Analyze providers, campaigns, shops, customers, and metadata. ``` Used well, Offline Payments make RevCent more complete as an ecommerce revenue, customer, and operations platform. --- Document Parent Directory * [Operations](https://revcent.com/documentation/markdown/mcp/operation/index.md) - AI/MCP details and overviews for operations available within the RevCent MCP.