--- title: "Customer Portals" description: "A non-technical overview of Customer Portals in RevCent, focused on secure customer self-service, account access, payment method updates, subscription and trial management, failed payment recovery, Tracking Domain configuration, and Customer record relationships." type: "feature" company: "RevCent" canonical: "https://revcent.com/documentation/markdown/ecosystem/feature/CustomerPortal.md" relationships: - name: "Tracking Domain" url: "https://revcent.com/documentation/markdown/ecosystem/feature/TrackingDomain.md" - name: "Customer" url: "https://revcent.com/documentation/markdown/ecosystem/item/Customer.md" technical_links: web_app: "https://kb.revcent.com/en/customer/customer-portal" api: section: "https://revcent.com/docs/api/v2#section-customer_portals" operations: - name: "Get Customer Portals" operation_id: "GetCustomerPortals" operation: "https://revcent.com/docs/api/v2#operation-GetCustomerPortals" schema: "https://revcent.com/documentation/files/api/operation/GetCustomerPortals.json" - name: "Create A Customer Portal" operation_id: "CreateCustomerPortal" operation: "https://revcent.com/docs/api/v2#operation-CreateCustomerPortal" schema: "https://revcent.com/documentation/files/api/operation/CreateCustomerPortal.json" - name: "Get A Customer Portal" operation_id: "GetCustomerPortal" operation: "https://revcent.com/docs/api/v2#operation-GetCustomerPortal" schema: "https://revcent.com/documentation/files/api/operation/GetCustomerPortal.json" - name: "Edit A Customer Portal" operation_id: "EditCustomerPortal" operation: "https://revcent.com/docs/api/v2#operation-EditCustomerPortal" schema: "https://revcent.com/documentation/files/api/operation/EditCustomerPortal.json" - name: "Delete A Customer Portal" operation_id: "DeleteCustomerPortal" operation: "https://revcent.com/docs/api/v2#operation-DeleteCustomerPortal" schema: "https://revcent.com/documentation/files/api/operation/DeleteCustomerPortal.json" mcp: overview: "https://revcent.com/documentation/markdown/mcp/operation/OverviewCustomerPortal.md" operations: - name: "Get Customer Portals" operation_id: "GetCustomerPortals" markdown: "https://revcent.com/documentation/markdown/mcp/operation/GetCustomerPortals.md" available_via_ai: true - name: "Create A Customer Portal" operation_id: "CreateCustomerPortal" markdown: "https://revcent.com/documentation/markdown/mcp/operation/CreateCustomerPortal.md" available_via_ai: true - name: "Get A Customer Portal" operation_id: "GetCustomerPortal" markdown: "https://revcent.com/documentation/markdown/mcp/operation/GetCustomerPortal.md" available_via_ai: true - name: "Edit A Customer Portal" operation_id: "EditCustomerPortal" markdown: "https://revcent.com/documentation/markdown/mcp/operation/EditCustomerPortal.md" available_via_ai: true - name: "Delete A Customer Portal" operation_id: "DeleteCustomerPortal" markdown: "https://revcent.com/documentation/markdown/mcp/operation/DeleteCustomerPortal.md" available_via_ai: true --- # Customer Portals Customer Portals are RevCent features that give customers a secure, customer-facing place to access and manage selected parts of their account. A Customer Portal connects RevCent customer data to a controlled self-service experience. Depending on the permissions configured by the business, customers can view account-related information, update contact details, update payment methods, manage subscriptions, manage trials, update shipping information, reset passwords, confirm portal registration, and pay certain failed payment balances. The important idea is that the Customer Portal is not just an internal admin view. It is a public-facing feature that lets the end customer interact with selected RevCent records through a secure registration and login flow. ## Technical Links | Area | Link | |---|---| | Web App | `https://kb.revcent.com/en/customer/customer-portal` | | API | `https://revcent.com/docs/api/v2#section-customer_portals` | | MCP / AI | `https://revcent.com/documentation/markdown/mcp/operation/OverviewCustomerPortal.md` | ## Why Customer Portals Are a Feature Customer Portals are a feature because they are configurable parts of a RevCent account. A business creates and configures a portal. The configuration determines the portal name, status, display settings, domain behavior, customer access rules, email templates, SMTP sender, reCAPTCHA settings, customer filters, and customer permissions. The portal then becomes the customer-facing access layer for selected customer actions. Conceptually: ```text Customer Portal configuration ↓ Customer registers or logs in securely ↓ RevCent matches the customer to a Customer record ↓ Portal permissions determine what the customer can do ↓ Customer performs allowed self-service actions ``` This makes Customer Portals different from Customer records. The Customer record is the underlying item that stores customer identity and lifecycle information. The Customer Portal is the configurable feature that gives the customer a secure way to interact with that information. ## Core Purpose The core purpose of a Customer Portal is to reduce friction between the business and the customer. Customers often need to do routine account work, such as updating a card, resetting a password, changing contact information, updating shipping details, managing a subscription, or resolving a failed payment. Without a portal, those actions may require a support ticket, phone call, manual admin update, or custom ecommerce account page. With a Customer Portal, the business can make selected actions available directly to the customer. This helps the business: - reduce repetitive support work - improve customer experience - keep customer information current - support subscription lifecycle management - support trial lifecycle management - support secure payment method updates - create a direct customer path for failed payment recovery - give AI, voice, email, and support workflows a secure destination to send customers ## Relationship to Customers Customer Portals are closely tied to Customer records. A Customer Portal is accessed by an end customer, but the portal experience is based on the matching Customer record in RevCent. During registration, the customer’s email is used to match the portal user to an existing Customer record when the portal is configured for existing customers. The Customer record is the source of the customer relationship. It can connect to sales, subscriptions, trials, customer cards, shipping details, payment history, and other ecommerce activity. The Customer Portal provides a controlled way for the customer to interact with selected parts of that relationship. Conceptually: ```text Customer record ↓ Customer Portal account registration and login ↓ Customer permissions ↓ Allowed customer self-service actions ``` For crawlers and planning systems, the distinction is: ```text Customer = item representing the person or buyer. Customer Portal = feature that lets that customer access and manage selected account actions. ``` ## Secure Registration Customer Portal access is based on portal-specific registration. A customer registers directly within the portal. Even if the customer already has an account in a separate store, ecommerce site, or web application, the Customer Portal uses its own registration and verification process. This matters because RevCent is hosting the portal, managing the customer portal user registration, and verifying who is logging into that portal. A typical secure registration flow looks like this: ```text Customer opens portal registration page ↓ Customer submits registration information ↓ reCAPTCHA helps prevent automated abuse ↓ RevCent sends confirmation email ↓ Customer confirms with email code ↓ Customer can access allowed portal actions ``` The email used during registration is important. It is used to match the portal user to a Customer record in the RevCent account when the portal is set to existing-customers-only behavior. ## Existing Customers Only Customer Portals can be configured to allow only existing customers to register. When existing customers only is enabled, RevCent checks the submitted registration email against existing Customer records. If no matching customer exists, registration is cancelled. This is useful when the portal should only be available to customers who have already purchased, subscribed, started a trial, or otherwise exist inside the RevCent account. When existing customers only is disabled, people who do not already match a Customer record may be allowed to register. In that case, RevCent can create a new Customer record and assign the new customer to a selected campaign. For most ecommerce customer-service use cases, existing-customers-only behavior is often the safer default because the portal is usually meant for customers who already have a relationship with the business. ## Relationship to Tracking Domains Customer Portals can use an existing Tracking Domain as the portal hosting domain. This is one of the main relationships between Customer Portals and Tracking Domains. A Tracking Domain gives RevCent a domain that the business has already configured for customer-facing use. When the Tracking Domain has DNS set up correctly and SSL active, it can be used as the domain for the Customer Portal. Conceptually: ```text Tracking Domain configured ↓ DNS setup completed ↓ SSL active ↓ Customer Portal can use that domain ``` This helps the portal feel connected to the business’s own customer-facing website instead of appearing as an unrelated page. The Tracking Domain should be ready before the portal is launched. A customer-facing portal should not be created around a domain that is not properly configured, not secure, or not appropriate for customer use. ## Custom Domain and Portal URL A Customer Portal can have a portal URL, registration URL, login URL, and account URL. The portal URL is the main entry point. If the customer is not logged in, the customer is redirected to the login page. If the customer is already logged in, the customer is redirected to the account page. A custom path can also be configured. If no custom path is entered, RevCent can use the Customer Portal ID as the path. A strong portal URL should be easy for customers to recognize and should match the brand or store experience whenever possible. Example portal use cases: ```text Customer account center Payment update portal Subscription management portal Trial management portal Brand-specific customer portal Store-specific customer portal ``` ## Embedding and Domain Behavior Customer Portals have historically supported iframe-style embedding, but third-party iframe usage is no longer recommended for modern browser environments. The safer pattern is to use a custom domain that is properly configured through a Tracking Domain. When the portal runs on the same customer-facing domain context, the business can create a smoother account experience and avoid browser restrictions that apply to cross-domain iframe behavior. The practical guidance is: ```text Use a properly configured custom domain instead of relying on third-party iframe behavior. ``` ## Required Setup Before creating or enabling a Customer Portal, the business should have the required surrounding configuration ready. Important prerequisites include: - a Customer Portal name - a Tracking Domain that is DNS-ready and SSL-active - reCAPTCHA settings - an SMTP Profile - account confirmation email settings - password reset email settings - customer permissions - customer filters, if needed - display settings and footer content, if needed A Customer Portal is customer-facing, so it should not be treated as a casual internal setting. The domain, security, email delivery, permissions, and customer access behavior should all be intentional before launch. ## reCAPTCHA Customer Portals use reCAPTCHA to help protect the registration experience. The portal is customer-facing, which means it can be exposed to bot registration attempts, fake account attempts, and other low-quality traffic. reCAPTCHA helps reduce that risk. The configuration should include the required reCAPTCHA keys, such as the site key and secret key. The business should confirm reCAPTCHA is active before directing customers to the portal. ## SMTP Profile Requirement Customer Portals require an SMTP Profile for customer portal emails. The SMTP Profile is used to send important portal emails such as account confirmation and password reset messages. Without working email delivery, customers may not be able to confirm registration or regain access after forgetting a password. The portal email sender should be reviewed carefully. The from email should align with the selected SMTP Profile and the brand experience customers expect. ## Customer Portal Emails Customer Portals include customizable emails for key account-access flows. The two most important portal email types are: - registration confirmation email - password reset email Each email type can have its own from address, from name, subject, HTML template, CC addresses, and BCC addresses. The key operational rule is that these emails must include the required email code placeholder: ```handlebars {{email_code}} ``` That code is what the customer uses to confirm registration or complete a password reset. If the email template does not include the code, the customer may be unable to complete the flow. ## Display and Branding A Customer Portal can be customized so it feels more consistent with the merchant’s brand. Display settings can include: - company or display name - portal name - logo image - footer HTML - customer-facing support information - customer guidance text The display name is what customers see when using the portal. If the display name is blank, the portal name may be used. Footer HTML can be useful for support links, terms links, privacy links, contact information, brand guidance, or other customer-facing information. JavaScript should not be expected to run inside footer HTML. ## Customer Filters Customer filters control which customers can access or see account information through a portal. Customer Portals can support filtering by customer origin, such as campaign or shop association. Filters are important for multi-brand, multi-store, or multi-campaign RevCent accounts. They allow the business to create different portals for different customer groups without exposing unrelated brand or store information. Examples: ```text Brand A Portal → Brand A campaign customers Brand B Portal → Brand B campaign customers WooCommerce Store Portal → customers from that shop Subscription Portal → customers from subscription-related campaigns ``` If no customer filters are selected, the portal may be available to a broader set of customers. That may be fine for a simple single-brand business, but multi-brand businesses should plan filters carefully. ## Campaign Filters Campaign filters allow the portal to limit displayed entities to those that originated from selected campaigns. This is useful when campaigns represent different brands, websites, offers, funnels, partner sources, or business units. For example, a business may want a Brand A customer to see only Brand A sales, subscriptions, shipping, trials, and payment recovery items in the Brand A portal. Campaign filters help keep the portal experience aligned with the customer’s purchase origin. ## Shop Filters Shop filters allow the portal to limit displayed entities to those that originated from selected shops. This is useful when the RevCent account is connected to multiple storefronts, such as different WooCommerce stores, Shopify stores, or other third-party shops. A store-specific portal can have its own branding, customer emails, permission strategy, and customer guidance. This helps the customer see a portal that matches where they purchased. ## Customer Permissions Customer permissions determine what logged-in customers can do inside the portal. By default, portal permissions should be treated as sensitive. Only enable the actions that the business truly wants customers to perform. Common permissions include: | Permission | Customer-Facing Purpose | |---|---| | `contact_modify` | Allow customers to modify contact information. | | `credit_card_add` | Allow customers to add a new credit card. | | `credit_card_remove` | Allow customers to remove a non-default saved card. | | `credit_card_set_default` | Allow customers to set a default credit card. | | `shipping_modify_ship_to` | Allow customers to modify shipping details. | | `subscription_renew` | Allow customers to manually renew a subscription. | | `subscription_activate` | Allow customers to re-activate a subscription. | | `subscription_suspend` | Allow customers to suspend a subscription. | | `subscription_cancel` | Allow customers to permanently cancel a subscription. | | `trial_expire` | Allow customers to expire a trial with payment. | | `trial_cancel` | Allow customers to cancel a trial without payment. | | `salvage_transaction_process` | Allow customers to pay a failed renewal or failed trial expiration balance. | Permissions are the main guardrail between a useful self-service portal and a portal that exposes too much customer control. ## Payment Method Management Payment method management is one of the most valuable Customer Portal use cases. Customers may need to add a new card, remove an old card, or set a different default card because a card expired, was replaced, failed during renewal, failed during trial expiration, or no longer belongs to the customer. A typical payment update flow looks like this: ```text Payment fails or card needs update ↓ Customer opens Customer Portal ↓ Customer adds new card ↓ Customer sets new default card ↓ Future payment activity can use the updated method ``` This can reduce support work and give the customer a secure place to update payment details without sending sensitive information through email, chat, or support tickets. ## Subscription Management Customer Portals can support subscription self-service when the business enables subscription permissions. Possible subscription actions include renewing, re-activating, suspending, or cancelling a subscription. A business should only enable the subscription permissions that match its customer policy. For example, if customers should be able to update payment methods but not directly cancel subscriptions, then the payment-related permissions can be enabled while `subscription_cancel` remains disabled. Customer Portals make subscription management more scalable because customers can perform allowed subscription actions without waiting for a support agent. ## Trial Management Customer Portals can also support trial lifecycle actions. Depending on the portal permissions, customers may be able to expire a trial with payment or cancel a trial without payment. Trial permissions are useful for businesses where trials are a major part of the customer lifecycle. They allow the business to give customers a controlled way to manage trial outcomes. As with subscription permissions, trial permissions should be enabled intentionally. ## Failed Payment Recovery Customer Portals can be part of failed payment recovery. When a renewal or trial expiration payment fails, the customer often needs a secure way to update the default card, add a new payment method, or pay the failed balance. The `salvage_transaction_process` permission allows customers to pay certain failed renewal or failed trial expiration balances through the portal. For the customer, this should be framed in simple language such as: ```text Pay now Update payment method Resolve failed payment ``` The internal system concept may be a salvage transaction, but the customer-facing experience should focus on completing or resolving the failed payment. ## Relationship to AI Assistants Customer Portals can work well with AI Assistants. An AI Assistant can identify customer situations where a portal link is useful, such as failed payment recovery, card update reminders, subscription save flows, trial conversion follow-up, or customer support triage. A typical AI-assisted flow looks like this: ```text AI Assistant identifies customer needing action ↓ Email or workflow sends Customer Portal link ↓ Customer logs in securely ↓ Customer completes allowed self-service action ``` The Customer Portal gives AI workflows a secure customer-facing destination. The AI Assistant does not need to collect sensitive payment details directly. It can guide the customer to the portal instead. ## Relationship to AI Voice Agents AI Voice Agents can also direct customers to a Customer Portal. For example, an AI Voice Agent might call a customer about a failed renewal, explain that the customer can update their payment method, and direct the customer to the portal. This pattern is safer than asking the customer to provide sensitive payment details over a voice conversation. Conceptually: ```text AI Voice Agent contacts customer ↓ Agent explains account or payment issue ↓ Agent directs customer to Customer Portal ↓ Customer completes secure self-service action ``` ## Relationship to Email Templates Customer Portals often pair with email communication. Email Templates can send customers to the portal for actions like updating cards, resolving failed payments, resetting account access, or managing subscriptions. Portal-specific customer emails handle the confirmation and password reset process, while normal ecommerce email templates can point customers toward the portal for self-service. This makes the Customer Portal a destination that other communication features can reference. ## Relationship to Customer Cards Customer Cards are stored customer payment method references in RevCent. Customer Portals can allow customers to manage payment methods through the permissions that add cards, remove non-default cards, or set a default card. The portal should be understood as the customer-facing mechanism for secure card updates, while Customer Cards are the underlying stored payment method items. Important distinction: ```text Customer Portal = feature that lets the customer manage allowed payment method actions. Customer Card = stored payment method item associated with the customer. ``` ## Relationship to Salvage Transactions Customer Portals can allow customers to process certain failed payment balances when `salvage_transaction_process` is enabled. This is useful for failed renewal or failed trial expiration scenarios where the customer needs to pay an outstanding balance or resolve an overdue payment. The portal should present this in customer-friendly language rather than system terminology. For example: ```text Pay now Resolve payment Complete failed renewal payment Update card and retry ``` ## Relationship to Shipping Customer Portals can allow customers to update shipping details when the `shipping_modify_ship_to` permission is enabled. This is useful for ecommerce businesses that ship physical products. Customers can correct shipping information before fulfillment problems occur. The business should decide whether shipping updates are allowed for all shipping records or only certain customer situations, depending on how the broader shipping workflow is designed. ## Multi-Brand and Multi-Store Portals Customer Portals are especially useful in accounts with multiple brands, campaigns, or shops. Instead of using one generic portal for every customer, a business can create portal experiences tailored to the customer’s origin. Examples: ```text Brand A Customer Portal Brand B Customer Portal Subscription Product Portal WooCommerce Store Portal Trial Customer Portal Payment Recovery Portal ``` Each portal can have different: - display name - domain or path - customer filters - customer permissions - email copy - footer content - customer guidance This lets the business centralize customer data in RevCent while still giving each customer a portal experience that matches the brand, store, or product they recognize. ## Customer Support Benefits Customer Portals can reduce support load by giving customers a place to complete common actions themselves. Common support questions that can be reduced include: ```text How do I update my card? Can I reset my password? Can I change my shipping address? Can I renew my subscription? Can I pause my subscription? Can I cancel my trial? How do I fix my failed payment? ``` When customers can handle these actions directly, support teams can focus on more complex issues. ## Customer Data Quality Customer Portals can improve customer data quality because customers can update important information themselves. Examples include: - contact information - payment method details - default payment method selection - shipping details - subscription actions - trial actions Better customer-managed data can improve future billing, fulfillment, customer support, and customer lifecycle workflows. ## Security and Access Considerations Because Customer Portals expose customer-facing access to account actions, the configuration should be reviewed carefully before launch. Important security considerations include: - use a DNS-ready Tracking Domain with SSL active - require reCAPTCHA - require customer email verification - include `{{email_code}}` in confirmation and password reset emails - use a trusted SMTP Profile - enable only intentional customer permissions - use filters for multi-brand or multi-shop environments - avoid exposing subscription cancel, trial cancel, or payment actions unless the business truly wants customers to have those options A Customer Portal should always be treated as a customer-facing security boundary. ## Common Ecommerce Use Cases ### Payment Update Portal A business can use a Customer Portal mainly to let customers update payment methods. Typical permissions: ```text credit_card_add credit_card_remove credit_card_set_default ``` This is useful for subscription businesses, trial businesses, and any ecommerce operation where customers need to keep payment methods current. ### Subscription Management Portal A subscription-focused business can enable selected subscription permissions. Possible permissions: ```text subscription_renew subscription_activate subscription_suspend subscription_cancel ``` The business can choose which lifecycle actions customers should be able to perform. ### Trial Management Portal A trial-based business can enable selected trial permissions. Possible permissions: ```text trial_expire trial_cancel ``` This can help customers manage trial outcomes without waiting for support. ### Failed Payment Recovery Portal A business can send customers with failed renewals or failed trial expirations to a Customer Portal. Useful permissions: ```text credit_card_add credit_card_set_default salvage_transaction_process ``` This gives customers a secure path to update payment details and resolve failed payment situations. ### Brand-Specific Account Portal A multi-brand business can create a separate portal for each brand. Each portal can have its own Tracking Domain, display settings, customer filters, and permissions. This helps keep the customer-facing account experience aligned with the brand where the customer purchased. ## Guardrails Customer Portal setup should follow a few important guardrails: - Do not enable broad permissions without reviewing the customer impact. - Do not launch a portal before DNS, SSL, SMTP, and reCAPTCHA are ready. - Do not forget `{{email_code}}` in confirmation and password reset emails. - Do not use one broad portal for multiple brands if customers should see brand-specific experiences. - Do not rely on third-party iframe behavior when a properly configured custom domain is the better path. - Do not allow non-existing customer registration unless there is a clear business reason. - Do not expose payment or subscription actions that should require human review. ## Why This Matters in the RevCent Ecosystem Customer Portals connect several parts of RevCent into a customer-facing experience. They relate to Customers because the portal account is matched to customer records. They relate to Tracking Domains because the portal can use a configured domain for customer-facing access. They relate to Customer Cards because customers can manage payment methods when permissions allow. They relate to subscriptions, trials, shipping, and failed payment recovery because the portal can expose selected actions around those records. This makes the Customer Portal a practical bridge between RevCent’s internal ecommerce data and the customer’s own account experience. ## Best-Fit Businesses Customer Portals are especially valuable for businesses that: - sell subscriptions - offer trials - need customers to update payment methods - want to reduce support tickets - manage multiple brands or stores - need customer-facing account access - want customers to resolve failed payments securely - ship products and need customers to update shipping details - use AI, voice, or email workflows that need a secure customer destination ## Summary Customer Portals in RevCent are configurable customer-facing self-service features. They let businesses give customers secure access to selected account actions while maintaining control through permissions, filters, domain configuration, reCAPTCHA, SMTP-based emails, and customer verification. The key relationships are: ```text Tracking Domain → provides customer-facing domain context for the portal Customer Portal → configurable feature that hosts the self-service experience Customer → underlying customer item matched to the portal user ``` A well-configured Customer Portal can reduce support workload, improve customer experience, help customers update payment methods, support subscription and trial management, help resolve failed payments, and make RevCent customer data more actionable for the customer. --- 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.