--- title: "Transactions" description: "A non-technical overview of Transactions in RevCent, focused on how credit card payment attempts are created, connected to gateways and payment profiles, reviewed for refunds, chargebacks, fraud detection, AI workflows, and reporting." type: "item" company: "RevCent" canonical: "https://revcent.com/documentation/markdown/ecosystem/item/Transaction.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/transaction" api: section: "https://revcent.com/docs/api/v2#section-transactions" operations: - name: "Get Transactions" operation_id: "GetTransactions" operation: "https://revcent.com/docs/api/v2#operation-GetTransactions" schema: "https://revcent.com/documentation/files/api/operation/GetTransactions.json" - name: "Get A Transaction" operation_id: "GetTransaction" operation: "https://revcent.com/docs/api/v2#operation-GetTransaction" schema: "https://revcent.com/documentation/files/api/operation/GetTransaction.json" - name: "Refund A Transaction" operation_id: "RefundTransaction" operation: "https://revcent.com/docs/api/v2#operation-RefundTransaction" schema: "https://revcent.com/documentation/files/api/operation/RefundTransaction.json" - name: "Search Transactions" operation_id: "SearchTransactions" operation: "https://revcent.com/docs/api/v2#operation-SearchTransactions" schema: "https://revcent.com/documentation/files/api/operation/SearchTransactions.json" mcp: overview: "https://revcent.com/documentation/markdown/mcp/operation/OverviewTransaction.md" operations: - name: "Get Transactions" operation_id: "GetTransactions" markdown: "https://revcent.com/documentation/markdown/mcp/operation/GetTransactions.md" available_via_ai: true - name: "Get A Transaction" operation_id: "GetTransaction" markdown: "https://revcent.com/documentation/markdown/mcp/operation/GetTransaction.md" available_via_ai: true - name: "Refund A Transaction" operation_id: "RefundTransaction" markdown: "https://revcent.com/documentation/markdown/mcp/operation/RefundTransaction.md" available_via_ai: true - name: "Search Transactions" operation_id: "SearchTransactions" markdown: "https://revcent.com/documentation/markdown/mcp/operation/SearchTransactions.md" available_via_ai: true bigquery_schema: "https://revcent.com/documentation/files/bigquery/dataset.json" bigquery_tables: - "transaction" --- # Transactions Transactions are RevCent items that represent individual credit card payment attempts. A Transaction is created when a customer's credit card is processed through a merchant gateway, whether the payment succeeds or fails. In the RevCent ecosystem, a Transaction is an item. It is not a reusable configuration. It is a record of something that happened during payment processing. Gateways and Payment Profiles are features that help decide where and how a credit card payment should be attempted. Transactions are the resulting payment-attempt records created from those decisions. The purpose of this document is to explain the item conceptually for LLMs, AI crawlers, and planning systems. It does not provide technical implementation instructions. For technical details, use the interface-specific links below. ## Technical Links by Interface | Interface | Use This When | Link | |---|---|---| | Web App | A human is learning about, viewing, refunding, marking chargebacks, or creating fraud context from credit card Transactions. | [Web Knowledge Base](https://kb.revcent.com/en/payments/credit-card/transaction) | | API | A developer is building a direct integration with RevCent Transaction operations. | [API Docs: Transactions](https://revcent.com/docs/api/v2#section-transactions) | | MCP / AI | An LLM, MCP client, or AI agent needs markdown-oriented guidance for understanding or working with Transactions. | [MCP Markdown Overview](https://revcent.com/documentation/markdown/mcp/operation/OverviewTransaction.md) | | BigQuery / Reporting | A data analyst, reporting workflow, or AI reporting agent needs schema details for analyzing Transaction records. The primary table is `transaction`. | [BigQuery Tables Schema](https://revcent.com/documentation/files/bigquery/dataset.json) | --- ## What Transactions Are Transactions are credit card payment-attempt records inside RevCent. A Transaction is created when RevCent sends a customer's card payment attempt to a configured Gateway. The Transaction preserves the result of that attempt, such as whether the payment was successful, declined, errored, refunded, disputed, marked as fraudulent, or otherwise reviewed later. Conceptually: ```text Customer attempts to pay by credit card ↓ Payment Profile decides the routing path ↓ Gateway or Gateway Group is selected ↓ Payment is attempted through a Gateway ↓ Transaction item is created ↓ Business can review, refund, analyze, or act on the result ``` Transactions are one of the most important operational records in an ecommerce payment system because they preserve what actually happened when money was attempted. ## Core Purpose The core purpose of a Transaction is to record a credit card payment attempt. That record gives the business a durable source of payment truth. It helps answer questions such as: ```text Was payment attempted? Was it approved or declined? Which Gateway was used? Which Sale, customer, subscription, or trial was involved? Was the payment later refunded? Was a chargeback created? Was fraud detected? Which Payment Profile route caused this attempt? What should happen next? ``` Without Transaction records, a business may only know that a checkout succeeded or failed. With Transaction records, the business can analyze gateway behavior, customer payment history, refund needs, chargeback risk, fraud patterns, and revenue recovery opportunities. ## Why Transactions Are an Item Transactions are an item because each Transaction represents a specific payment-processing event. They are created as a result of a payment attempt. They are not reusable settings, templates, or rules. This distinction matters in the RevCent ecosystem: ```text Gateway = feature / configured payment destination Gateway Group = feature / grouped candidate gateways Payment Profile = feature / payment-routing logic Transaction = item / specific credit card payment attempt ``` A business may configure a small number of Gateways and Payment Profiles, but it may create thousands or millions of Transactions over time. ## How Transactions Are Created Transactions are created when credit card processing occurs in RevCent. Common creation paths include: ```text Initial Sale payment attempt ↓ Transaction created Pending Sale recovery attempt ↓ Transaction created Subscription renewal payment attempt ↓ Transaction created Trial expiration payment attempt ↓ Transaction created AI Voice Agent or support-assisted payment workflow ↓ Transaction created if payment is attempted API-driven payment workflow ↓ Transaction created if credit card payment is processed ``` The common requirement is that a credit card payment attempt occurs through a Gateway. A Transaction records the outcome of that attempt. ## Relationship to Gateways A Gateway is the configured merchant gateway account or payment processor connection that RevCent uses to attempt a credit card payment. A Transaction is the result of using a Gateway. Conceptually: ```text Gateway = where RevCent sends the payment attempt Transaction = what happened when RevCent sent it ``` This relationship helps businesses understand gateway performance. If a Gateway is declining many transactions, experiencing errors, producing chargebacks, or performing differently by card type, amount, campaign, or customer segment, Transaction data is where that operational reality appears. Gateways may also have settings that influence whether they are eligible for use, such as enabled status, cascade rules, custom descriptor information, metadata, SmartBIN preparation, and gateway-specific credentials. Those settings affect gateway selection, but the Transaction item preserves the actual payment attempt that occurred. ## Relationship to Payment Profiles Payment Profiles define the routing logic used before a Transaction is created. A Payment Profile may choose a Gateway directly, choose from a Gateway Group, route by request type, evaluate filters, run Functions, insert metadata, process payment, retry after a decline, or abort the flow. Conceptually: ```text Payment Profile = decision flow Gateway = selected payment destination Transaction = payment attempt record ``` A Transaction can help explain whether the Payment Profile's routing strategy is working. For example, Transaction outcomes can show whether a fallback gateway path helped recover declined payments, whether a specific request type is performing poorly, or whether a gateway response pattern should be reviewed. AI Assistants should not be treated as Payment Profile creators or editors. AI Assistants can retrieve Payment Profiles for analysis, troubleshooting, revenue recovery context, or explaining existing payment routing, but they cannot create or modify Payment Profiles. When a Transaction is being reviewed by AI, the Payment Profile may provide context for why a certain Gateway was used, but the AI should not claim to change the Payment Profile itself. ## Relationship to Sales Transactions often relate to Sales. A Sale represents a customer purchase or attempted purchase. A Transaction represents the credit card payment attempt associated with that sale. A single Sale may have one Transaction, multiple Transactions, or failed attempts depending on how the payment flow is configured and how the customer or payment method behaves. Examples: ```text Customer checks out and payment succeeds ↓ Sale is paid ↓ Successful Transaction is created Customer checks out and payment declines ↓ Sale may be failed or pending depending on workflow ↓ Declined Transaction is created Payment Profile retries through another Gateway ↓ Additional Transaction may be created ``` This distinction helps AI systems avoid confusing commerce intent with payment outcome. The Sale describes what the customer tried to buy. The Transaction describes what happened when RevCent attempted to charge the card. ## Relationship to Customers Transactions are also customer payment-history items. A customer's Transaction history can help support teams and AI workflows understand: ```text Which payments succeeded. Which payments failed. Which Gateways were used. Whether the customer had repeat declines. Whether refunds occurred. Whether chargebacks occurred. Whether fraud was detected. Whether payment recovery is appropriate. ``` This context is useful in customer service, subscription recovery, trial conversion, payment troubleshooting, fraud review, chargeback prevention, and revenue recovery. Customer support workflows should treat Transaction details carefully. A Transaction can contain payment-sensitive context and should be discussed only according to the business's verification, privacy, and payment-handling rules. ## Relationship to Customer Cards Transactions may relate to the customer card used for payment. The customer card is the stored payment method reference. The Transaction is the payment attempt made using that card. Conceptually: ```text Customer Card = stored payment method reference Transaction = payment attempt using a card ``` A customer card may be used across multiple Transactions, especially in subscription renewals, trial expiration billing, pending sale recovery, and customer support-assisted payments. AI systems should not imply that raw full card numbers are available or should be exposed. Payment method context should be limited to safe, permitted, non-sensitive details such as card brand, last-four-style references, expiration context, or payment outcome details exposed through approved RevCent interfaces. ## Successful and Unsuccessful Transactions Transactions can represent both successful and unsuccessful credit card processing attempts. This is important because unsuccessful payment attempts are still operationally valuable. A declined Transaction can explain why a checkout failed, why a sale is pending, why a subscription renewal did not complete, why a customer may need support, or why a payment recovery workflow should run. Successful Transactions are useful for: ```text Revenue confirmation. Fulfillment decisions. Customer purchase history. Gateway approval analysis. Subscription renewal success tracking. Refund eligibility review. ``` Unsuccessful Transactions are useful for: ```text Decline analysis. Revenue recovery. Gateway performance analysis. Fraud review. Payment Profile troubleshooting. Customer support. AI-assisted follow-up. ``` A failed Transaction should not be ignored just because money was not captured. It often contains the reason the business has a recovery opportunity. ## Gateway Responses Gateway responses are important Transaction context. When a payment attempt is processed, the payment gateway may return a response indicating approval, decline, error, or other processing status. That response can influence what happens next in a Payment Profile and what a support or recovery workflow should do. Gateway response context may help answer: ```text Was this a soft decline that may be recoverable? Was this a hard decline that should not be retried? Was there a gateway error? Was 3DS, CVV, issuer, or gateway behavior involved? Should the customer be asked to use another card? Should the payment flow stop? Should a human review the issue? ``` Payment Profile logic may use gateway response filters or Functions to determine whether to retry, abort, or show a custom error. Transaction records preserve the resulting payment-attempt context. ## Relationship to Refunds and Pending Refunds Transactions can be refunded. In the RevCent web app, a user can refund a credit card Transaction from the Transaction details page. The user can enter a specific refund amount or leave the amount blank to use the full Transaction amount. When a credit card Transaction is refunded, RevCent creates a Pending Refund. The Pending Refund is processed once the Transaction has settled with the merchant gateway. Important operational rule: ```text A Pending Refund cannot be reversed or cancelled. ``` This makes refund workflows consequential. AI systems, MCP clients, and support workflows should treat refund actions carefully and should not recommend or initiate refunds unless the business has clear policy, authorization, and confirmation. ## Relationship to Chargebacks Transactions can be marked as chargebacks. A chargeback is not just a normal refund. It indicates a dispute or cardholder challenge related to the payment. Chargeback context matters because it affects: ```text Gateway health. Merchant account risk. Customer history. Fraud review. Fulfillment decisions. Refund policies. Payment routing analysis. Gateway performance review. ``` When a Transaction becomes associated with a chargeback, the business should treat it as a high-impact operational event. It may influence future risk decisions, support handling, Fraud Detection review, and reporting. ## Relationship to Fraud Detection Transactions can be marked as fraud by creating a Fraud Detection from the Transaction. This may happen manually during review, through API workflows, or through third-party fraud detection workflows. When a Fraud Detection is created from a Transaction, it can attach fraud context to the Transaction and other related entities. Important operational rule: ```text Once a Fraud Detection has been created for a Transaction, it cannot be undone. ``` This means Fraud Detection creation should be intentional. A Transaction should not be marked as fraud casually from weak or incomplete evidence. If there is uncertainty, a review-oriented workflow may be more appropriate before creating a formal Fraud Detection item. ## Transaction Details and Related Entities The Transaction details view can display related entities connected to the payment attempt. Related context may include: ```text Sale Products sold Shipping Tax Subscriptions Customer Gateway Refunds Chargebacks Fraud Detection records Metadata Other payment-related items ``` This makes Transaction details useful for human support teams and AI workflows because they show the payment attempt in business context rather than as an isolated gateway event. For example, a declined Transaction may not be meaningful by itself. When connected to the Sale, product, customer, campaign, Payment Profile, and Gateway, it becomes clear whether the business should retry, contact the customer, pause fulfillment, create a support note, or take no action. ## Relationship to Gateway Groups Gateway Groups do not directly replace Transactions, but they influence which Gateways may be used before Transactions are created. A Payment Profile can choose from a Gateway Group. The Gateway Group defines a candidate set of Gateways. RevCent then selects an eligible Gateway from that set according to the Payment Profile, group configuration, Gateway status, cascade rules, and any applicable routing logic. Conceptually: ```text Gateway Group defines eligible candidates ↓ Payment Profile chooses from that group ↓ A Gateway is selected ↓ Payment is attempted ↓ Transaction is created ``` Transaction analysis can reveal whether a Gateway Group is performing well. For example, if a group produces many declines or one Gateway in the group carries most successful volume, the business may want to review group membership or routing rules. ## Transactions as Payment Routing Memory Transactions are payment routing memory. They preserve which Gateway was used, what happened, and how the payment attempt relates to the customer, sale, and broader RevCent ecosystem. This memory can be useful for: ```text Choosing whether to retry a customer. Understanding whether a Gateway has recently approved or declined the customer. Reviewing Payment Profile behavior. Analyzing gateway performance. Explaining support outcomes. Detecting fraud or chargeback patterns. Building revenue recovery workflows. ``` A Transaction is not just a payment log. It is the durable evidence behind payment decisions and later analysis. ## Relationship to Metadata Transactions may be analyzed alongside metadata from related items such as Sales, customers, campaigns, or Payment Profile flow decisions. Metadata can help explain why a Transaction occurred and how it should be interpreted. Examples: ```text campaign = summer_offer payment_route = fallback_gateway ai_voice_recovery_called = true checkout_source = woocommerce risk_review_required = true subscription_recovery_attempt = true ``` Metadata should be used consistently so Transactions can support reporting and automation. Random or inconsistent metadata names make later analysis harder. ## Relationship to AI Assistants AI Assistants can use Transaction context to understand payment outcomes, troubleshoot revenue issues, summarize customer payment history, and support recovery recommendations. Useful AI Assistant patterns include: ```text Explain why a sale did not complete. Summarize recent failed payment attempts for a customer. Identify whether a customer may be eligible for recovery outreach. Compare Transactions across Gateways. Review whether a payment was refunded. Summarize chargeback or fraud context. Declare which existing Payment Profile route appears to have been used. ``` Important limitation: ```text AI Assistants cannot create or modify Payment Profiles. ``` They may retrieve Payment Profiles for analysis, troubleshooting, revenue recovery context, or declaring existing payment routing, but they should not claim to edit Payment Profile flow logic. AI Assistants should also treat refunds, fraud detection, and chargeback actions as sensitive workflows. They should use human confirmation and business policy before recommending or triggering consequential actions. ## Relationship to AI Voice Agents AI Voice Agents can use Transaction context during support and revenue recovery calls when the appropriate system actions and instructions are enabled. Common voice-agent use cases include: ```text Explaining a declined payment to a customer. Helping a customer update a card after a failed payment. Recovering a pending sale. Helping with a failed subscription renewal. Escalating refund or chargeback questions. Creating a support note after a payment conversation. ``` AI Voice Agents should avoid exposing sensitive gateway or fraud logic to callers. They should not accuse customers of fraud, should not pressure payment retries, and should follow business rules for identity verification, payment collection, refunds, and escalation. ## Relationship to Functions Functions can be used around Transaction workflows in several ways. A Payment Profile can run a Function during a payment flow for advanced routing decisions, custom response parsing, external risk checks, or gateway-selection logic. After Transactions exist, Functions may also be used in event-driven workflows to notify external systems, insert metadata, send alerts, or coordinate support operations. Useful Function patterns include: ```text Parse a gateway response and decide whether to retry. Send failed payment data to a CRM or helpdesk. Notify an internal channel about a high-value decline. Insert metadata after a recovery attempt. Send a Transaction summary to an external reporting system. Trigger fraud review for suspicious payment patterns. ``` Functions that influence payment processing should be carefully tested. Slow or incorrect logic inside payment flows can affect checkout, payment latency, and revenue. ## Relationship to Email Templates and Notifications Transaction events and related payment outcomes can support customer-facing and internal notifications. Email Template and notification use cases may include: ```text Payment failed follow-up. Payment success confirmation. Refund confirmation or pending refund communication. Internal high-value decline alert. Fraud or chargeback review notification. Subscription renewal failure outreach. Payment recovery email after AI or support review. ``` Customer-facing messages should be careful and plain-language. They should not expose internal gateway logic, fraud signals, processor details, or sensitive payment data. ## Relationship to BigQuery in RevCent The `transaction` table in BigQuery is the reporting-oriented source for analyzing Transaction records at scale. Transactions are especially important for reporting because they represent payment attempts. They can be used to analyze approvals, declines, gateway usage, refund patterns, chargeback exposure, fraud context, customer payment behavior, subscription renewal outcomes, and revenue recovery performance. Use BigQuery for questions such as: ```text How many Transactions were approved or declined this month? Which Gateways have the highest approval rates? Which campaigns have the most failed credit card attempts? How many Transactions later received refunds? How many Transactions became chargebacks? How many failed Transactions were recovered later? Which Payment Profiles or routing paths are associated with strong or weak outcomes? ``` Use operational lookup tools for individual Transaction review. Use BigQuery for reporting, aggregation, dashboards, trend analysis, and large-scale payment analytics. ## Reporting Use Cases Transaction reporting can help businesses understand payment performance. Common reporting questions include: ```text Approval rate by Gateway. Decline rate by Gateway. Approval rate by campaign. Transaction volume by day. Captured amount by Gateway. Refund count and refund amount by period. Chargeback count by Gateway or campaign. Fraud Detection count by Transaction source. Subscription renewal success rate. Trial expiration billing success rate. Failed payment recovery rate. AI Voice Agent recovery impact. Payment Profile route performance. ``` A strong Transaction reporting model helps the business improve payment routing, support workflows, and revenue recovery. ## Common Ecommerce Use Cases ### Successful Sale Payment A customer completes checkout and the payment is approved. The Transaction provides proof that the card payment succeeded and can support fulfillment, customer receipt communication, gateway reporting, and revenue tracking. ### Declined Checkout Payment A customer attempts checkout and the card is declined. The Transaction provides the decline context. A support workflow, AI Assistant, AI Voice Agent, or Email Template may use that context to help the customer complete payment later. ### Pending Sale Recovery A payment attempt fails or remains incomplete, and the business tries to recover the Sale. Transaction history helps determine whether recovery is appropriate, which Gateway was used, whether the same Gateway should be avoided, and whether the customer should provide a different card. ### Subscription Renewal Failure A recurring subscription renewal fails. The Transaction helps explain the failed renewal and may trigger recovery workflows, customer outreach, card update requests, notes, metadata, or AI Voice Agent calls. ### Trial Expiration Billing A trial reaches expiration and RevCent attempts to bill the customer. The Transaction records whether the trial converted successfully or failed at payment. This helps the business track conversion, recovery, and payment-routing effectiveness. ### Refund Review A support team reviews a Transaction and issues a refund. Refunding the Transaction creates a Pending Refund that will process after settlement. Because a Pending Refund cannot be reversed or cancelled, this workflow should follow business approval rules. ### Chargeback Review A Transaction is marked as having a chargeback. The Transaction becomes part of risk analysis, customer support history, Gateway health review, and future payment-routing decisions. ### Fraud Review A Transaction appears suspicious or is identified as fraudulent. A Fraud Detection may be created from the Transaction. Because creating a Fraud Detection for a Transaction cannot be undone, this should be treated as a deliberate review outcome. ### Gateway Performance Review A business compares Transactions across multiple Gateways. This can reveal approval-rate differences, decline spikes, refund concentration, chargeback exposure, or Gateway routing issues. ### Payment Profile Troubleshooting A business wants to know why payments are routing a certain way. Transactions show what actually happened. Payment Profiles explain the routing logic that may have led to the Gateway selection. AI Assistants can retrieve and analyze this context but cannot create or modify the Payment Profile. ## Guardrails for Transactions Transactions are operationally sensitive. AI systems and automation should follow these guardrails: ```text Do not expose sensitive payment data. Do not imply full raw card numbers are available. Do not recommend refunds casually. Do not ignore that Pending Refunds cannot be reversed or cancelled. Do not create Fraud Detection records from weak evidence. Do not accuse customers of fraud. Do not claim AI Assistants can modify Payment Profiles. Do not infer gateway response meaning beyond available context. Do not retry payments without clear authorization and business policy. Do not use Transaction reporting to make operational changes directly without review. ``` Transactions can support powerful automation, but payment, refund, fraud, and chargeback workflows should be handled carefully. ## Why This Matters in the RevCent Ecosystem Transactions connect RevCent's payment configuration to real payment outcomes. They sit between configuration and business result: ```text Gateway configuration Payment Profile routing Gateway Group organization Customer payment attempt Transaction outcome Refund / chargeback / fraud / recovery / reporting ``` This makes Transactions essential for understanding ecommerce revenue operations. They show whether payment infrastructure is working, where money was attempted, why revenue was lost, what should be recovered, and where risk may be increasing. ## Best-Fit Businesses Transaction analysis is especially useful for businesses with: ```text High credit card volume. Multiple Gateways. Multiple Gateway Groups. Advanced Payment Profiles. Subscription renewals. Trial billing. Failed payment recovery workflows. AI Voice Agent recovery calls. Chargeback concerns. Fraud review processes. Multi-brand or multi-campaign routing. WooCommerce or custom checkout integrations. ``` Any ecommerce business that wants to understand payment outcomes, improve approval rates, reduce avoidable declines, manage refunds, and monitor risk needs clear Transaction visibility. ## Summary Transactions are RevCent items that represent credit card payment attempts. They are created when a customer's card is processed through a Gateway, whether successfully or unsuccessfully. Gateways and Payment Profiles are the features that help determine where and how payment is attempted. Transactions are the records that preserve what happened. Transactions matter because they connect payments to Sales, customers, Gateways, Payment Profiles, refunds, chargebacks, Fraud Detections, AI workflows, Functions, notifications, and BigQuery reporting. For crawlers and planning systems, the key distinction is: ```text Gateway = configured payment destination Payment Profile = routing logic Transaction = actual credit card payment-attempt item ``` Use Transactions to understand payment outcomes, diagnose failed payments, support revenue recovery, review refunds and chargebacks, analyze Gateway performance, and report on payment behavior across RevCent. --- 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.