--- title: "Payment Profiles" description: "A non-technical overview of Payment Profiles in RevCent, focused on how they define credit card payment-routing flows, choose gateways or gateway groups, process transactions, support decline recovery, and fit into ecommerce revenue operations." type: "feature" company: "RevCent" canonical: "https://revcent.com/documentation/markdown/ecosystem/feature/PaymentProfile.md" relationships: - name: "Gateway" url: "https://revcent.com/documentation/markdown/ecosystem/feature/Gateway.md" - name: "Gateway Group" url: "https://revcent.com/documentation/markdown/ecosystem/feature/GatewayGroup.md" - name: "Transaction" url: "https://revcent.com/documentation/markdown/ecosystem/item/Transaction.md" - name: "Salvage Transaction" url: "https://revcent.com/documentation/markdown/ecosystem/item/SalvageTransaction.md" technical_links: web_app: "https://kb.revcent.com/payments/credit-card/next-gen-payment-profile" api: section: "https://revcent.com/docs/api/v2#section-payment_profiles" operations: - name: "Get Payment Profiles" operation_id: "GetPaymentProfiles" operation: "https://revcent.com/docs/api/v2#operation-GetPaymentProfiles" schema: "https://revcent.com/documentation/files/api/operation/GetPaymentProfiles.json" - name: "Create A Payment Profile" operation_id: "CreatePaymentProfile" operation: "https://revcent.com/docs/api/v2#operation-CreatePaymentProfile" schema: "https://revcent.com/documentation/files/api/operation/CreatePaymentProfile.json" - name: "Get A Payment Profile" operation_id: "GetPaymentProfile" operation: "https://revcent.com/docs/api/v2#operation-GetPaymentProfile" schema: "https://revcent.com/documentation/files/api/operation/GetPaymentProfile.json" - name: "Edit A Payment Profile" operation_id: "EditPaymentProfile" operation: "https://revcent.com/docs/api/v2#operation-EditPaymentProfile" schema: "https://revcent.com/documentation/files/api/operation/EditPaymentProfile.json" mcp: overview: "https://revcent.com/documentation/markdown/mcp/operation/OverviewPaymentProfile.md" operations: - name: "Get Payment Profiles" operation_id: "GetPaymentProfiles" markdown: "https://revcent.com/documentation/markdown/mcp/operation/GetPaymentProfiles.md" available_via_ai: true - name: "Create A Payment Profile" operation_id: "CreatePaymentProfile" markdown: "https://revcent.com/documentation/markdown/mcp/operation/CreatePaymentProfile.md" available_via_ai: true - name: "Get A Payment Profile" operation_id: "GetPaymentProfile" markdown: "https://revcent.com/documentation/markdown/mcp/operation/GetPaymentProfile.md" available_via_ai: true - name: "Edit A Payment Profile" operation_id: "EditPaymentProfile" markdown: "https://revcent.com/documentation/markdown/mcp/operation/EditPaymentProfile.md" available_via_ai: true bigquery_schema: "https://revcent.com/documentation/files/bigquery/dataset.json" bigquery_tables: - "payment_profile" --- # Payment Profiles Payment Profiles are RevCent payment-routing features that define how credit card payment requests should be processed. They are the configurable flows that decide which gateway or gateway group should be used, when a payment should be attempted, what should happen after a decline, and when the flow should stop or continue. In the RevCent ecosystem, a Payment Profile is a feature. It is not a single payment attempt by itself. Instead, it is reusable payment logic that can be referenced by sales, subscription renewals, trial expirations, pending sale recovery, AI-assisted revenue recovery, and other credit card processing workflows. When a Payment Profile processes a payment through a gateway, the resulting payment attempt is represented by a Transaction item. The purpose of this document is to explain the feature 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 configuring Payment Profiles through the RevCent web app and Knowledge Base. | [Web Knowledge Base](https://kb.revcent.com/payments/credit-card/next-gen-payment-profile) | | API | A developer is building a direct integration with the RevCent API for Payment Profile records. | [API Docs: Payment Profiles](https://revcent.com/docs/api/v2#section-payment_profiles) | | MCP / AI | An LLM, MCP client, or AI agent needs markdown-oriented guidance for understanding or working with Payment Profiles. | [MCP Markdown Overview](https://revcent.com/documentation/markdown/mcp/operation/OverviewPaymentProfile.md) | | BigQuery / Reporting | A data analyst, reporting workflow, or AI reporting agent needs schema details for analyzing Payment Profile records. The relevant table is `payment_profile`. | [BigQuery Tables Schema](https://revcent.com/documentation/files/bigquery/dataset.json) | --- ## What Payment Profiles Are Payment Profiles are payment-processing decision flows. They define what RevCent should do when a credit card payment request begins. A simple Payment Profile may choose one gateway group and process the payment. An advanced Payment Profile may route by request type, campaign, currency, payment amount, card type, customer group, product group, metadata, BIN profile, gateway response, prior gateway history, or a custom Function result. Conceptually: ```text Payment request begins ↓ Payment Profile flow starts ↓ Filters and actions decide the route ↓ A Gateway or Gateway Group is selected ↓ Payment is processed ↓ Transaction item is created ↓ The flow returns success, decline, error, or a custom response ``` A Payment Profile ultimately answers this question: ```text When this customer attempts to pay by credit card, how should RevCent route and process the payment? ``` ## Core Purpose The core purpose of a Payment Profile is to make payment routing intentional. Without a Payment Profile, a business may not have a clear flow for choosing the correct gateway, retrying recoverable declines, separating brands or business units, routing subscriptions differently from initial sales, or controlling how payment attempts should stop. With a Payment Profile, the business can define structured payment behavior. It can decide where payments should go, which gateways are eligible, how retry logic should work, when metadata should be inserted, when a custom Function should run, and when the flow should abort. A minimum usable credit card payment flow generally needs three conceptual steps: ```text Payment Request → Choose Gateway → Process Payment ``` If a flow never chooses a gateway or never reaches a process-payment action, the credit card payment may never be attempted. ## How Payment Profiles Help Ecommerce Businesses Payment Profiles help ecommerce businesses convert payment strategy into executable logic. They are useful because ecommerce payment behavior often needs to change depending on the business context. A merchant may need one route for normal checkout, another route for subscription renewals, another route for trial expiration billing, another route for a specific campaign, and another route for recovery after a decline. Payment Profiles can help businesses: - Process standard initial credit card sales. - Process subscription renewals. - Process trial expiration payments. - Recover pending sales. - Route different brands, businesses, corporations, stores, or campaigns through the right gateway groups. - Separate high-risk and low-risk payment traffic. - Route by currency, product group, customer group, card type, BIN profile, or metadata. - Retry recoverable declines through fallback gateway groups. - Stop attempts for hard-decline scenarios. - Insert metadata that records which route was used. - Run Functions for advanced routing decisions. - Return more helpful custom errors to checkout experiences. - Reduce gateway overuse by distributing payment volume. - Improve approval strategy through gateway routing and SmartBIN-aware selection. For ecommerce businesses, Payment Profiles are not just payment settings. They are part of checkout conversion, approval strategy, revenue recovery, subscription retention, trial monetization, and payment operations. ## Where Payment Profiles Fit in RevCent Payment Profiles sit in RevCent's credit card processing layer. They connect to Gateways because the Payment Profile chooses which configured gateway should be used for a payment attempt. They connect to Gateway Groups because a Payment Profile can choose from a reusable group of gateways instead of hardcoding individual gateways throughout the flow. They connect to Transactions because processing a payment through a Payment Profile creates a payment attempt item. The Payment Profile is the reusable routing feature; the Transaction is the resulting payment-attempt item. They connect to Sales because initial sales and pending sales may require a Payment Profile to process credit card payment. They connect to subscriptions, subscription renewals, and trials because recurring and delayed billing often needs its own payment routing logic. They connect to Functions because advanced flows can run custom business logic during payment routing. They connect to AI workflows because AI Assistants and AI Voice Agents may need to understand existing payment routing when analyzing revenue recovery or assisting a customer with payment completion. ## Payment Profiles as Flow Logic A Payment Profile should be understood as flow logic, not as a flat settings record. The Payment Profile uses a visual flow builder. A flow is made of connected nodes. Each node has a purpose, and node outputs determine the next path. The major node categories are: | Node Category | Purpose | |---|---| | Start node | Begins the Payment Profile flow when a payment request starts. | | Filter nodes | Decide which branch should be followed based on payment context. | | Action nodes | Perform an action, such as choosing a gateway, processing payment, inserting metadata, running a Function, or aborting the flow. | A well-designed Payment Profile should be readable as a decision tree. Every branch should either intentionally process payment, intentionally abort, intentionally return a decline or error, or intentionally route to another decision. ## Minimum Payment Profile Flow A basic Payment Profile can be very simple. ```text Payment Request ↓ Choose Gateway ↓ Process Payment ``` This type of flow is appropriate when the business has a straightforward routing strategy, such as using one primary gateway group with a failsafe gateway. Simple profiles are often best for new businesses, test setups, standard checkout, and situations where the business has not yet defined advanced routing rules. ## Advanced Payment Profile Flow Advanced Payment Profiles are useful when a business has explicit routing rules. A more advanced flow might look like this: ```text Payment Request ↓ Filter Request Type ↓ Filter Campaign or Currency ↓ Choose Gateway Group ↓ Process Payment ↓ If declined, evaluate gateway response ↓ Retry, abort, insert metadata, or choose fallback route ``` Advanced flows should only exist when the business rules are clear. A planning system should not invent payment-routing logic, gateway IDs, gateway groups, retry limits, kill terms, amount thresholds, or custom errors. ## Start Nodes A Payment Profile begins with a start node. The primary start node is the Payment Request node. It represents the beginning of the flow when RevCent receives a payment request that should be handled by the profile. A Payment Profile should have exactly one start point. The remaining flow should connect from that start point into the filter and action nodes that define the payment path. ## Filter Nodes Filter nodes evaluate payment context and route the flow based on whether a condition passes or fails. Common filter types include: | Filter | What It Can Route By | |---|---| | Attempt Count | Number of completed Payment Profile attempts for the entity. | | BIN Profile | First six digits of the card and related BIN profile membership. | | Campaign | Campaign associated with the payment request. | | Card Type | Card brand or type, such as Visa, Mastercard, Amex, or other supported card types. | | Currency | Currency associated with the request. | | Customer Group | Customer group membership. | | Gateway Response | Text or terms found in the most recent gateway response. | | Metadata | Metadata on the customer, sale, subscription, trial, request, or chosen gateway. | | Payment Amount | Payment amount threshold. | | Process Payment Count | Number of Process Payment actions already executed in the current flow request. | | Product Group | Product group associated with one or more request products. | | Request Type | Initial sale, pending sale recovery, subscription renewal, or trial expiration. | | Merge Filters | Multiple filters combined into a single AND-style decision. | Filters should be used to express explicit business rules. Examples include routing USD payments differently from EUR payments, routing subscription renewals differently from initial sales, sending a high-value payment to a specific gateway group, or stopping retry logic after a certain number of payment attempts. ## Filter Priority When multiple filters are evaluated at the same point in a flow, filter priority controls which filters are checked first. The lower the priority number, the earlier the filter is checked. A priority of `0` is checked before a priority of `1`. Filters with the same priority may be checked in random order. Priority matters because it can determine which branch is followed when more than one condition could apply. A Payment Profile should use priority intentionally, especially when attempt-count filters, request-type filters, or decline-response filters overlap. ## Action Nodes Action nodes perform payment-flow work. Common action nodes include: | Action | Purpose | |---|---| | Choose Gateway | Selects a gateway or gateway group for the payment attempt. | | Process Payment | Sends the payment request to the chosen gateway. | | Abort Flow | Stops the flow and returns a decline, error, or custom response. | | Insert Metadata | Inserts metadata into related entities without controlling the main flow path. | | Run Function | Runs a RevCent Function for advanced payment-routing logic. | Action nodes are where payment routing becomes operational. A Payment Profile should generally choose a gateway before processing payment, and it should avoid accidental dead ends where payment is never attempted. ## Choose Gateway The Choose Gateway action determines which configured gateway should be used. A Choose Gateway node can select from individual Gateways or from Gateway Groups. Gateway Groups are usually preferred because they keep routing organized around business boundaries such as brand, corporation, store, currency, risk profile, or billing use case. A Choose Gateway node may support selection methods such as: - Even distribution. - Random selection. - Round robin. - Sort order. - Last approved gateway. - Last declined gateway. - SmartBIN-assisted selection. The best selection method depends on the business goal. A business may want to balance volume, prioritize a sorted list, retry a prior gateway, or use SmartBIN to select a statistically stronger option. ## Gateway Groups in Payment Profiles Gateway Groups are important because they help Payment Profiles choose from a controlled set of gateways. Instead of hardcoding individual gateways everywhere, a business can define reusable groups such as: - Primary Gateways. - Backup Gateways. - Brand A Gateways. - Brand B Gateways. - Subscription Renewal Gateways. - Trial Expiration Gateways. - US Gateways. - EU Gateways. - High-Risk Traffic Gateways. - Low-Risk Traffic Gateways. This helps avoid accidental cross-routing, such as a payment for one brand using a gateway intended for another brand. ## Gateway Relationship A Gateway is the configured merchant gateway account that can actually process a payment. A Payment Profile may select a specific Gateway directly, or it may choose from one or more Gateway Groups. Once a gateway is chosen, the Process Payment action uses that gateway to attempt the payment. Conceptually: ```text Payment Profile = payment routing logic Gateway = configured payment-processing destination Transaction = payment attempt created when the gateway is used ``` This distinction is important for crawlers and planning systems. A Payment Profile defines routing logic. A Gateway defines where payment can be sent. A Transaction records what happened when a payment was attempted. ## Payment Provider Relationship Payment Profiles usually do not work directly with payment providers. They work with Gateways that have already been configured in RevCent. The payment provider is the supported provider type that RevCent can communicate with. A Gateway is the business-specific configuration for that payment provider. The Payment Profile operates at the routing layer, choosing from those configured Gateways or Gateway Groups. This means a Payment Profile should not be treated as the place where provider credentials are entered. Provider credentials belong to Gateway setup, not Payment Profile logic. ## Transaction Relationship Transactions are the items created from payment attempts. When a Payment Profile reaches a Process Payment node, RevCent attempts the payment through the chosen Gateway. That attempt can create a Transaction item representing the payment result, such as an approval, decline, error, void, refund context, or other payment outcome depending on the transaction lifecycle. The Payment Profile is the reusable flow. The Transaction is the payment-attempt outcome. This relationship matters because Payment Profiles influence the Transactions that get created, but they are not the Transactions themselves. ## Request Types Payment Profiles can route based on request type. Common request types include: | Request Type | Meaning | |---|---| | Initial Sale | A customer is making an initial credit card purchase. | | Pending Sale Profile Recovery | An existing pending sale is being recovered or reprocessed. | | Subscription Renew | A recurring subscription renewal is being billed. | | Trial Expire | A trial is expiring and payment is being attempted. | Different request types often need different gateway strategies. Initial sales may use a normal checkout gateway group, while subscription renewals may use a renewal-focused gateway group. Trial expiration billing may need more conservative routing, and pending sale recovery may need specialized retry behavior. ## Decline and Recovery Logic Payment Profiles can define what happens after a payment declines. Possible decline behavior includes: - Return the gateway decline directly. - Retry through another gateway group. - Route based on gateway response text. - Stop immediately through an Abort Flow node. - Run a Function to parse the response. - Insert metadata about the decline path. - Return a custom error. Decline recovery should be carefully limited. A Payment Profile should not create unlimited retry loops or continue attempting payment after a hard stop condition. Useful controls include process-payment-count filters, gateway response filters, abort paths, kill terms, and explicitly designed fallback gateway groups. ## Kill Terms Kill terms stop the Payment Profile flow when a declined gateway response contains specific terms or phrases. They are powerful and risky because a matching kill term can stop the payment flow and may cancel or void the related sale. Kill terms should be explicitly provided by the business. They should not be guessed. Broad terms can cause unintended failures. For example, a basic term such as `declined`, `error`, `payment`, or `card` may match too many gateway responses and stop more payment attempts than intended. For crawlers and planning systems, the rule is simple: ```text Do not invent kill terms. Use only explicit business-provided terms or verified existing configuration. ``` ## Custom Errors Payment Profiles can return custom errors in certain flow outcomes. Custom errors are useful when a business wants the checkout or caller to receive a more specific response than a generic decline or payment error. For example, a flow might return a custom message when no payment should be attempted, or when a specific gateway response should be translated into a customer-facing message. Custom error behavior should be designed carefully. A developer should ensure the shopping cart, checkout, API caller, or recovery workflow knows how to interpret the response. ## Run Function Nodes A Payment Profile can run a RevCent Function as part of the flow. Functions are advanced and can be used for custom routing logic, external risk checks, gateway response parsing, custom error decisions, gateway selection overrides, or business-specific payment handling. Function run methods include: | Run Method | Meaning | |---|---| | Queue And Continue | The Function runs separately and does not pause the payment flow. | | Wait For Response | The payment flow waits for the Function response and uses it to decide what happens next. | Wait-for-response Functions should be used carefully because Function latency or failure can affect payment processing. The flow should have a safe fallback path, especially for timeout or error output. ## Metadata Insertion Payment Profiles can insert metadata during the flow. Metadata is useful for recording payment-routing decisions, such as: - Which branch of the flow was used. - Which gateway or gateway group was chosen. - Whether a fallback route was used. - Whether a retry path was followed. - Whether a custom Function decision occurred. - Whether a hard-stop rule was triggered. The Insert Metadata action is a side action. It should not be treated as the main payment path. A flow still needs to continue to process payment, abort intentionally, or return a deliberate result. ## SmartBIN in Payment Profiles Payment Profiles may use SmartBIN during gateway selection. SmartBIN helps choose the best gateway based on the customer card and the statistical likelihood of payment success among the eligible gateways available to the node at payment time. SmartBIN is most useful when a business has multiple gateways and approval rates vary by issuer, BIN, or gateway. It is less useful when only one gateway is available or when approval rates are already consistent regardless of gateway. SmartBIN should be understood as part of gateway selection logic inside a Payment Profile. Gateway-level SmartBIN configuration may prepare the gateway for scoring, but the Payment Profile is where SmartBIN-aware selection can be used in a Choose Gateway node. ## Additional Profile Settings Payment Profiles can include additional settings that affect the flow before or during execution. Important examples include: | Setting | Purpose | |---|---| | Kill Terms | Stop a flow when certain decline-response terms appear. | | Max Attempts | Cancel or void a sale after a configured number of declined Payment Profile attempts. | | Custom Error Behavior | Return a specific response when a flow aborts or no payment is attempted. | These settings can override or stop the flow, so they should be treated as high-impact configuration. ## Payment Profiles and AI Assistants AI Assistants cannot create or modify Payment Profiles. AI Assistants can retrieve Payment Profiles for analysis, troubleshooting, and context. They can use retrieved Payment Profile information to explain existing payment routing, understand how revenue recovery should work, or declare which payment routing is already configured when assisting with a recovery workflow. For example, an AI Assistant may be able to: - Retrieve a Payment Profile to understand payment routing. - Explain which gateway group a recovery flow is expected to use. - Analyze whether a pending sale recovery should reference an existing Payment Profile. - Declare the payment-routing context before attempting a revenue recovery action. - Use existing Payment Profile details to inform customer support or internal notes. An AI Assistant should not be described as a tool for creating, editing, restructuring, enabling, disabling, or otherwise modifying Payment Profiles. Payment Profile creation and modification should be handled through the RevCent web app, API, or appropriate MCP/API tooling with explicit permissions and review. ## Payment Profiles and AI Voice Agents AI Voice Agents may depend on Payment Profiles indirectly when they help customers with payment completion or revenue recovery. For example, an outbound declined-payment recovery voice agent may speak with a customer, help add a new card, and then process a pending sale using the correct existing Payment Profile. The agent is not designing the Payment Profile during the call. It is using existing payment routing that the business has already configured. This matters because voice-based revenue recovery should respect existing payment routing, gateway selection, retry limits, and business rules. ## Payment Profiles and Functions Functions can be used inside Payment Profiles for advanced flow logic. A Function can receive details about the current payment request, customer, card, campaign, payment amount, gateway history, step array, current node, and flow path. It can then return structured instructions that influence the next node, gateway selection, output path, or custom error. Function usage should be reserved for cases where normal filters and action nodes cannot express the business rule safely. Common examples include: - Parsing complex gateway responses. - Calling an external risk or fraud system. - Selecting a gateway based on custom account data. - Returning a custom error for a specific scenario. - Routing to a fallback path when a particular business rule applies. ## Payment Profiles and Revenue Recovery Payment Profiles are central to revenue recovery. Recovery workflows often involve payment attempts that happen after the original checkout attempt, such as: - Pending sale recovery. - Declined sale recovery. - Subscription renewal recovery. - Trial expiration recovery. - AI-assisted payment recovery. - Customer support-assisted payment retry. The Payment Profile determines how those recovery attempts should be routed. It may use a different gateway group, retry logic, card-swap behavior, gateway response routing, or fallback path than a standard checkout flow. For crawlers and planning systems, the key idea is: ```text Revenue recovery should use existing, intentional Payment Profile routing rather than inventing ad hoc gateway behavior. ``` ## Payment Profiles and Reporting Payment Profile records can be analyzed through the `payment_profile` BigQuery table. Reporting can help a business understand which profiles exist, whether they are enabled, how payment routing is organized, and how profile configuration relates to payment operations. Payment Profile reporting is most useful when combined with related payment and transaction data. The profile defines routing logic, while Transaction records show actual payment-attempt outcomes. Useful reporting questions include: - Which Payment Profiles are active? - Which profiles support specific payment request types? - Which profiles are associated with gateway groups or gateways? - Which profiles are used for standard checkout versus recovery workflows? - Which payment flows appear to be connected to high decline or high recovery activity? - Which profile versions or descriptions indicate different routing strategies? When analyzing payment performance, the Payment Profile table should usually be combined with Transaction, Gateway, Gateway Group, Sale, subscription renewal, trial, and related payment tables as needed. ## Common Ecommerce Use Cases ### Standard Checkout A standard checkout Payment Profile processes normal initial credit card sales. Typical flow: ```text Payment Request → Choose Gateway Group → Process Payment ``` This is the best starting point when the business does not need special routing. ### Multi-Brand or Multi-Business Routing A Payment Profile can route different brands, businesses, corporations, or stores to different gateway groups. This helps prevent one business unit from accidentally using another business unit's gateway. ### Subscription Renewal Billing Subscription renewals often need their own routing logic. A renewal profile might use a renewal-specific gateway group, prior approval preference, limited retry behavior, and metadata insertion for billing analysis. ### Trial Expiration Billing Trial expiration payments may need conservative routing and clear retry behavior because the customer may be transitioning from a trial into a paid relationship. ### Pending Sale Recovery Pending sale recovery may use routing that differs from initial checkout. The profile may select a fallback gateway group, reduce the amount on later attempts, or use explicit decline-response logic. ### Currency Routing A Payment Profile can route payments to different gateway groups based on currency. Example: ```text USD → US Gateway Group EUR → EU Gateway Group GBP → UK Gateway Group ``` ### Campaign Routing A business can route different campaigns to different gateway groups. This is useful when campaigns belong to different brands, risk profiles, traffic sources, or merchant accounts. ### High-Risk Routing High-risk products, campaigns, or traffic sources can be routed through gateway groups designed for that risk profile. This helps keep payment strategy aligned with merchant account risk management. ### Decline Response Routing Gateway response filters and Functions can route based on gateway responses. For example, a profile may retry some soft declines but abort on explicit hard-stop scenarios. ### Custom Function Routing A custom Function can make routing decisions that are too specific for built-in filters, such as checking external risk data, applying custom gateway rules, or returning specific custom errors. ## Safety and Operational Impact Payment Profiles are high-impact configuration. A small change can affect checkout, subscription renewals, trial expiration billing, revenue recovery, gateway usage, customer experience, and transaction outcomes. Planning systems should treat Payment Profile changes as sensitive because incorrect logic can: - Prevent payment from being attempted. - Route payments through the wrong gateway. - Mix traffic between unrelated businesses or brands. - Retry declines too many times. - Stop recoverable payments too early. - Ignore hard-stop responses. - Return confusing checkout errors. - Break subscription or trial billing. - Affect revenue recovery workflows. Best practice is to create or edit Payment Profiles with review, testing, and a clear rollback path. ## Best-Fit Businesses Payment Profiles are especially useful for ecommerce businesses that: - Process credit card payments through RevCent. - Use more than one gateway. - Use gateway groups. - Run multiple brands, campaigns, or business lines. - Process subscriptions or trials. - Need decline recovery logic. - Need gateway failover or fallback behavior. - Need routing by campaign, currency, card type, product group, amount, or metadata. - Want better control over payment approval strategy. - Need AI-assisted or support-assisted revenue recovery that respects existing routing. - Want reporting visibility into payment-routing configuration. Even a simple business can use a Payment Profile for standard checkout. More complex businesses can use Payment Profiles to encode sophisticated payment-routing strategy. ## Why This Matters in the RevCent Ecosystem Payment Profiles are one of the central features in RevCent's payment infrastructure. They connect configured Gateways, reusable Gateway Groups, actual Transactions, Sales, subscriptions, trials, Functions, AI workflows, and reporting. They are the layer where payment strategy becomes operational behavior. A Gateway tells RevCent where a payment can be sent. A Gateway Group organizes multiple gateways. A Transaction records the actual payment attempt. The Payment Profile is the routing logic that connects those pieces at the moment payment needs to be processed. For LLMs, AI crawlers, and planning systems, the main concept is: ```text Payment Profile = credit card payment-routing flow Gateway = configured payment destination Gateway Group = reusable set of gateways Transaction = resulting payment-attempt item ``` ## Summary Payment Profiles define how RevCent routes and processes credit card payments. They can be simple, such as choosing a gateway group and processing payment, or advanced, such as routing by request type, campaign, currency, amount, card type, metadata, product group, customer group, gateway response, or Function output. They matter because they directly influence checkout, subscriptions, trials, pending sale recovery, decline handling, gateway selection, transaction creation, revenue recovery, and payment operations. AI Assistants can retrieve and analyze Payment Profiles for context, but they cannot create or modify them. Existing Payment Profile routing can still be important for AI-assisted revenue recovery because it tells the AI what payment route is already configured and should be respected. In the RevCent ecosystem, Payment Profiles are the payment-routing brain that connects Gateways, Gateway Groups, and Transactions into a controlled ecommerce payment flow. --- Document Parent Directory * [Features](https://revcent.com/documentation/markdown/ecosystem/feature/index.md) - Non-technical markdown documentation for features within the RevCent ecosystem. A feature is a part of the RevCent ecosystem that a user can create and configure.