--- title: "Check Directs" description: "A non-technical ecosystem overview of Check Directs in RevCent, focused on how a Check Direct item is created when a Sale uses the check_direct payment type, how it serves as the Sale's official physical-check payment record in a role similar to a credit-card Transaction, and how it connects to Customers, Product Sales, Shipping, Tax, Subscriptions, refunds, automation, and reporting." type: "item" company: "RevCent" canonical: "https://revcent.com/documentation/markdown/ecosystem/item/CheckDirect.md" relationships: - name: "Sale" url: "https://revcent.com/documentation/markdown/ecosystem/item/Sale.md" - name: "Transaction" url: "https://revcent.com/documentation/markdown/ecosystem/item/Transaction.md" - name: "Offline Payment" url: "https://revcent.com/documentation/markdown/ecosystem/item/OfflinePayment.md" - name: "Customer" url: "https://revcent.com/documentation/markdown/ecosystem/item/Customer.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" url: "https://revcent.com/documentation/markdown/ecosystem/item/Subscription.md" - name: "Subscription Renewal" url: "https://revcent.com/documentation/markdown/ecosystem/item/SubscriptionRenewal.md" - name: "Pending Refund" url: "https://revcent.com/documentation/markdown/ecosystem/item/PendingRefund.md" - name: "Campaign" url: "https://revcent.com/documentation/markdown/ecosystem/feature/Campaign.md" - name: "Third Party Shop" url: "https://revcent.com/documentation/markdown/ecosystem/feature/ThirdPartyShop.md" technical_links: web_app: "https://kb.revcent.com/en/payments/check" api: section: "https://revcent.com/docs/api/v2#section-checks" operations: - name: "Get Check Directs" operation_id: "GetCheckDirects" operation: "https://revcent.com/docs/api/v2#operation-GetCheckDirects" schema: "https://revcent.com/documentation/files/api/operation/GetCheckDirects.json" - name: "Get A Check Direct" operation_id: "GetCheckDirect" operation: "https://revcent.com/docs/api/v2#operation-GetCheckDirect" schema: "https://revcent.com/documentation/files/api/operation/GetCheckDirect.json" mcp: overview: "https://revcent.com/documentation/markdown/mcp/operation/OverviewCheckDirect.md" operations: - name: "Get Check Directs" operation_id: "GetCheckDirects" markdown: "https://revcent.com/documentation/markdown/mcp/operation/GetCheckDirects.md" available_via_ai: true - name: "Get A Check Direct" operation_id: "GetCheckDirect" markdown: "https://revcent.com/documentation/markdown/mcp/operation/GetCheckDirect.md" available_via_ai: true bigquery_schema: "https://revcent.com/documentation/files/bigquery/dataset.json" bigquery_tables: - "check" --- # Check Directs A Check Direct is the official RevCent payment item for a Sale paid by physical check. When a Sale has a payment type of `check_direct`, RevCent creates a Check Direct item. The Check Direct fills the payment-record role for that Sale in much the same way that a Transaction fills the payment-record role for a credit-card Sale. At the simplest level: ```text Sale payment_type = check_direct ↓ RevCent creates the Sale and its related commerce items ↓ RevCent creates a Check Direct item as the official payment entry ↓ The Check Direct remains connected to the Sale and its related records ``` A Check Direct is not a credit-card Transaction, an ACH transfer, or an electronic check. It represents a physical-check payment path and the accounts-receivable context that comes with receiving, depositing, and reconciling a check. ## Why Check Directs Are an Item Check Directs are an item because each record represents a specific payment occurrence. A business does not configure one reusable Check Direct and apply it to many Sales. Instead, RevCent creates a separate Check Direct item for each Sale whose payment type is `check_direct`. This distinction is important: | Concept | Meaning | |---|---| | Sale | The overall purchase or order event. | | Check Direct | The official physical-check payment record for that Sale. | | Transaction | A credit-card payment-attempt record processed through a Gateway. | | Offline Payment | An alternate, manual, or external payment record outside the standard card flow. | The Sale explains what was purchased. The Check Direct explains how that Sale is being paid. ## Core Purpose The core purpose of a Check Direct is to preserve payment truth for a physical-check Sale. It helps the business understand: - Which Sale was paid by check. - The amount associated with the check payment. - Which Customer owes or supplied the payment. - The check number when available. - Whether the check has been received. - The current status recorded for the check. - Which Campaign or Third Party Shop originated the Sale. - Which Product Sales, Shipping, Tax, Subscription, or renewal records belong to the same commerce event. - Which refund or reconciliation activity later relates to the payment. Without a Check Direct item, the Sale could show a check-based payment type without a first-class payment record to inspect, relate, automate, and report on. ## Where Check Directs Fit in the Ecosystem Check Directs sit between the Sale and the physical-check payment lifecycle. ```text Customer ↓ Sale ├─ Product Sales ├─ Shipping ├─ Tax ├─ Discounts ├─ Subscription or Trial context └─ Check Direct payment item ↓ receipt, deposit, clearing, reconciliation, refund context, and reporting ``` For ecosystem graphing, a Check Direct should be treated as a payment node parallel to other payment item types. ## Technical Links | Area | Link | |---|---| | Web App / Knowledge Base | `https://kb.revcent.com/en/payments/check` | | API | `https://revcent.com/docs/api/v2#section-checks` | | MCP | `https://revcent.com/documentation/markdown/mcp/operation/OverviewCheckDirect.md` | | BigQuery Table | `check` | The API and MCP call the item a Check Direct and use `check_direct` identifiers. The BigQuery table is named `check`. ## How Check Directs Are Created A Check Direct is created as a result of Sale creation. The essential creation rule is: ```text Sale has payment_type: check_direct ↓ Sale is created ↓ Check Direct item is created as the Sale's payment record ``` Creation paths can include: - A Sale entered in the RevCent web app with Check Direct selected as the payment type. - A direct API or MCP `CreateSale` request using `payment_type: check_direct`. - An internal or custom storefront workflow that creates a check-based Sale. - An authorized AI workflow creating a Sale that the user has explicitly chosen to pay by physical check. There is no standalone Check Direct creation operation. The item is spawned by the Sale's payment method. ## Physical Check, Not ACH or Electronic Check Check Direct represents a physical check. This distinction matters because physical checks involve operational steps that do not exist in the same way for an electronic payment: - instructions for who the check should be payable to, - a mailing destination, - waiting for the check to arrive, - recording that it was received, - depositing it, - waiting for it to clear, - handling a returned or bounced check, - reconciling the payment with the Sale. An ACH or electronic-check payment should not be described as a Check Direct unless RevCent explicitly represents it that way in the applicable workflow. ## Check Direct as the Official Payment Entry The Check Direct is not merely a note saying that a check may arrive. It is the official payment item related to the check-based Sale. This is similar to how a Transaction represents the payment entry for a credit-card Sale: ```text Credit-card Sale → Transaction payment item Check-based Sale → Check Direct payment item ``` The similarity is about ecosystem role. Both items connect payment activity to the Sale, Customer, Product Sales, and other related records. The difference is how payment happens. A Transaction records a card attempt through a Gateway and can have an approval, decline, or processor error. A Check Direct records a physical-check payment lifecycle and does not represent a card Gateway attempt. ## Check Direct vs Transaction | Area | Check Direct | Transaction | |---|---|---| | Payment method | Physical check | Credit card | | Creation trigger | Sale uses `payment_type: check_direct` | Card payment is attempted through a Gateway | | Official payment role | Payment item for the check-based Sale | Payment-attempt item for the card-based Sale | | Gateway response | Not applicable as a card processor response | Preserves Gateway approval, decline, or error details | | Timing | May involve waiting for receipt and clearing | Attempt result is returned by the processor | | BigQuery table | `check` | `transaction` | These are parallel payment records, but they should not be treated as technically interchangeable. ## Check Direct vs Offline Payment Check Direct and Offline Payment are both non-credit-card payment items, but they represent different paths. A Check Direct is specifically for a physical check. An Offline Payment can represent a manual, alternate, or external payment method such as an integrated Buy Now Pay Later provider or another payment completed outside RevCent's card Gateway flow. Use the Sale's authoritative payment type and related payment item instead of inferring the payment path from a description or Metadata value. ## Relationship to Sales The Sale is the parent commerce event for a Check Direct. The Sale contains the Products, amount, Customer, Campaign, Shop, Shipping, Tax, Discounts, and other purchase context. The Check Direct is the payment entry that explains that the Sale uses the physical-check path. A Sale response can include a `check_directs` array containing related Check Direct IDs. Each ID can be retrieved with `GetCheckDirect`. This relationship helps answer: - What was purchased with this check? - What Sale amount does the check correspond to? - Is the Sale waiting for physical payment? - Which related items should be reconciled if the check is received, clears, or fails? ## Relationship to Customers A Check Direct is connected to the Customer who made or owes the payment. Customer relationship visibility helps support and accounts-receivable teams understand: - which Customer should send the check, - which Sale the check is intended to pay, - whether the payment has been received, - the check number when recorded, - the surrounding order, Shipping, Tax, and Subscription context, - whether other payment or support activity exists for the same Customer. Check-related details should be treated as payment-sensitive information and disclosed only to authorized users. ## Relationship to Product Sales Product Sales are the individual purchased line items inside the Sale. The Check Direct can connect to those Product Sales so the business can understand which Products were paid by physical check. This supports product-level revenue, fulfillment, refund, and profitability analysis. For a multi-product Sale, the Sale is the order-level context, the Product Sales are the line-item context, and the Check Direct is the payment context. ## Relationship to Shipping and Fulfillment A check-based Sale may include shippable Products and related Shipping records. The Check Direct relationship helps operations teams determine whether fulfillment should occur before the check arrives, after receipt, after deposit, or after clearing according to the business's policy. RevCent preserves the relationship, but the business must decide its own fulfillment risk policy. A Check Direct record should not be interpreted as proof that funds have irrevocably cleared unless authoritative status confirms that outcome. ## Relationship to Tax and Discounts Tax and Discounts remain separate components of a check-based Sale. The Check Direct amount belongs to the full Sale economics, while related Tax and Discount items explain how the amount due was calculated. This separation helps with: - reconciliation, - accounting review, - product-level profitability, - refund allocation, - customer support, - Campaign and Shop reporting. ## Relationship to Subscriptions and Renewals Check Direct records can be related to Subscription and Subscription Renewal context. When a check-based Sale creates a Subscription, the initial Check Direct preserves how the originating Sale was paid. Related renewal records can provide later recurring-payment context. The presence of a Check Direct should not be used to assume that every future renewal uses the same payment path. Retrieve the authoritative Subscription and renewal records when that detail matters. ## Received and Status Context Check Direct retrieval includes: - `received`, indicating whether the physical check has been received, - `status`, describing the current recorded check state, - `check_number`, when a check number is available. These fields are important because a physical check can exist in several operational stages. A record can be created before the check has completed its full receipt and clearing lifecycle. AI, fulfillment, support, and accounts-receivable workflows should use the authoritative returned fields instead of guessing from the Sale date or from a customer statement. ## Refunds and Pending Refunds Check Direct does not have a standalone `RefundCheckDirect` operation. When a refund is needed, the refund is associated with the relevant commerce item, such as the Sale component, Product Sale, Shipping, Tax, or Subscription Renewal. The resulting Pending Refund context can remain related to the Check Direct payment record. This distinction matters because a physical-check refund may require a different operational process than an electronic reversal through a payment processor. The business should determine: - what is being refunded, - the amount to return, - how the return payment will be issued, - whether the original check was received and cleared, - which related item should preserve refund attribution. ## Campaigns and Third Party Shops Check Directs can carry Campaign and Third Party Shop context from the related Sale. This allows a business to analyze physical-check payment volume by acquisition source, storefront, Customer, Product, and time period. It also helps reconcile Shop orders whose official RevCent payment record is a Check Direct rather than a card Transaction, PayPal Transaction, or Offline Payment. ## Metadata, Notes, and Automation Check Directs can participate in Metadata, Notes, Events, Functions, AI Assistant, AI Voice Agent, Email Template, and other automation relationships. Useful Metadata can include non-sensitive internal references such as: - invoice or purchase-order reference, - remittance reference, - support case, - internal accounts-receivable owner, - business unit, - expected arrival date supplied by an authorized workflow. Avoid storing raw bank account or routing information in general-purpose Metadata. The `check_direct.created` account event can allow configured automation to respond when a new Check Direct item is created. Automation should not represent a check as received or cleared unless authoritative state supports that statement. ## Viewing Check Directs The RevCent web app lists check payments under Payments > Check > All Checks. Users can open: ```text https://revcent.com/user/checks ``` The Knowledge Base page is: ```text https://kb.revcent.com/en/payments/check ``` The Check Direct details and related entity links help users move between the payment record, Sale, Customer, Product Sales, Shipping, Tax, and other surrounding records. ## API and MCP Retrieval Check Directs currently have two retrieval operations: | Operation | Purpose | |---|---| | `GetCheckDirects` | Retrieve a bounded, paginated list of Check Direct records. | | `GetCheckDirect` | Retrieve one Check Direct by its 20-character ID. | There is no standalone create or refund operation for a Check Direct. Creation occurs through a Sale with `payment_type: check_direct`, and refund handling belongs to the relevant related commerce item. ## BigQuery Reporting The BigQuery representation is the `check` table. It includes: - Check creation time and ID, - amount, - live or test mode, - Campaign, - currency, - Customer, - Third Party Shop, - related Tax records, - related Shipping records, - related Product Sales, - related Pending Refunds, - Metadata. Use BigQuery for counts, totals, trends, broad analysis, reconciliation, and comparisons across payment types. Do not loop through paginated operational results to build reports. Example questions include: - How much Sale value used Check Direct this month? - How many check-based Sales came from each Campaign or Shop? - Which Customers or Products most often use physical checks? - Which check-based Sales have related Pending Refunds? - How does Check Direct volume compare with credit-card, PayPal, and Offline Payment volume? ## Business Benefits Treating Check Direct as a first-class payment item gives businesses: - A clear payment record for physical-check Sales. - Better accounts-receivable visibility. - Separation from card Transactions and alternate Offline Payments. - Better Customer and order support context. - Better Shipping and fulfillment decisions. - Better refund attribution. - Better Campaign, Shop, Product, and payment-type reporting. - A durable relationship node for AI and automation. ## Check Direct as a Relationship Graph Node ```text Sale with payment_type: check_direct ↓ Check Direct ├─ Customer ├─ Sale ├─ Product Sales ├─ Shipping ├─ Tax ├─ Discounts ├─ Subscription and Renewal context ├─ Pending Refunds ├─ Campaign and Third Party Shop ├─ Metadata and automation └─ BigQuery reporting ``` The Check Direct explains the payment path while the related Sale and item records explain the purchase. ## Common Ecommerce Use Cases - Creating a business-to-business Sale that will be paid by physical check. - Recording a purchase-order-backed order whose remittance arrives by mail. - Tracking whether payment has been received before Shipping. - Connecting a physical check to Products, Tax, and fulfillment. - Reconciling check volume by Customer, Campaign, Shop, or Product. - Preserving refund context for a Sale originally paid by check. - Triggering authorized accounts-receivable or customer communication workflows. ## Common Mistakes to Avoid - Do not treat Check Direct as ACH or an electronic check. - Do not treat the Check Direct as a credit-card Gateway attempt. - Do not create a separate payment record manually when the Sale's `check_direct` payment type creates it. - Do not assume a created Check Direct means the physical check has been received or cleared. - Do not infer status from the Sale date. - Do not expose check or Customer details without authorization. - Do not place raw bank account or routing details in general-purpose Metadata. - Do not look for a standalone `CreateCheckDirect` or `RefundCheckDirect` operation. - Do not use paginated retrieval to create metrics or reports. - Do not combine live and test Check Directs in production reporting. ## AI/MCP Guidance ```text Need to create a physical-check Sale? → Use the appropriate Sale workflow with payment_type: check_direct. Need to find recent Check Direct payment records? → Use GetCheckDirects with a narrow date range and bounded pagination. Need the authoritative details of one check payment? → Use GetCheckDirect with an exact Check Direct ID. Need totals, counts, trends, or broad comparison? → Use BigQueryRunQuery against the documented check table. ``` Before creating a check-based Sale, verify that the user explicitly intends a physical-check payment and understands whether the order should be considered paid, pending receipt, or subject to a later fulfillment decision. Do not collect unnecessary bank information or claim that funds have cleared without authoritative evidence. ## Summary A Check Direct is the official physical-check payment item created when a Sale uses `payment_type: check_direct`. It occupies a role similar to a Transaction by connecting a payment record to the Sale and related commerce items. Unlike a Transaction, it does not represent a credit-card Gateway attempt. It preserves the physical-check payment lifecycle, Customer and Sale relationships, receipt and status context, refund relationships, automation context, and BigQuery reporting value. --- 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.