--- title: "Customer Cards" description: "A non-technical overview of Customer Cards in RevCent, focused on what stored customer payment method references represent, why they matter, how they support ecommerce payment workflows, and how they connect customers to subscriptions, trials, recovery, support, AI, and reporting." type: "item" company: "RevCent" canonical: "https://revcent.com/documentation/markdown/ecosystem/item/CustomerCard.md" relationships: - name: "Customer" url: "https://revcent.com/documentation/markdown/ecosystem/item/Customer.md" technical_links: web_app: "https://kb.revcent.com/en/customer/customer-card" api: section: "https://revcent.com/docs/api/v2#section-customer_cards" operations: - name: "Get Customer Cards" operation_id: "GetCustomerCards" operation: "https://revcent.com/docs/api/v2#operation-GetCustomerCards" schema: "https://revcent.com/documentation/files/api/operation/GetCustomerCards.json" - name: "Get A Customer Card" operation_id: "GetCustomerCard" operation: "https://revcent.com/docs/api/v2#operation-GetCustomerCard" schema: "https://revcent.com/documentation/files/api/operation/GetCustomerCard.json" - name: "Enable A Customer Card" operation_id: "EnableCustomerCard" operation: "https://revcent.com/docs/api/v2#operation-EnableCustomerCard" schema: "https://revcent.com/documentation/files/api/operation/EnableCustomerCard.json" - name: "Disable A Customer Card" operation_id: "DisableCustomerCard" operation: "https://revcent.com/docs/api/v2#operation-DisableCustomerCard" schema: "https://revcent.com/documentation/files/api/operation/DisableCustomerCard.json" - name: "Set Default Customer Card" operation_id: "SetDefaultCustomerCard" operation: "https://revcent.com/docs/api/v2#operation-SetDefaultCustomerCard" schema: "https://revcent.com/documentation/files/api/operation/SetDefaultCustomerCard.json" - name: "Delete A Customer Card" operation_id: "DeleteCustomerCard" operation: "https://revcent.com/docs/api/v2#operation-DeleteCustomerCard" schema: "https://revcent.com/documentation/files/api/operation/DeleteCustomerCard.json" - name: "Search Customer Cards" operation_id: "SearchCustomerCards" operation: "https://revcent.com/docs/api/v2#operation-SearchCustomerCards" schema: "https://revcent.com/documentation/files/api/operation/SearchCustomerCards.json" mcp: overview: "https://revcent.com/documentation/markdown/mcp/operation/OverviewCustomerCard.md" operations: - name: "Get Customer Cards" operation_id: "GetCustomerCards" markdown: "https://revcent.com/documentation/markdown/mcp/operation/GetCustomerCards.md" available_via_ai: true - name: "Get A Customer Card" operation_id: "GetCustomerCard" markdown: "https://revcent.com/documentation/markdown/mcp/operation/GetCustomerCard.md" available_via_ai: true - name: "Enable A Customer Card" operation_id: "EnableCustomerCard" markdown: "https://revcent.com/documentation/markdown/mcp/operation/EnableCustomerCard.md" available_via_ai: true - name: "Disable A Customer Card" operation_id: "DisableCustomerCard" markdown: "https://revcent.com/documentation/markdown/mcp/operation/DisableCustomerCard.md" available_via_ai: true - name: "Set Default Customer Card" operation_id: "SetDefaultCustomerCard" markdown: "https://revcent.com/documentation/markdown/mcp/operation/SetDefaultCustomerCard.md" available_via_ai: true - name: "Delete A Customer Card" operation_id: "DeleteCustomerCard" markdown: "https://revcent.com/documentation/markdown/mcp/operation/DeleteCustomerCard.md" available_via_ai: true - name: "Search Customer Cards" operation_id: "SearchCustomerCards" markdown: "https://revcent.com/documentation/markdown/mcp/operation/SearchCustomerCards.md" available_via_ai: true bigquery_schema: "https://revcent.com/documentation/files/bigquery/dataset.json" bigquery_tables: - "customer_card" --- # Customer Cards Customer Cards are stored customer payment method references in RevCent. They connect a Customer to secure payment context that can support future billing, recurring payments, payment recovery, customer support, subscriptions, trials, and other ecommerce workflows. A Customer Card is not a configurable feature. It is an item in the RevCent ecosystem. It is created or associated as a result of customer and payment activity, and it becomes part of the customer’s long-term ecommerce record. 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 or managing Customer Cards through the RevCent web app and Knowledge Base. | [Web Knowledge Base](https://kb.revcent.com/en/customer/customer-card) | | API | A developer is building a direct integration with the RevCent API. | [API Docs: Customer Cards](https://revcent.com/docs/api/v2#section-customer_cards) | | MCP / AI | An LLM, MCP client, or AI agent needs markdown-oriented guidance for understanding or working with the item. | [MCP Markdown Overview](https://revcent.com/documentation/markdown/mcp/operation/OverviewCustomerCard.md) | | BigQuery / Reporting | A data analyst, reporting workflow, or AI reporting agent needs schema details for analyzing customer card records. The primary table is `customer_card`. | [BigQuery Tables Schema](https://revcent.com/documentation/files/bigquery/dataset.json) | --- ## What Customer Cards Are Customer Cards are payment method reference records associated with customers in RevCent. A Customer Card gives RevCent a safe way to represent that a customer has a stored payment relationship without exposing the raw underlying card number to users, support teams, AI systems, or general business workflows. A Customer Card can provide useful non-sensitive payment context such as the customer it belongs to, whether it is enabled, whether it is the default card, card type, first six digits or BIN, last four digits, expiration information, and BIN-related details. This makes Customer Cards useful for business workflows that need to understand the customer’s payment state without exposing full payment credentials. ## Why Customer Cards Are an Item Customer Cards are an item because they are records that exist as a result of customer and payment activity. A RevCent user may view, manage, or use customer card records, but the Customer Card itself is not primarily a configurable feature like Customer Groups, AI Assistants, or Payment Profiles. It is a stored entity attached to a customer and used by other features and operations. This distinction matters for ecosystem documentation. Customer Cards belong in the `item` directory because they represent stored payment-reference records. Features such as Customer Portals, AI Assistants, AI Voice Agents, Email Templates, Functions, and Payment Profiles can use customer card context to support business workflows. ## Core Purpose The core purpose of Customer Cards is to connect a customer identity to secure payment method context. Ecommerce businesses often need to bill the same customer more than once. This may happen through subscriptions, trial conversions, failed payment recovery, repeat purchases, customer support-assisted purchases, or payment update workflows. Without a stored payment method reference, each future payment moment requires the customer to start over. With a Customer Card, RevCent can support payment continuity while keeping sensitive card data protected. Customer Cards help RevCent connect customer identity, payment history, billing continuity, and recovery workflows into one customer-centered ecommerce system. ## Secure Payment Reference, Not Raw Card Access A Customer Card should be understood as a secure payment method reference, not as raw card access. RevCent’s customer card model allows business workflows to know that a customer has a stored payment method and to reference safe card details, but the full card number is not viewable or retrievable through normal customer card views or workflows. This is important because ecommerce businesses need payment context, but they also need strong payment data protection. Support teams, AI tools, reporting workflows, and operational automations should be able to understand safe payment-reference information without seeing sensitive raw payment credentials. Conceptually: ```text Customer ↓ Customer Card reference ↓ Secure payment storage layer ↓ Approved payment workflow ``` The Customer Card gives RevCent a business-level handle for payment workflows while keeping the sensitive payment data isolated. ## Payment Data Security Customer Cards are closely tied to payment data security. Payment information is sensitive, so the Customer Card should not be treated like a normal customer note, metadata value, or general profile field. It represents payment context that must remain protected. RevCent’s Customer Card documentation emphasizes that the full credit card number cannot be viewed or retrieved from customer card records. It also describes payment data security in terms of PCI DSS Level 1 infrastructure, encryption, monitoring, and secure infrastructure design. For ecosystem understanding, the important concept is that Customer Cards provide usable payment context while sensitive raw payment data remains protected from general access. ## How Customer Cards Are Created or Associated A Customer Card can be created or associated when payment information is stored for a customer. This can happen through ecommerce activity such as a purchase attempt, sale creation, subscription-related billing setup, trial setup, customer support-assisted billing, customer portal payment updates, or API-driven payment workflows. Once created, the Customer Card becomes part of the customer’s broader RevCent profile. It can then support future billing, recovery, subscription, trial, support, and reporting workflows. This is why Customer Cards are tied to the customer lifecycle. They are not isolated payment records; they are part of the customer’s long-term commerce relationship with the business. ## Relationship to Customers Customers are the central identity that Customer Cards attach to. A Customer may have one Customer Card, multiple Customer Cards, no stored card, or one card marked as the default payment method. This relationship matters because payment context becomes more useful when it is attached to customer history. A stored card has more business value when RevCent can understand the customer’s purchases, subscriptions, renewals, trials, refunds, chargebacks, notes, metadata, customer groups, and lifetime value. For example, a failed payment from a high-value customer with an active subscription may require more attention than a failed payment from a first-time customer with no purchase history. Customer Cards help make that payment relationship visible in the customer context. ## Default Payment Method A customer may have multiple Customer Cards, and one card can be treated as the default payment method. The default card is important because it indicates which stored payment method should normally be used or referenced for future billing workflows. Default payment method context can matter for: - Subscription renewals - Trial expiration billing - Repeat billing - Payment recovery - Customer support billing context - Customer portal payment updates - AI-assisted payment analysis - Customer segmentation around card update needs Conceptually: ```text Customer ├─ Customer Card A ├─ Customer Card B └─ Default Customer Card ``` This helps RevCent understand which stored payment relationship is primary for the customer. ## Relationship to Customer Portals Customer Cards can support customer-facing payment management through Customer Portals. A Customer Portal can give customers a secure way to review or update payment method references, replace expired cards, set a default card, and manage payment information connected to subscriptions or future billing. This is important because payment recovery often depends on customer self-service. A business may detect that a card is expired, failed, or needs an update. The customer can then be directed to a secure update flow rather than being asked to send sensitive payment details through unsafe channels. Customer Cards make the customer portal more useful because the portal can operate around the customer’s existing payment relationship. ## Relationship to Sales and Purchase Attempts Sales and purchase attempts can create or use Customer Card context. When a customer attempts to purchase one or more products, a payment method may be involved. If the payment method is stored or referenced, the Customer Card can become part of the customer’s future payment history. This matters because a sale is not always the end of the customer journey. A sale may be successful, declined, abandoned, refunded, partially recovered, or connected to later subscriptions, trials, shipments, product sales, and customer support interactions. Customer Cards help keep the payment relationship connected to the customer beyond the single sale attempt. ## Relationship to Transactions and Payment Outcomes Transactions represent payment attempts and outcomes. Customer Cards provide payment method context for those outcomes. A transaction may be approved, declined, held, refunded, or produce an error. Customer Card context can help a business understand which stored payment relationship was involved, what card type was used, what BIN or last four digits are associated, and whether a payment method may need attention. This is useful for payment support, decline analysis, gateway performance review, recurring billing, and payment recovery. A single transaction tells the business what happened in one payment attempt. Customer Card context helps connect that outcome to the customer’s broader payment history. ## Relationship to BIN Details Customer Cards may include card type and BIN-related details. BIN information can help provide high-level payment context, such as card brand, card type, issuer, or issuing country, depending on available details. This can be useful for support, payment routing analysis, fraud context, gateway performance analysis, and reporting. For example, a business may want to understand whether a payment issue is concentrated around a card brand, issuer, card type, or region. Customer Card and transaction context can help make those patterns more visible. The key point is that BIN details provide analytical and operational context without requiring access to full raw card numbers. ## Relationship to Subscriptions Customer Cards are especially important for subscription businesses. A subscription represents an ongoing billing relationship. When a subscription renews, RevCent needs payment context that can support recurring billing. A stored Customer Card can help support subscription renewal attempts, renewal recovery, payment update outreach, customer portal updates, and support conversations around billing issues. Conceptually: ```text Customer subscribes ↓ Customer Card is securely associated ↓ Subscription renewal date arrives ↓ RevCent attempts renewal billing through approved payment workflow ↓ Renewal succeeds, fails, or enters recovery ``` This makes Customer Cards part of recurring revenue infrastructure. ## Relationship to Subscription Renewals Subscription Renewals are one of the most important workflows connected to Customer Cards. A renewal attempt depends on whether the customer has an usable payment method, whether that method is expired, whether it is default, whether it has declined recently, and whether the customer should be contacted for an update. If a renewal succeeds, the Customer Card relationship helps preserve billing continuity. If a renewal fails, the Customer Card relationship can help trigger recovery workflows such as email outreach, AI Voice Agent calls, Customer Group changes, AI Assistant analysis, support review, or customer portal updates. For recurring revenue businesses, Customer Cards help turn failed renewal events into recoverable customer moments. ## Relationship to Trials Trials can also depend on Customer Cards. A trial may start before a paid billing event. When the trial ends, RevCent may attempt trial expiration billing using a stored payment relationship. If the payment succeeds, the trial can become paid revenue. If the payment fails, the Customer Card remains part of the recovery context. This can support trial conversion workflows such as payment update emails, AI Voice Agent follow-up, customer support outreach, Customer Group assignment, or AI Assistant review. Customer Cards therefore help trial-based businesses reduce friction when moving a customer from trial activity to paid activity. ## Relationship to Salvage Transactions and Revenue Recovery Customer Cards are important for salvage and revenue recovery workflows. A declined payment, failed renewal, failed trial billing attempt, abandoned sale, or partially collected transaction may create a recovery opportunity. Customer Cards help keep the payment relationship connected to the customer so the business can take action. Recovery workflows may include: - Retrying eligible payments - Asking the customer to update payment information - Sending a payment recovery email - Calling the customer with an AI Voice Agent - Adding the customer to a payment recovery group - Creating a support note - Triggering an AI Assistant to analyze recovery priority - Triggering a Function to update an external CRM or billing system The business value comes from the connection between stored payment context, customer identity, and next-step automation. ## Relationship to Customer Groups Customer Cards can support Customer Group segmentation. A Customer Group can represent a payment-related state such as Card Update Needed, Payment Recovery, High Value Recovery, Subscription Save, Trial Conversion Recovery, Manual Billing Review, Recovered Payment, or Do Not Contact. When Customer Card context indicates that a payment method is expired, disabled, not default, or tied to failed payments, the customer may qualify for a group that triggers action. Conceptually: ```text Customer Card needs attention ↓ Customer enters payment-related Customer Group ↓ Workflow begins ↓ Customer updates payment method or receives follow-up ↓ Outcome is stored as group change, note, metadata, or reportable activity ``` Customer Cards provide the payment signal. Customer Groups provide the lifecycle state. ## Relationship to Notes and Metadata Customer Cards can generate useful support and automation context that may be captured through notes or metadata. A note may explain that a customer was contacted about an expired card, that a payment update link was sent, that an AI Voice Agent call occurred, or that support reviewed a billing issue. Metadata may store business-specific recovery state, card update outcome, external CRM references, payment recovery labels, or customer lifecycle indicators. Notes and metadata help preserve context around the Customer Card without storing sensitive raw payment data in ordinary business fields. ## Relationship to Email Templates Email Templates can use Customer Card-related context to support payment communication. Common customer-facing messages may include: - Payment update reminders - Failed payment notices - Subscription renewal failure notices - Trial expiration payment failure notices - Expiring card reminders - Customer portal payment update links - Payment recovery follow-ups This allows a business to communicate about payment issues in a branded, repeatable, and safer way. Customer Cards make these messages more actionable because the business can identify when a payment method may need attention. ## Relationship to AI Assistants AI Assistants can use Customer Card context as part of customer, payment, and recovery workflows. An AI Assistant may analyze a failed renewal, declined sale, failed trial conversion, or salvage opportunity and consider whether the Customer Card appears expired, whether it is the default card, whether the customer has prior successful payments, whether the customer is high value, and whether outreach is appropriate. The assistant can then recommend or trigger follow-up through Email Templates, AI Voice Agents, Customer Groups, Functions, notes, metadata, or human review. Customer Cards help AI Assistants reason from real ecommerce payment context rather than only from a generic decline event. ## Relationship to AI Voice Agents AI Voice Agents can use Customer Card context during payment recovery and support conversations. An AI Voice Agent might call a customer after a failed subscription renewal, a failed trial expiration payment, a high-value declined sale, or an expiring-card warning. The agent can use safe payment reference details, such as card type, last four digits, or expiration context when appropriate, while directing the customer to a secure update flow instead of collecting sensitive payment data in an unsafe way. This makes Customer Cards useful for higher-touch recovery workflows where email alone may not be enough. ## Relationship to Functions Functions can use Customer Card context to extend RevCent workflows with custom logic. A Function might notify a CRM when a high-value customer has a failed payment, send a Slack alert when an important customer needs card update assistance, check an external loyalty system before choosing a recovery path, or update an external marketing platform when a customer enters a payment recovery state. Because Customer Cards are connected to customers, functions can combine card context with customer value, subscription status, purchase history, customer groups, and metadata. This makes Customer Cards useful in both internal RevCent workflows and external business systems. ## Relationship to Payment Profiles Payment Profiles determine how credit card transactions are routed and processed. Customer Cards can provide the stored payment method context that participates in future payment events, while Payment Profiles can determine how those payments should be processed. This matters for subscriptions, trial expiration billing, repeat purchases, recovery attempts, and other workflows where a stored customer payment method may be used. Together, Customer Cards and Payment Profiles help connect customer payment relationships to payment routing, gateway behavior, retry logic, and revenue optimization. ## Relationship to Reporting Google BigQuery makes Customer Card records part of RevCent’s broader reporting ecosystem. The primary table is `customer_card`. It contains customer card records and safe reference fields such as card type, default status, enabled status, expiration date, BIN details, customer relationship, and metadata. Customer Card reporting is most valuable when analyzed as part of the larger customer and payment ecosystem. Because Customer Cards connect to Customers, and Customers connect to sales, subscriptions, trials, transactions, refunds, chargebacks, salvage opportunities, notes, metadata, and customer groups, card-related reporting can help the business understand payment continuity and revenue recovery. Business questions may include: - How many customers have stored payment methods? - How many customers have default cards? - Which customers may need payment method updates? - Which subscriptions may be at risk because of card expiration? - Which customer groups have the highest payment recovery rate? - Which card types or BIN patterns are associated with more declines? - How often do failed payments become recovered revenue? - Which AI Voice Agent or Email Template recovery workflows help customers update payment methods? - How does stored payment method availability affect lifetime value? The important concept is that Customer Cards help make payment continuity measurable. ## Relationship to Customer Lifetime Value Customer Cards can support customer lifetime value by reducing friction in future billing and recovery workflows. A customer with a stored payment relationship may be easier to bill for renewals, easier to convert after a trial, easier to recover after a failed payment, and easier to support during a customer service interaction. This can affect recurring revenue, repeat purchase behavior, recovery rates, subscription continuity, and long-term customer retention. Customer Cards therefore support more than payment storage. They support the customer revenue lifecycle. ## Common Ecommerce Use Cases ### Subscription Renewal Billing A Customer Card can support recurring billing when a customer has an active subscription. This allows the business to attempt renewal billing without requiring the customer to manually re-enter payment information for every renewal. ### Trial Conversion A Customer Card can support payment when a trial expires. This helps trial-based businesses convert trial users into paying customers with less friction. ### Failed Payment Recovery A Customer Card can help identify customers who may need payment update outreach after a failed transaction, declined renewal, failed trial billing attempt, or abandoned purchase attempt. ### Card Expiration Prevention A Customer Card can help identify payment methods that may expire soon. This can support reminder emails, customer portal updates, support outreach, AI Voice Agent calls, or Customer Group assignment before the card causes a renewal failure. ### Customer Support Billing Context A Customer Card can help support teams understand safe payment reference details without seeing raw card data. This helps with billing questions, subscription issues, payment update requests, failed payments, and support-assisted sales. ### High-Value Recovery A Customer Card can support special recovery workflows for high-value customers. If a valuable customer has a failed payment, the business may use AI analysis, voice outreach, support escalation, and personalized email rather than treating the decline as a routine failure. ### Customer Portal Payment Updates A Customer Card can support self-service payment updates through a customer portal. This helps customers keep their payment methods current while reducing support workload. ### AI-Powered Payment Workflows AI Assistants and AI Voice Agents can use Customer Card context to determine which payment issues require email, voice outreach, manual review, customer group updates, functions, or no action. ## Why This Matters in the RevCent Ecosystem Customer Cards help make RevCent a customer-centered ecommerce system rather than a collection of disconnected payment attempts. A stored payment method reference becomes much more valuable when it is connected to the customer, their purchases, subscriptions, trials, renewals, payment outcomes, notes, metadata, AI workflows, customer groups, customer portal activity, and reporting. This creates several ecosystem-level advantages: - Customers can maintain ongoing payment relationships with the business. - Subscriptions and trials can be billed with less friction. - Failed payments can become recoverable events instead of dead ends. - Support teams can understand billing context without seeing raw card data. - AI Assistants can evaluate payment recovery with customer context. - AI Voice Agents can support high-touch payment update conversations. - Email Templates can automate payment update communication. - Customer Groups can represent payment lifecycle states. - Functions can connect card-related workflows to external systems. - Payment Profiles can process future card-based payment activity. - BigQuery can make card-related payment continuity and recovery measurable. Customer Cards are one of the items that connect customer identity to payment continuity, revenue recovery, and long-term ecommerce value. ## Best-Fit Businesses Customer Cards are valuable for ecommerce businesses that need stored payment relationships, recurring billing, trial conversion, customer payment recovery, repeat purchase support, customer portals, subscription management, or payment-focused customer support. They are especially important for businesses with subscriptions, trials, high customer acquisition costs, frequent payment declines, salvage workflows, AI Voice Agent recovery, or customer support teams that need safe billing context. Any business that wants to preserve customer payment continuity while protecting sensitive payment data can benefit from Customer Cards. ## Summary Customer Cards are RevCent items that securely associate customer payment method references with customer records. They help RevCent connect customer identity to stored payment context while keeping raw card data protected. They can support subscription renewals, trial expiration billing, failed payment recovery, salvage workflows, customer support billing context, customer portal payment updates, AI Assistant analysis, AI Voice Agent outreach, Email Template communication, Customer Group segmentation, Functions, Payment Profiles, BigQuery reporting, and lifetime value growth. The most important concept is that a Customer Card is not just a card record. It is a safe payment-reference item that helps RevCent connect customers, payments, subscriptions, trials, recovery workflows, AI, support, and reporting into a connected ecommerce ecosystem. Use the technical links at the top of this file to distinguish between the main ways to interface with or analyze the item: Web App, API, MCP / AI, and BigQuery / Reporting. --- 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.