--- title: "Gateways" description: "A non-technical overview of Gateways in RevCent, focused on how configured merchant gateway accounts support credit card processing, payment routing, gateway groups, transactions, cascade rules, 3DS, SmartBIN, and reporting." type: "feature" company: "RevCent" canonical: "https://revcent.com/documentation/markdown/ecosystem/feature/Gateway.md" relationships: - name: "Payment Profile" url: "https://revcent.com/documentation/markdown/ecosystem/feature/PaymentProfile.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" technical_links: web_app: "https://kb.revcent.com/en/payments/credit-card/gateway" api: section: "https://revcent.com/docs/api/v2#section-gateways" operations: - name: "Get Site Gateways" operation_id: "GetSiteGateways" operation: "https://revcent.com/docs/api/v2#operation-GetSiteGateways" schema: "https://revcent.com/documentation/files/api/operation/GetSiteGateways.json" - name: "Get A Site Gateway" operation_id: "GetSiteGateway" operation: "https://revcent.com/docs/api/v2#operation-GetSiteGateway" schema: "https://revcent.com/documentation/files/api/operation/GetSiteGateway.json" - name: "Get User Gateways" operation_id: "GetUserGateways" operation: "https://revcent.com/docs/api/v2#operation-GetUserGateways" schema: "https://revcent.com/documentation/files/api/operation/GetUserGateways.json" - name: "Create A User Gateway" operation_id: "CreateUserGateway" operation: "https://revcent.com/docs/api/v2#operation-CreateUserGateway" schema: "https://revcent.com/documentation/files/api/operation/CreateUserGateway.json" - name: "Get A User Gateway" operation_id: "GetUserGateway" operation: "https://revcent.com/docs/api/v2#operation-GetUserGateway" schema: "https://revcent.com/documentation/files/api/operation/GetUserGateway.json" - name: "Edit A User Gateway" operation_id: "EditUserGateway" operation: "https://revcent.com/docs/api/v2#operation-EditUserGateway" schema: "https://revcent.com/documentation/files/api/operation/EditUserGateway.json" mcp: overview: "https://revcent.com/documentation/markdown/mcp/operation/OverviewGateway.md" operations: - name: "Get Site Gateways" operation_id: "GetSiteGateways" markdown: "https://revcent.com/documentation/markdown/mcp/operation/GetSiteGateways.md" available_via_ai: true - name: "Get A Site Gateway" operation_id: "GetSiteGateway" markdown: "https://revcent.com/documentation/markdown/mcp/operation/GetSiteGateway.md" available_via_ai: true - name: "Get User Gateways" operation_id: "GetUserGateways" markdown: "https://revcent.com/documentation/markdown/mcp/operation/GetUserGateways.md" available_via_ai: true - name: "Create A User Gateway" operation_id: "CreateUserGateway" markdown: "https://revcent.com/documentation/markdown/mcp/operation/CreateUserGateway.md" available_via_ai: true - name: "Get A User Gateway" operation_id: "GetUserGateway" markdown: "https://revcent.com/documentation/markdown/mcp/operation/GetUserGateway.md" available_via_ai: true - name: "Edit A User Gateway" operation_id: "EditUserGateway" markdown: "https://revcent.com/documentation/markdown/mcp/operation/EditUserGateway.md" available_via_ai: true bigquery_schema: "https://revcent.com/documentation/files/bigquery/dataset.json" bigquery_tables: - "gateway" --- # Gateways Gateways are RevCent payment configuration features that represent a business's actual credit card gateway, merchant account, MID, or processor account inside RevCent. They are the gateway records a business configures so RevCent can route credit card payment attempts to the correct third-party payment provider. In the RevCent ecosystem, a Gateway is a feature. It does not represent one payment attempt by itself. Instead, it defines a reusable payment-processing connection that can be selected by Payment Profiles, organized with Gateway Groups, and used to create Transactions when credit card payments are attempted. 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, creating, or editing gateways through the RevCent web app and Knowledge Base. | [Web Knowledge Base](https://kb.revcent.com/en/payments/credit-card/gateway) | | API | A developer is building a direct integration with the RevCent API for gateway records. | [API Docs: Gateways](https://revcent.com/docs/api/v2#section-gateways) | | MCP / AI | An LLM, MCP client, or AI agent needs markdown-oriented guidance for understanding or working with gateways. | [MCP Markdown Overview](https://revcent.com/documentation/markdown/mcp/operation/OverviewGateway.md) | | BigQuery / Reporting | A data analyst, reporting workflow, or AI reporting agent needs schema details for analyzing gateway records. The relevant table is `gateway`. | [BigQuery Tables Schema](https://revcent.com/documentation/files/bigquery/dataset.json) | --- ## What Gateways Are Gateways are the configured payment gateway records that belong to a RevCent user account. A payment provider may exist at the platform level, but a Gateway is the business-specific configuration that connects RevCent to that business's own merchant gateway account. It can represent a specific processor, merchant account, MID, brand, region, business line, or payment routing role. Conceptually: ```text Payment provider ↓ Business configures its own Gateway ↓ Payment Profile can select that gateway ↓ Gateway is used for a payment attempt ↓ Transaction item is created ``` This makes a Gateway one of the core building blocks of credit card processing in RevCent. ## Core Purpose The core purpose of a Gateway is to tell RevCent where and how a credit card payment can be processed. A business must have a merchant gateway account with a third-party payment provider before configuring the corresponding Gateway in RevCent. The Gateway stores the configuration, status, credentials path, cost assumptions, rules, metadata, and routing context that RevCent needs in order to use that provider during payment processing. Without a Gateway, RevCent may have no configured credit card destination for a payment attempt. With one or more Gateways, RevCent can support more advanced payment strategies, including multi-gateway routing, backup gateway logic, payment profile flows, gateway groups, cascade rules, SmartBIN, 3DS-aware checkout, and gateway-level reporting. ## How Gateways Help Ecommerce Businesses Gateways help ecommerce businesses connect their real payment infrastructure to RevCent. A simple store may only need one gateway. A more advanced business may have several gateways across different brands, products, processors, countries, MIDs, risk profiles, subscription flows, or recovery strategies. Gateways are useful because they let the business organize payment processing around real operational needs: - Primary and backup gateways. - Brand-specific merchant accounts. - Subscription-specific gateways. - Trial and renewal payment strategies. - High-risk or low-risk transaction routing. - Regional routing. - Gateway capacity management. - Processor cost awareness. - MID protection. - 3DS-specific routing. - SmartBIN approval optimization. - Payment failure and recovery strategies. For ecommerce businesses, gateway configuration is not just a setup step. It affects approval rates, decline rates, revenue recovery, customer experience, gateway health, and operational risk. ## Where Gateways Fit in RevCent Gateways fit inside RevCent's payments layer. They connect to Payment Profiles because Payment Profiles define how a payment should be routed. A Payment Profile may choose a specific gateway, choose from a Gateway Group, use fallback behavior, apply routing logic, or use advanced selection tools such as SmartBIN. They connect to Gateway Groups because a Gateway Group can organize multiple Gateways into a reusable set. This lets payment flows select from a group rather than hardcoding one individual gateway everywhere. They connect to Transactions because a Transaction is the item created when a payment is attempted through a gateway. The gateway is the configured feature; the transaction is the resulting payment-attempt item. They connect to Sales because sales often create the need for credit card processing. When a sale is created or processed, a Payment Profile may route the payment to one of the configured gateways. They connect to subscriptions, trials, and renewals because recurring or delayed billing may also depend on gateway routing. They connect to reporting because gateway configuration and gateway usage help the business understand how its payment infrastructure is performing. ## Gateway vs Payment Provider A Gateway should not be confused with the underlying payment provider. A payment provider is the supported provider type or integration type RevCent knows how to communicate with. In technical API or MCP schemas, this provider-level concept may be referred to as a Site Gateway. A Gateway is the business's actual configured merchant gateway account, merchant account, or MID for that payment provider. Conceptually: ```text Payment Provider = supported provider type, also called Site Gateway in some technical schemas Gateway = business-specific configured gateway/MID ``` For example, RevCent may support several payment providers. A business then creates one or more Gateways tied to the providers it actually uses. This distinction matters because an MCP or setup workflow may first need to identify the correct payment provider, then help create the business-specific Gateway through the appropriate secure credential flow. ## Gateway Credentials Gateway credentials are sensitive and should be handled carefully. A Gateway may require provider-specific credentials such as API keys, transaction keys, login IDs, merchant credentials, processor tokens, or similar sensitive data. These credentials vary depending on the selected payment provider. The conceptual rule for AI and MCP workflows is simple: do not ask the user to paste raw gateway credentials directly into a chat conversation. Secure credential collection should happen through the appropriate secure form or secure credential workflow. The Gateway record is the RevCent configuration that points to the usable gateway, but credential handling should remain protected. ## Live Mode and Test Mode Gateway credentials and RevCent API mode must align. If a business wants to process live payments, it should use live gateway credentials and a RevCent API account configured for live mode. If a business wants to run test transactions, it should use test gateway credentials and a RevCent API account configured for test mode. This distinction matters because using the wrong combination can cause payments to be sent to the wrong gateway environment or fail unexpectedly. For crawlers and planning systems, the important concept is that Gateways are environment-sensitive payment configuration records. A live gateway configuration should be treated differently from a test gateway configuration. ## Common Gateway Settings A Gateway can include general details that help identify and manage the gateway. Common settings include name, description, status, payment provider, merchant account ID or MID, acquirer BIN information, analytic cap, Gateway Group membership, custom descriptors, metadata, gateway credentials, fee assumptions, and cascade rules. The name should be clear enough for humans, MCP workflows, and payment profile builders to understand the gateway's role. A good gateway name might identify the brand, provider, MID, region, and routing purpose. Examples: ```text Brand A - NMI Primary MID Brand A - NMI Backup MID Subscription Renewals - Primary Gateway EU Store - Checkout.com 3DS Gateway Trial Recovery - Backup Gateway ``` Poor names such as `Gateway`, `Primary`, or `Test` make payment routing harder to understand later. ## Gateway Status A Gateway has a status that controls whether it should be available for use. A disabled gateway should not be relied on for active processing. A gateway may be created disabled while credentials, rules, payment profile routing, or testing are still being reviewed. For live ecommerce operations, enabling or disabling a gateway can affect checkout, subscription renewals, trial billing, salvage workflows, and payment recovery flows. AI and MCP planning systems should treat gateway status changes as operationally important because they may affect revenue processing. ## Gateway Groups Gateway Groups are related features that organize multiple Gateways together. A Gateway Group is useful when a business wants a Payment Profile to select from a set of gateways rather than one specific gateway. Conceptually: ```text Gateway A Gateway B Gateway C ↓ Gateway Group ↓ Payment Profile chooses from the group ``` Gateway Groups are especially useful for multi-gateway routing, fallback strategies, SmartBIN strategies, brand-specific gateway sets, and capacity management. The relationship is important: a Gateway is the configured payment endpoint, while a Gateway Group is a grouping feature that can make several gateways available to routing logic. ## Payment Profiles Payment Profiles are the features that decide how credit card payments should be processed. A Gateway can exist in RevCent, but the Payment Profile determines when and how that gateway is selected during a payment flow. A Payment Profile may: - Select one specific gateway. - Choose from a Gateway Group. - Route by payment amount, product, campaign, customer, card, BIN, risk, or other logic. - Use fallback paths when a gateway fails or declines. - Use SmartBIN to select an eligible gateway. - Avoid a gateway when cascade rules fail. - Process or retry payment through the selected gateway. Conceptually: ```text Sale or payment request ↓ Payment Profile flow ↓ Gateway selection logic ↓ Gateway eligibility checks ↓ Transaction attempt ``` This relationship is central to the RevCent payment ecosystem. Gateways define where payments can go. Payment Profiles define how RevCent decides where payments should go. ## Transactions Transactions are the payment-attempt items created when RevCent processes credit card activity through a gateway. A Gateway is a reusable configuration feature. A Transaction is the operational item that records a specific charge, authorization, capture, decline, refund-related activity, or other gateway payment result. Conceptually: ```text Gateway = configured payment destination Transaction = payment attempt/result through that destination ``` This distinction matters for AI crawlers and reporting systems. When a business wants to understand how a gateway is configured, it should look at Gateways. When it wants to understand what happened during actual payment processing, it should look at Transactions and related sales/payment records. ## Gateway Fees and Cost Awareness Gateways can store fee-related fields such as discount rate, success transaction fee, and failure transaction fee. These fields help the business understand payment cost assumptions and gateway economics. They do not replace the payment provider's actual billing statements, but they are useful context for internal reporting, gateway comparison, and payment strategy. For example, a business may want to know whether one gateway has better approval performance but higher cost, or whether a backup gateway should only be used under certain circumstances. Gateway fee context helps turn gateway routing into a business decision rather than only a technical routing decision. ## Merchant Account and MID Context A Gateway may represent a specific merchant account or MID. This is important because many ecommerce businesses use more than one MID. Different MIDs may be associated with different brands, processors, countries, risk levels, product lines, or business units. A clear merchant account ID or MID helps humans and AI systems distinguish one gateway from another. It also helps with gateway health, processor communication, dispute review, and internal reporting. ## Custom Descriptors Custom descriptors can define the business details that may be passed to supported gateways or used in customer-facing communication. Descriptor details may include information such as business name, email, URL, phone, address, city, state, and postal code. Good descriptors can reduce customer confusion by helping customers recognize a charge. Poor or unclear descriptors can increase support requests, refunds, and chargeback risk. Custom descriptors should only be enabled when the business understands whether the selected gateway or processor supports them. ## Metadata Gateways can use metadata to store custom name/value context. Gateway metadata can help with internal organization, reporting, automation, and advanced workflows. For example, a business might store internal routing labels, brand identifiers, 3DS-related keys, operational notes, or gateway classification values. Metadata should be used intentionally. It should not contain raw secrets or unprotected credentials. For AI and planning systems, gateway metadata can help explain why a gateway exists and when it should be used. ## Global Cascade Rules Global cascade rules are gateway-level eligibility controls. They can override or influence individual payment profile cascade rules across payment profiles for a gateway. This is especially useful when using next-generation Payment Profiles where gateway selection may be more dynamic. Cascade rules help a business decide whether a gateway should be allowed or denied during payment routing. They are useful for protecting gateways from overuse, decline spikes, chargeback concentration, processor maintenance windows, or unwanted processing patterns. Conceptually: ```text Payment Profile considers gateway ↓ Gateway cascade rules are checked ↓ Gateway is allowed or denied ↓ Payment Profile continues with eligible gateway logic ``` ## Revenue Rules Revenue rules are cascade rules that evaluate payment activity over a past time period. They can use sources such as this gateway, all gateways, or the active payment profile step. They can evaluate captured transactions, declined transactions, charged-back transactions, all transactions, or the active step amount. They can calculate count, percent, or sum across a time range such as hours, days, weeks, or months. Examples of business intentions include: ```text Do not use this gateway after it captures too much volume today. Do not use this gateway if decline count spikes in the last hour. Do not use this gateway if chargeback percentage exceeds a threshold. Do not use this gateway if total attempts exceed an internal limit. ``` Revenue rules help turn gateway health into automated routing decisions. ## Time Rules Time rules allow or deny gateway usage based on weekday and time range. RevCent gateway time rules use GMT / UTC time. Time rules can be useful for processor maintenance windows, business policies, region-specific schedules, MID pacing, or known low-performing time periods. For example, a business may choose not to route payments to a certain gateway during a specific weekly window. Time rules are another way Gateways become more than static credentials. They become policy-aware payment routing components. ## 3DS Authentication Some gateways support 3DS v2 authentication. 3DS can require browser-side work before RevCent processes a payment. A checkout page may need to request 3DS values from a provider-specific SDK or endpoint, then pass those values into the RevCent sale create request inside the `three_ds` object. 3DS is not a simple on/off feature for all gateways. It depends on the payment provider, the browser implementation, the fields returned by the 3DS flow, and how those fields are mapped to RevCent's payment request. For AI crawlers and planning systems, the key idea is that Gateways can affect how 3DS must be implemented. A gateway may require a specific 3DS SDK, specific field mapping, or gateway-specific metadata. ## 3DS Pre-Purchase Gateway Selection A business using multiple 3DS-capable gateways may need to know which gateway RevCent is likely to use before the final sale create call. RevCent supports a pattern where the business estimates a sale with gateway inclusion enabled. The estimate can return a gateway object identifying the gateway that would be used for the eventual payment attempt. That gateway ID can then be used inside the `three_ds` object when creating the sale. Important conceptual limits: - This is an advanced flow. - It is most relevant when using next-generation Payment Profiles. - The returned gateway is a pre-purchase estimate, not a guaranteed final processing result. - The gateway ID should be included inside the `three_ds` object when used for this purpose. - The gateway may be preferred but still not used if the final payment profile flow rejects it. This flow helps businesses that use multiple 3DS SDK keys or gateway-specific 3DS browser integrations. ## SmartBIN SmartBIN is an advanced routing capability that can help select the gateway with the strongest approval likelihood for a specific payment request. SmartBIN is most useful when the business has multiple gateways and payment performance varies by issuer, BIN, card brand, gateway, acquirer, or processor. Gateways can store SmartBIN-related metadata, such as merchant category code, processor, and card-brand-specific MID, BIN, and acquirer details. However, gateway-level SmartBIN metadata is not enough by itself. SmartBIN routing also depends on account enablement and Payment Profile configuration. Conceptually: ```text Eligible Gateways ↓ SmartBIN evaluates gateway performance context ↓ Payment Profile chooses a strong candidate ↓ Transaction is attempted ``` AI and MCP workflows should not invent SmartBIN values. Processor, acquirer, MID, BIN, and MCC information should come from the business or authoritative payment records. ## Available Gateway Providers RevCent supports multiple payment payment provider types. The Knowledge Base lists examples such as Adyen, Authorize.net, Braintree, Cardpointe, Checkout.com, Cybersource, FluidPay, Elavon Converge, Maverick, NAB Transact, NMI, Pathly, PayJunction, PaySafe, PSiGate, and Pinwheel. Some providers support 3DS v2. Gateway availability and provider capabilities may change over time, so implementation workflows should use the current RevCent API, MCP operation guidance, or web app when selecting the exact supported provider. ## Gateways and AI Assistants AI Assistants may need to understand Gateways when analyzing payment workflows, reviewing existing payment routing, retrieving Payment Profiles for context, or explaining transaction outcomes. AI Assistants cannot create, edit, modify, or otherwise manage Payment Profiles. They may retrieve Payment Profiles for analysis, troubleshooting, revenue recovery context, or for declaring which payment routing should be used when a permitted revenue recovery action depends on an existing Payment Profile. An AI Assistant should treat gateways as sensitive payment infrastructure. It should avoid collecting credentials directly, avoid making live payment routing changes without clear intent, and avoid inventing gateway rules or thresholds. Good AI usage includes: - Explaining which gateway is used in an existing payment flow. - Retrieving an existing Payment Profile to understand payment routing. - Declaring which existing Payment Profile or routing path should be used during a permitted revenue recovery workflow. - Comparing gateway purpose and role. - Summarizing gateway configuration. - Recommending safe questions for a human or MCP workflow before changing routing. - Using BigQuery to report on configured gateway records. High-impact changes, such as enabling a gateway, modifying credentials, changing cascade rules, or creating/modifying Payment Profiles, should be treated as operationally important because they can affect live payment behavior. AI Assistants should not create or modify Payment Profiles. ## Gateways and Functions Functions can support gateway-related workflows when custom logic is needed. For example, a Function might help prepare external gateway metadata, notify an operations team when a gateway-related threshold is reached, sync gateway context with another system, or support a custom payment-routing decision around a Payment Profile workflow. Functions should not be used to expose raw gateway secrets or bypass secure credential handling. For crawlers and AI planners, the important concept is that Functions can extend gateway-related automation, while the Gateway itself remains the configured payment feature. ## Gateways and Reporting The relevant BigQuery table for Gateways is `gateway`. This table is useful when a reporting workflow needs to analyze gateway records as configured features. Examples include gateway inventory, enabled or disabled gateways, gateway naming, gateway configuration context, fee assumptions, grouping context, and payment-routing readiness. Gateway reporting becomes more useful when combined conceptually with related payment data, such as Transactions, Sales, chargebacks, refunds, and payment profile results. Examples of useful gateway-related reporting questions include: ```text Which gateways are configured? Which gateways are enabled? Which gateways belong to which business purpose or group? Which gateways are used for active payment strategies? Which gateways have cost assumptions configured? Which gateways should be reviewed before routing live traffic? ``` For payment performance, the gateway table alone is not enough. A business should analyze Transactions and other payment outcome records alongside gateway records to understand approval rate, decline rate, capture volume, chargebacks, refunds, and revenue recovery. ## Why This Matters in the RevCent Ecosystem Gateways matter because they connect RevCent's payment intelligence to the real payment infrastructure of an ecommerce business. Payment Profiles, Gateway Groups, Transactions, SmartBIN, cascade rules, 3DS flows, sales, subscriptions, trials, and recovery workflows all depend on gateways being configured clearly and safely. A poorly named or poorly configured gateway can make payment routing confusing or risky. A well-designed set of Gateways can help the business route payments more intentionally, protect MIDs, improve fallback strategies, and understand payment performance. For LLMs, AI crawlers, and planning systems, Gateways should be understood as reusable payment-processing configuration features that enable payment flows but are not themselves individual payment events. ## Best-Fit Businesses Gateways are important for any RevCent business that processes credit cards. They are especially important for businesses that: - Use more than one gateway or MID. - Need backup payment routing. - Operate multiple brands, products, or stores. - Process subscriptions or trials. - Need higher approval-rate strategy. - Want to manage gateway volume or chargeback exposure. - Need 3DS-capable payment flows. - Want payment profile routing instead of simple one-gateway processing. - Need reporting around configured payment infrastructure. For simple businesses, one Gateway may be enough. For more complex businesses, Gateways become part of a broader payment architecture. ## Summary Gateways are RevCent's configured gateway records for a business's actual merchant accounts, processors, or MIDs. They define where credit card payments can be sent, while Payment Profiles define how and when those gateways are selected. They can be organized with Gateway Groups, protected with cascade rules, prepared for SmartBIN, used in 3DS flows, and connected to Transactions when payment attempts occur. Use the technical links at the top of this file to distinguish between the main ways to interface with the feature: Web App, API, MCP / AI, and BigQuery / Reporting. --- 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.