# CTIO COMBO — Vol 5 Website & Mobile App (Markdown extract) **Design-update requirements input** **Document ID:** CTIO-V5WEB-001 **Version:** V.01 (working draft) **Date:** 2026-06-04 **Source:** CDRL06 Detailed Design Document, **Volume 5** — faithful text extract of the web/mobile design content. --- ## How to use this document This is a markdown rendering of Volume 5's **Website and Mobile App** design so it can be edited and used as an input when updating the web/mobile design. The body below is reproduced faithfully from Vol 5 — including the **Business Rules** and **Validation / System Responses** tables, which are the acceptance criteria for each screen. Edit here, then fold approved changes back into the controlled Vol 5. **Scope included:** Website and Mobile App (sitemap, all detailed component designs, external interfaces, content management); Customer Satisfaction Surveys; Technologies Used; Non-Functional Requirements. **Scope excluded** (not web-design content): the Omnichannel / Amazon Connect contact-centre section, the Walk-In Center, and the generic Introduction / Partners pages. Say the word if you want those appended. **Wireframes / figures:** screen wireframes are referenced by caption (e.g. "Figure NN – Wireframe – …") but the **images are not embedded** in this text extract — the source Word file holds the actual wireframe images. Treat the captions as pointers to the visual spec. ## Design-update actions to fold in (from the requirements gap analysis, CTIO-WREQ-001) - **Loyalty Program — net-new design required.** Vol 5 contains **no loyalty screens**, yet 27 web-flagged RTM requirements and Volumes 1/3/6/7 require it. Add loyalty enrollment, balance/tier/history, and redemption/offers screens. - **Communication / notification preferences** — Vol 5 references "Edit Communication Preferences"; ensure the screen and dataset are fully specified. - **In-app HOV declaration** — add the mobile flow for declaring HOV status (HOV occupancy verification via the Mobile Application). - **QR-code invoice payment entry** — add the QR landing that routes a guest to pay/dispute on web/app with an app-download prompt. **Traceability:** RTM requirement IDs and the Epic/User-Story mapping live in **CTIO-WREQ-001** (Web Requirements Map) and the backlog **CTIO-BLG-001**. --- ## Contents - [Website and Mobile App](#website-and-mobile-app) - [Introduction](#introduction) - [Sitemap](#sitemap) - [Detailed Components Design](#detailed-components-design) - [Front Pages](#front-pages) - [Personal Account Creation](#personal-account-creation) - [Business Account Creation](#business-account-creation) - [Additional Account Plans](#additional-account-plans) - [Sign In](#sign-in) - [First-Time Login](#first-time-login) - [Forgot Password](#forgot-password) - [Reset Password](#reset-password) - [Multi-Account Switcher](#multi-account-switcher) - [Personal Account Management](#personal-account-management) - [Business Account Management](#business-account-management) - [Non-Account Users](#non-account-users) - [External Interfaces (APIs, Third-Party Integrations)](#external-interfaces-apis-third-party-integrations) - [Chatbot and Web Chat](#chatbot-and-web-chat) - [Language and Browser Support](#language-and-browser-support) - [Payment Processing Integration](#payment-processing-integration) - [Social Media](#social-media) - [CoTrip](#cotrip) - [Google Maps & Waze/Carpool](#google-maps-wazecarpool) - [Analytics and Logging](#analytics-and-logging) - [Content Management](#content-management) - [Content Ownership & Responsibilities](#content-ownership-responsibilities) - [System Boundaries](#system-boundaries) - [Content Modeling & Structure](#content-modeling-structure) - [Rendering & Delivery](#rendering-delivery) - [Content Lifecycle (Draft, Preview, Publish)](#content-lifecycle-draft-preview-publish) - [Localization Strategy](#localization-strategy) - [Media Asset Management](#media-asset-management) - [Caching & Content Freshness](#caching-content-freshness) - [Content Classification](#content-classification) - [CMS Managed Content Updates](#cms-managed-content-updates) - [Customer Satisfaction Surveys](#customer-satisfaction-surveys) - [Integration Architecture](#integration-architecture) - [Survey Forms and Delivery Methods](#survey-forms-and-delivery-methods) - [Channel-Specific Implementation](#channel-specific-implementation) - [Phone/IVR Surveys (Phone Bot-Only, Phone Self-Service, Phone CSR)](#phoneivr-surveys-phone-bot-only-phone-self-service-phone-csr) - [Web Chat Surveys (Web Chatbot-Only, Web Chat CSR)](#web-chat-surveys-web-chatbot-only-web-chat-csr) - [Email Surveys](#email-surveys) - [Web Portal Surveys (Web General, Web Logged-In, Web Payment)](#web-portal-surveys-web-general-web-logged-in-web-payment) - [Mobile Application Surveys (App General, App Logged-In, App Payment)](#mobile-application-surveys-app-general-app-logged-in-app-payment) - [Case Management Surveys](#case-management-surveys) - [Walk-In Center Surveys](#walk-in-center-surveys) - [Survey Offer Strategy and Frequency Controls](#survey-offer-strategy-and-frequency-controls) - [Survey Configuration](#survey-configuration) - [Reporting and Data Access](#reporting-and-data-access) - [Data Storage and Security](#data-storage-and-security) - [Technologies Used](#technologies-used) - [Non-Functional Requirements (NFRs)](#non-functional-requirements-nfrs) - [Accessibility and Usability](#accessibility-and-usability) - [Security, Privacy, and Data Protection](#security-privacy-and-data-protection) - [Performance, Availability, and Scalability](#performance-availability-and-scalability) - [Logging, Monitoring, and Audit Support](#logging-monitoring-and-audit-support) - [Design Scope Statement](#design-scope-statement) --- # Website and Mobile App ## Introduction The Emovis Touch website and the App are designed to enhance user experience, streamline tolling processes and updates/enhancements, and provide a seamless interface for managing toll-related activities. Aligned with the overall project strategy, the website offers different user journeys tailored to both unregistered and registered users, minimizing the friction and increasing the self-service features required. It is designed like this to ensure convenience, efficiency, and user satisfaction. Whether a customer is managing multiple vehicles, planning a long road trip, or simply commuting daily, the website ensures a hassle-free experience with its intuitive design and comprehensive feature set with integrated advanced technology and real-time data. ## Sitemap The sitemap presents a structured, usercentric view of the CTIO website, organized around the key journeys that customers follow when interacting with tolling services. The architecture clearly separates public access, transactional flows and authenticated account management in order to minimize friction, reduce user confusion, and support both occasional and frequent users. **Front Pages (Public Access)** form the entry point to the website and are accessible to all users, whether logged in or not. These pages focus on highintent actions through clear calls to action such as *Create Account*, *Pay a Bill*, and *Pay a Toll*. Supporting content—including Sign-in, password reset, firsttime access for CSRcreated accounts, news, contact information, and editable informational pages (e.g. FAQs, STEP, Equity plans)—ensures users can both complete transactions and understand CTIO services without requiring authentication. **Account Creation** is a dedicated flow that guides new users through setting up an online account. This flow is intentionally isolated and streamlined to support selfservice onboarding, while also integrating with CSRinitiated accounts to ensure continuity between assisted and digital channels. **Non****Account User Flows** allow customers to complete essential transactions without registering, recognizing that many users are infrequent or resolving oneoff issues. These flows include paying a bill (covering invoices and Step violations), paying a recent toll (generated within the last seven days), and disputing a bill. The dispute process is deliberately separated from payment to reduce cognitive load, allowing users to clearly choose whether they intend to pay or contest a charge before proceeding. **Account Management** represents the core authenticated experience and is available only to loggedin users. It provides a comprehensive, dashboarddriven environment for managing all aspects of a customer’s relationship with CTIO. Functional areas include vehicle management, payments, documents, account history, cases and disputes, safety enforcement, and account settings. This structure supports both singleaccount and multiaccount users, ensuring scalability for households or fleets. Finally, **Global Account Management Functions** are accessible from anywhere within the authenticated experience and provide crosscutting utilities such as switching between accounts, managing profile settings, accessing rewards, and signing out. The following figure depicts the website sitemap that has been designed. Figure 32 – Website Sitemap ## Detailed Components Design The website has been designed based on previous operational experiences, aiming for a user friendly, intuitive and customer centric solution. With this in mind, and considering all the requirements captured in the RTM and other Emovis best practice and lessons learnt, the website has been organized around navigation flows or groups of functionalities that capture all the needs and scenarios that CTIO users will go through when interacting with us whenever they want to create or manage their accounts, pay or dispute their invoices or simply browse for information or interact with our agents. These are the navigation flows: Home Page / Third-Parties Links / FAQ / Info Personal / Business Account Creation Personal / Business Account Management Sign In / Forgot / Reset Password Check (and Pay) Unpaid Tolls Pay an Invoice / Pay as Guest / Convert & Save / Transfer to my Account Dispute and Invoice / STEP Notice Analytics Content Management ### Front Pages #### Homepage ##### Introduction The CTIO Homepage is the primary public-facing landing page and serves as the main entry point for users. It provides access to key journeys, informational content, media, statistics, news, and FAQs. The homepage is CMS editable, allowing content managers to update text, media, links, alert messaging, and section visibility without developer involvement. ##### Sections and Components Table 11 – Homepage – Sections | Section | Purpose | | --- | --- | | Header | Provides top-level public navigation that contains official agency name and Seal with core functionalities like login, create account, language and a search bar for ease of navigation. | | Alert Banner | Displays persistent high-priority informational or service messaging | | Hero/Primary Entry | Main entry point with key actions | | Featured Content | Highlight a configurable message or campaign details | | Value Proposition Cards | Display user facing values like benefits, services and related topics | | Video/Media | Show multimedia content | | Statistics | Present key metrics | | Latest News | Display recent updates | | FAQ | Provide common answers | | Footer | Provides supporting navigation, logo, trademark, disclosures or legal requirements | Table 12 – Homepage – Section Components | Section | Component | Description | | --- | --- | --- | | Header | Logo | CTIO logo displayed on the left and linked to homepage | | | Primary Navigation | Public navigation links such as Home, About, FAQ, Contact | | | Register Button | CTA (Call-to-action) linking to registration flow | | | Login Button | CTA linking to sign-in flow | | | Language Selector | Language switcher control | | Sticky Alert Mini Banner | Alert Message | Short informational or service-related message | | | Alert Link | Optional inline link such as “Action” | | | Sticky Behavior | Banner remains fixed at top while user scrolls, according to implementation | | Hero | Hero Media | Image/banner | | | CTA Cards | 3 primary action cards containing icon. Title, description and link | | Featured Content | Image | Featured visual | | | Description | Supporting text | | | CTA Button | Link to more details | | Value Proposition Cards | Section Title | Heading for section | | | Card Title | Individual card heading | | | Card Description | Informational text | | | Card Link (optional) | Navigation to detail page | | | Video Asset | Embedded or linked video | | Video/Media | Thumbnail | Preview image | | | Play Control | Starts / pauses the video | | | Section Title | Heading | | Statistics | Value | Numeric metric | | | Label | Description of metric | | | Section Title | Heading | | Latest News | News Card | Individual news item | | | Image | News thumbnail | | | Title | News headline | | | Summary | Short description | | | Link | Navigate to article | | | Section Title | Heading | | FAQ | Question | FAQ item | | | Answer | Expandable content | | | Accordion Control | Expand/collapse behavior | | | Logo | CTIO logo displayed on the left | | Footer | Trademark / Copyright Text | Trademark, copyright, or ownership text displayed under / beside the logo | | | Secondary Navigation | Links such as About, Board, Media and News | | | Legal Links | Links such as Privacy and Sitemap | ##### Business Rules Table 13 – Business Rules – Homepage | Rule Name | Description | | --- | --- | | CMS-Driven Content | All homepage content, including global elements where configured, is managed via CMS | | Header Consistency | Header is displayed across public-facing pages using the same global structure | | Sticky Alert Visibility | Sticky alert banner is displayed only when enabled and populated | | Footer Consistency | Footer is displayed across public-facing pages using the same global structure | | Section Visibility | Sections can be shown/hidden | | Section Order | Controlled via CMS or layout config | | Graceful Empty State | Empty sections are hidden or fallback displayed │ | ##### Wireframe(s) Figure 33 – Wireframe – Homepage #### News Landing Page ##### Introduction The News Landing Page is a public, CMS-driven page that displays CTIO news, updates, and informational content in a structured, filterable, and paginated layout. The page enables users to browse, filter, and access detailed news articles. ##### Sections and Components Table 14 – News Landing Page – Sections | Section | Purpose | | --- | --- | | Header (Global) | Navigation and access to other pages | | Breadcrumb | Shows page location and context | | Featured Article | Highlights a primary news item | | Category Filters | Allows filtering of content | | News Listing Grid | Displays news articles | | Pagination | Navigate through pages | | Subscription CTA | Capture user email for updates | | Footer (Global) | Supporting navigation and legal info | Table 15 – News Landing Page – Section Components | Section | Component | Description | | --- | --- | --- | | Featured Article | Image | Thumbnail | | | Tag / Category | Content classification | | | Publish Date | Article date | | | Title | Featured article headline | | | Summary | Short description | | Category Filters | Filter Tabs | Categories (e.g. All, News & Updates, Policies) | | News Listing Grid | Article Card | Repeating news items | | | Image | Thumbnail | | | Category Label | Content type | | | Date | Publish date | | | Title | Article headline | | | Summary | Short text | | | Link | Navigates to detail page | | Subscription CTA | Title | Call-to-action heading | | | Description | Supporting text | | | Email Input | User email field | | | Subscribe Button | Submission action | ##### Business Rules Table 16 – Business Rules – News Landing Page | Rule Name | Description | | --- | --- | | CMS-Driven Content | All news content is managed via CMS | | Featured Article Priority | A featured article may be pinned or highlighted | | Category Filtering | Users can filter news by predefined categories | | Pagination Required | Pagination appears when results exceed page limit | | Chronological Ordering | Default sort is newest first | | Article Navigation | Clicking a card opens the article detail page | | Global Components | Header and Footer remain consistent across pages | ##### Wireframe(s) Figure 34 – Wireframes – News Landing Page #### News Single Page ##### Introduction The News single page is a CMS-driven public page that displays the full content of a selected news item. It provides users with detailed information, supporting media, and related content to encourage further engagement. All article content is dynamically retrieved from the CMS and rendered using structured content components. ##### Sections and Components Table 17 – News Single Page – Sections | Section | Purpose | | --- | --- | | Header (Global) | Navigation and access to other pages | | Breadcrumb | Shows navigation path | | Article Header | Displays title, category, published date | | Article Header – Social Media Icons/Share | Allows sharing to social media | | Hero | Displays primary article image/video | | Article Content | Main article body | | Inline Media | Supporting images/videos within content | | Related Articles | Displays related articles (by category) | | Footer (Global) | Supporting navigation and legal info | Table 18 – News Single Page – Section Components | Section | Component | Description | | --- | --- | --- | | Article Header | Category Label | Dedicated news category | | | Publish Date | Date of publication | | | Title | Main headline | | | Share Icons | Social/media sharing controls | | Hero Media | Image/Video | Featured article media | | Related Articles | Section Title | “More from this category” | | | Article Cards | Related items | | | Image | Thumbnail | | | Title | Headline | | | Date | Publish date | | | Link | Navigate to article | ##### Business Rules Table 19 – Business Rules – News Single Page | Rule Name | Description | | --- | --- | | CMS-Driven Content | All article content is managed via CMS | | Navigation Continuity | Breadcrumb must reflect correct hierarchy | | Metadata Display | Title, date, and category must be displayed | | Rich Content Support | Article body supports formatted text and media | | Related Content Logic | Related articles are displayed based on category or tagging | | Global Components | Header and Footer remain consistent across pages | ##### Wireframe(s) Figure 35 – Wireframe – News Single Page Figure 36 – Wireframe – Related Articles Section #### FAQ Page ##### Introduction The FAQ Page is a CMS-driven public page that provides users with answers to commonly asked questions related to CTIO services, accounts, payments, and tolling. The page is designed using an accordion-style layout to allow users to quickly scan questions and expand items to view detailed answers. All content is managed through the CMS and dynamically rendered. ##### Sections and Components Table 20 – FAQ Page – Sections | Section | Purpose | | --- | --- | | Header (Global) | Navigation and access to other pages | | FAQ Intro Section | Provides context and page description | | FAQ Accordion List | Displays expandable questions and answers | | Footer (Global) | Supporting navigation and legal info | Table 21 – FAQ Page – Section Components | Section | Component | Description | | --- | --- | --- | | FAQ Intro Section | Title | “Frequently asked questions” | | | Description | Introductory text explaining the section | | FAQ Accordion List | Question | Clickable FAQ item | | | Answer | Hidden content revealed on expand | | | Expand/Collapse Control | Toggle interaction (icon/button) | | | Accordion Container | Groups FAQ items | ##### Business Rules Table 22 – Business Rules – FAQ Page | Rule Name | Description | | --- | --- | | CMS-Driven Content | All FAQ content is managed via CMS | | Accordion Behavior | Answers are hidden by default and shown when expanded | | Ordered Display | FAQs are displayed in defined CMS order | | Rich Text Support | Answers may include formatted text and links | | Global Components | Header and Footer remain consistent across pages | ##### Wireframe(s) Figure 37 – Wireframe – FAQ Page #### Contact Us Page ##### Introduction The Contact Us Page is a CMS-driven public page that allows users to submit inquiries to CTIO support and access key contact information such as address, customer service hours, and phone details. The page combines a structured contact form with supporting information cards. All content is managed via the CMS, while form submission integrates with backend support systems. ##### Sections and Components Table 23 – Contact Us Page – Sections | Section | Purpose | | --- | --- | | Header (Global | Navigation and access to other pages | | Contact Intro | Page title and supporting text | | Contact Form | User inquiry submission | | Contact Information Cards | Display CTIO contact details | | Footer (Global) | Supporting navigation and legal info | Table 24 – Contact Us Page – Section Components | Section | Component | Description | | --- | --- | --- | | Contact Intro | Title | “Contact Us” | | | Description | Supporting text explaining purpose | | Contact Form | First Name | Text input (required) | | | Last Name | Text input (required) | | | Email Address | Email input (required) | | | Subject | Dropdown selection (required) | | | Message | Free-text input (required) | | | File Upload | Optional attachment field | | | Submit Button | “Send” action | | Contact Information Cards | Address | Physical address details | | | Customer Service Hours | Operating hours | | | Customer Service Phone | Contact phone number | ##### Business Rules Table 25 –Business Rules – Contact Us Page | Rule Name | Description | | --- | --- | | CMS-Driven Content | Page content and contact details are managed via CMS | | Required Fields | First name, last name, email, subject, and message are mandatory | | Email Validation | Email must be in valid format | | File Upload Optional | Users may attach a file, but it is not required | | Subject Classification | Subject dropdown determines inquiry categorization | | Global Components | Header and Footer remain consistent across pages | ##### Wireframe(s) Figure 38 – Wireframe – Contact Us Page #### Additional CMS Editable Sections ##### Introduction The CTIO website includes a set of CMS-driven reusable content modules that can be placed across multiple pages (e.g. homepage, informational pages, landing pages). These components enable flexible page composition and allow content managers to build pages using predefined layouts without developer involvement. All components are dynamically rendered from CMS entries and follow consistent design and behavior patterns. These components are: Configurable via CMS Reusable across multiple page types Orderable within page layouts Optional and composable (pages may include any combination) Table 26 – Additional CMS Editable Sections Overview | Component | Purpose | | --- | --- | | Two-Column Text | Present structured textual content | | Alternating Image and Text | Provide visual storytelling sections | | Multi-Image and Text | Display grouped media with supporting content | | Tabbed Media and Content Section | Display tabbed content with associated media, text, and call-to-action | | Card Slider | Display a horizontal set of clickable content cards | ##### Two-Column Text ###### Introduction Display structured textual content, typically used for introductions or explanatory sections. ###### Section Components Table 27 – Two-Column Text – Components | Component | Description | | --- | --- | | Optional Section Heading | Section-level heading, if configured | | Left Text Block | Primary message or summary | | Right Text Block | Supporting or extended content | ###### Business Rules Table 28 – Business Rules -Two-Column Text | Rule Name | Description | | --- | --- | | Two-Column Layout Structure | The component must render two distinct content areas in the approved layout. | | CMS Editable Text | All textual content must be editable through the CMS. | | Responsive Stacking | On smaller viewports, the two columns must stack vertically in the defined responsive order. | | Rich Text Support | Content areas may support structured rich text formatting subject to CMS field configuration. | | Optional Heading Support | A section heading may be displayed if configured in the CMS. | ###### Wireframe(s) Figure 39 – Wireframe – Two-Column Text ##### Alternating Image and Text ###### Introduction Present content in a visually engaging alternating layout combining text and imagery. ###### Section Components Table 29 – Components – Alternating Image and Text Section | Component | Description | | --- | --- | | Image | Visual content block | | Title | Section heading | | Description | Supporting text | ###### Business Rules Table 30 – Business Rules – Alternating Image and Text Block/Section | Rule Name | Description | | --- | --- | | CMS Editable Columns | Each column’s title, description, media, and CTA content must be editable through the CMS. | | Responsive Stacking | On smaller viewports, each column must stack according to responsive design rules. | | Ordered Display | Columns must be displayed in the order defined in CMS or configured sort order. | ###### Wireframe(s) Figure 40 – Wireframe – Alternating Image and Text ##### Multi-Image and Text ###### Introduction Display a grouped media layout on the left or right side of the section with supporting textual content. ###### Section Components Table 31 – Components – Multi-Image and Text | Component | Description | | --- | --- | | Media Group | Collection of images shown in one panel | | Content Area | Textual content block | | Title | Main heading | | Description | Supporting body text | | Optional CTA | Link, if configured | ###### Business Rules Table 32 – Business Rules – Multi-Image and Text | Rule Name | Description | | --- | --- | | Grouped Media Support | The component supports multiple images within a structured grouped layout. | | CMS Editable Media and Text | Media assets, headings, descriptions, and CTA content must be editable via CMS. | | Responsive Reflow | On smaller viewports, media and content must stack according to responsive layout rules. | | Ordered Media Display | Images within the media group must display in the configured order. | ###### Wireframe(s) Figure 41 – Wireframe – Multi-Image and Text (Left Aligned) Figure 42 – Wireframe – Multi-Image and Text (Right Aligned) ##### Tabbed Media and Content Section ###### Introduction The Tabbed Media and Content Section is a CMS-driven reusable module that allows users to switch between multiple content views within a single section using tab controls. Each tab displays a dedicated content state consisting of: Media area Supporting text content An optional call-to-action Provide a structured, tab-driven content module that allows users to switch between related content states without leaving the current page. ###### Section Components Table 33 – Tabbed Media and Content Section – Components | Component | Description | | --- | --- | | Tab Navigation | Horizontal list of selectable tabs | | Tab Label | Label identifying each content | | Active Tab State | Visual indicator showing the selected tab | | Media | Image or other approved media asset associated with the selected tab | | Title | Heading shown for the selected tab | | Description | Supporting copy shown for the selected tab | | CTA (Call to action) Button | Optional button linked to the selected tab content | ###### Business Rules Table 34 – Business Rules – Tabbed Media and Content Section | Rule Name | Description | | --- | --- | | CMS-Driven Tab Content | All tab labels, media, text, and CTA content are managed through the CMS. | | Single Active Tab | Only one tab may be active and displayed at a time. | | Default Active Tab | One configured tab must be active by default on initial page load. | | Active State Visibility | The selected tab must be visually highlighted. | | Optional CTA Support | The CTA is displayed only when both CTA label and destination are configured for the active tab. | | Responsive Reflow | On smaller viewports, tab navigation and content panels must stack according to responsive layout rules. | | Ordered Tab Display | Tabs must display in the order configured in the CMS. | ###### Wireframe(s) Figure 43 – Wireframe – Tabbed Media and Content Section ##### Card Slider ###### Introduction Provide a horizontally navigable content display for grouped items while maintaining a consistent visual layout. ###### Section Components Table 35 – Card Slider – Components | Component | Description | | --- | --- | | Card Item | Individual content unit within slider | | Image | Visual thumbnail displayed on card | | Title | Card heading | | Description | Supporting text | | Link (optional) | Navigation target | | Slider Track | Container holding all cards | | Navigation Controls | Previous / Next buttons | | Progress Indicator | Visual indicator of slider position | ###### Business Rules Table 36 – Business Rules – Card Slider | Rule Name | Description | | --- | --- | | CMS-Driven Content | All card content is managed via CMS | | Repeating Card Structure | Component supports multiple cards using a consistent structure | | Horizontal Layout | Cards are displayed in a horizontal sequence within a scrollable track │ | | Navigation Controls Visibility | Navigation controls are displayed when the number of cards exceeds visible capacity | | Navigation Controls Visibility | Navigation controls are displayed when the number of cards exceeds visible capacity | | Card Link Optionality | Cards may include a link, but are not required to be clickable | | Consistent Card Design | All cards must follow the same layout and styling rules | | Responsive Behavior | Number of visible cards adjusts based on viewport size | ###### Wireframe(s) Figure 44 – Wireframes – Card Slider #### Advertising and Promotional Content **Purpose**: The website supports promotional and informational content intended to communicate CTIO and CDOT-related initiatives, announcements, and public awareness messaging. Advertising within the platform is limited to internal institutional promotions only and does not support third-party advertising networks or commercial ad placements. Examples of supported promotional content may include: Transportation program awareness campaigns New tolling or roadway announcements Parking facility updates Public transit initiatives Seasonal operational notices Public service messaging CTIO or CDOT informational initiatives The website shall not display: Third-party advertising networks Google Ads or external ad-serving platforms Paid banner advertisements from external organizations Programmatic advertising placements Promotional content is managed through CMS-editable components and may be placed across public-facing pages where appropriate. ##### Supported Promotional Components For internal promotional messaging, the following reusable CMS components may be used: **Two Column Text Component ** Refer to Section 4.3.1.6.2 Figure 45 – Two Column Promotional Content Example **Multi Image and Text Component ** Refer to Section 4.3.1.6.4 Figure 46 – Multi Image Promotional Content Example ### Personal Account Creation #### Introduction Creating a CTIO digital account is designed to be a smooth, intuitive experience that empowers customers to manage their travel across Colorado’s express lanes with confidence. Whether a customer is setting up a personal account, managing a family vehicle, or onboarding a business fleet, the digital journey reflects CTIO’s commitment to **accessibility, transparency, and connected mobility**. The process is intentionally guided, helping customers move naturally from step to step as they build the foundation for reliable, seamless tolling. Each screen is structured to minimize friction, support informed decisions, and create a digital relationship with CTIO built on clarity and trust. To avoid duplications and ensure consistency, all API level validations are defined in DDD (CDRL06), Volume 6, Interfaces, and all CBOS business rules are defined in DDD (CDRL06), Volume 2, Emovis Transact CBOS. #### Navigation Flow The following figure depicts the navigation flow of the web user when creating a personal account. Each of the steps below is described in more detail in the sections below. It is split in two parts: the digital account creation, the first three steps until the email is verified, and the onboarding, where the customer finalizes providing the personal as well as the vehicle(s) and payment details. Figure 47 – Personal Account Creation Navigation Flow #### Account Type Selection **Purpose:**** **Identify whether the user is creating a Personal or Business account. This section only covers Personal Account selection. **Controls:** “Type of Account” radio button Title: “Sign up for a new account” Sign-in redirect link for returning users Account category selector (Personal / Business) “Continue” button disabled until a selection is made ##### Business Rules Table 37 – Business Rules – Account Type Selection | Rule Name | Description | | --- | --- | | Account Type Selection | User must select Personal Account before starting registration | | Sequential Onboarding | Steps must be completed in order: Create Account → Email Verification → Details → Vehicles → Payment | | Step Gating | Users cannot proceed to the next step until the current step validates successfully | | Back Navigation | Users may return to previous steps without losing previously saved data | ##### Validation and System Responses There are no website validations on this screen. ##### Wireframe(s) Figure 48 – Wireframe – Account Type Selection Screen #### Account Creation **Purpose:**** **Capture initial identity and credential information required for user authentication. **Inputs:** First Name (required) Last Name (required) Email Address (required; validated for format and uniqueness) Password - Minimum 8 characters - Must include at least one uppercase and lowercase letters, one digit and one symbol (!, #, $, %, &) Confirm Password (must match Password) Terms & Conditions + Privacy Policy acceptance (required) **Outputs:** Valid submissions generate the user profile. Triggers dispatch of an email verification code. **Controls:** “Create Account” button enabled only when all required inputs pass validation. When a user initiates account creation but does not complete the process, the account is stored in CBOS with a “Pending” status. The user will receive reminder emails containing a secure link that allows them to resume the registration. If the registration is not completed within 7 days, the pending account and all associated data are automatically deleted from CBOS, and the user will need to restart the registration process. ##### Business Rules Table 38 – Business Rules – Account Creation | Rule Name | Description | | --- | --- | | Mandatory Personal Fields | First name, last name, email, password, and confirm password are required | | Email Format Validation | Email must follow valid email structure | | Unique Email | Email must not already exist in the system | | Password Security Policy | Password must be at least 8 characters and include uppercase, lowercase, number, and special character | | Password Match | Confirm password must exactly match password | | Legal Consent Required | Terms & Conditions and Privacy Policy must be accepted before submission | | CTA (Call-to-Action) Enablement Rule | Create Account remains disabled until all required fields are valid | | Account Creation Submission | Valid submission creates account and triggers email verification | ##### Validation and System Responses Table 39 – Validation and System Response – Account Creation | Event | Input | Output | | --- | --- | --- | | User begins entering personal details | First name, last name, email | Fields populate; inline validation runs | | User leaves required fields empty | Missing first name/last name/email | Inline errors shown; Create Account disabled | | User enters invalid email format | Invalid email structure | ERR-EMAIL-001 – Email format invalid Email format error message shown | | User enters email already in use | Email | Error message shown; Create Account disabled | | User enters password failing criteria | Password not meeting rules | Password requirement indicators show unmet rules; Create Account disabled | | User enters mismatching confirm password | Password ≠ confirm password | Mismatch error shown; Create Account disabled | | User does not accept terms | Terms unchecked | Create Account disabled | | User completes all fields correctly | Valid inputs + terms accepted | Create Account enabled | | User clicks Create Account | Valid form submitted | Account creation request submitted; verification code triggered | | System returns submission error | API/validation/server error | Error message shown; user remains on form; inputs preserved where possible | ##### Wireframe(s) Figure 49 – Wireframe – Create Account Screen #### Email Verification **Purpose:**** **Validate the customer’s email address to confirm account ownership. **Inputs:** Code entry field (multi-digit) **Controls****:** “Submit Code” button (enabled only when all input fields are populated) “Request new code” link with rate limiting (1 request per 60 seconds) “Contact Support” link ##### Business Rules Table 40 – Business Rules – Email Verification | Rule Name | Description | | --- | --- | | Mandatory Email Verification | Email must be verified before onboarding can continue | | Verification Code Matching | Entered code must match the system-issued token | | Code Expiry | Verification code expires after a defined time period | | Resend Limiting | Resend requests are rate-limited to prevent abuse | | Onboarding Unlock | Successful verification unlocks onboarding flow | ##### Validation and System Responses Table 41 – Validation and System Responses Handling – Email Verification | Event | Input | Output | | --- | --- | --- | | System sends verification code | Account created | Code emailed to user | | User enters incomplete code | Partial code | Inline error shown; Continue disabled | | User enters incorrect code | Wrong code | Error message shown; user remains on verification screen | | User enters expired code | Expired token | Expired message shown; prompt to resend | | User requests resend code | Resend action | New code issued; confirmation shown | | Code request sent | Code request | 60 second cooldown is applied between each code request; user will not be able to request more than one code per minute | | User submits valid code | Correct full code | Email verified; user progresses to onboarding (Details step) | | System verification fails | Backend error | Error shown; user remains on verification screen | ##### Wireframe(s) Figure 50 – Wireframe – Email Verification Screen #### Onboarding – Personal Details **Purpose:**** **Capture customer demographic and contact information. **Inputs:** Address (auto-lookup enabled) Address Line 2 (optional) City ZIP/Postal Code State/Province Country Mobile Phone (optional; required if SMS notifications are selected) SMS Notification Opt-In (optional) **Controls****:** Address auto-lookup populates fields; manual edits require revalidation. If the user enters a manual address, the system presents the manually entered version and the validated version for final confirmation. “Continue” enabled only after required fields validate. ##### Business Rules Table 42 – Business Rules – Onboarding (Personal Details) | Rule Name | Description | | --- | --- | | Mandatory Address Fields | Address, city, ZIP/postal code, state/province, and country are required | | Country-Driven Validation | Country selection controls postal code format and state options | | Address Validation | Address must validate whether entered manually or via auto-lookup | | Phone Number Validation | Mobile number must follow valid format rules | | SMS Opt-in Dependency | SMS notifications can only be enabled with valid phone number | | Continue Enablement | Continue button enabled only when all required fields validate | ##### Wireframe(s) Figure 51 – Wireframe – Personal Details Screen Figure 52 – Wireframe – Verification Code Screen ##### Validation and System Responses Table 43 – Validation and System Responses – Onboarding (Personal Details) | Event | Input | Output | | --- | --- | --- | | User types address | Partial address | Auto-lookup suggestions displayed | | User selects suggested address | Suggestion selected | Address fields auto populated | | User manually edits address fields | Edited values | Values revalidated | | User leaves required fields empty | Missing address/city/ZIP/ state/country | Inline errors shown; Continue disabled | | User selects country/state | Dropdown selections | State list and validation rules applied | | User enters invalid phone number | Incorrect phone format | Inline error shown | | User opts into SMS notifications | SMS checkbox/toggle selected | SMS enabled (only if phone valid); otherwise, error shown | | User completes all required fields correctly | Valid details | Continue enabled | | User clicks Continue | Valid details submitted | Data saved; If the user manually entered their address, they will be prompted to review both the address they entered and the address returned by postal lookup, and must confirm which one to use; user progresses to Vehicles & Plates | #### Onboarding – Vehicles and Plates **Purpose:**** **Register at least one vehicle used for tolling. Vehicle registration is mandatory. **Inputs:** Country (default: United States) State/Province (default: Colorado) License Plate Number (validated per regional rules) Vehicle Make (dropdown) Vehicle Model Vehicle Type (configured list) **Optional Inputs:** Temporary Plate Toggle - Requires Expiry Date when enabled Temporary Access (Rental) Toggle - Requires start/end date and time - End must occur after start **Controls:** Vehicles appear in a summary list after saving Edit and Remove actions supported At least one vehicle is required to continue **Transponder Options:** Request Transponder (per vehicle) Link Existing Transponder - Serial Number - Activation Code - Mobile app supports QR code scanning; web and mobile version of web supports manual entry only. ##### Business Rules Table 44 – Business Rules – Onboarding – Vehicles and Plates | Rule Name | Description | | --- | --- | | Minimum Vehicle Requirement | At least one vehicle must be added before proceeding | | Required Vehicle Fields | Plate country, plate state, plate number, make, model, and vehicle type are mandatory | | Region-Based Plate Validation | Plate number format validation depends on selected country/state | | Vehicle Edit & Removal | Users may edit or remove vehicles prior to finalization | | Last Vehicle Protection | Removing the last vehicle disables progression | | Temporary Plate Expiry Required | Expiry date required when temporary plate enabled | | Expiry Date Validity | Expiry date must not be in the past | | Temporary Access Date Requirement | Start and end date/time required when enabled | | Valid Date Range | End date/time must occur after start date/time | | Transponder Request Option | User may request a transponder per vehicle | | Manual Linking Requirement | Serial number and activation code required for linking | | Mobile Scan Restriction | Scan feature available only on mobile devices | ##### Validation and System Responses Table 45 – Website Validations – Onboarding – Vehicles Details | Event | Input | Output | | --- | --- | --- | | User selects plate country | Country dropdown | Regional validation rules applied | | User selects plate state/province | State dropdown | State stored; plate validation updated | | User enters plate number | Alphanumeric plate | Inline format validation applied | | User leaves required fields empty | Missing plate/make/ model/type | Inline errors shown; Add Vehicle blocked | | User enables Temporary Plate | Toggle ON | Expiry date field shown and becomes required | | Temporary Plate enabled & User leaves expiry date empty | No expiry date | Validation error: Add Vehicle blocked | | Temporary Plate enabled & User enters invalid expiry date | Past/invalid date | Validation error shown | | User enables Temporary Access | Toggle ON | Start/end date+time fields shown and required | | Temporary Access enabled & User leaves temp access fields empty | Missing start/end | Validation error: Add Vehicle blocked | | Temporary Access enabled & User enters invalid temp access range | End before start | Validation error shown | | User adds valid vehicle | Complete valid vehicle set | Vehicle saved; vehicle appears in summary view | | User attempts to continue without vehicle | No vehicles exist | “Please add at least 1 vehicle…” message; Continue disabled | | System fails to save vehicle | Backend error | Error shown; vehicle not added; user stays on step | Table 46 – Website Validations Onboarding – Vehicles Summary | Event | Input | Output | | --- | --- | --- | | Vehicle is displayed in summary | Saved vehicle | Summary card shown with Edit/Remove actions | | User clicks Edit | Edit action | Vehicle form opens pre-populated | | User clicks Remove | Remove action | Confirmation shown; on confirm vehicle removed | | User removes last vehicle | Last vehicle removed | Continue disabled; “add at least 1 vehicle” message shown | | User toggles Request Transponder | Toggle ON/OFF | Vehicle flagged/unflagged for transponder request | | HOV Question – Always travel with 3 or more passengers? When requesting a transponder, the user will be asked a follow up question related to HOV / road usage. | Toggle YES / NO | If they answer No, they will order a standard transponder. If they answer Yes, they will order a HOV transponder. | | User clicks link transponder | Link action | Transponder linking view opened (for selected vehicle) | | User uses Scan (mobile only) | Scan action | Camera opens; serial auto-populated on success | | User attempts scan on desktop | Desktop device | Scan option not shown; manual entry only | | User submits missing transponder fields | Missing serial or activation code | Inline errors shown; Continue disabled | | User submits invalid transponder values | Invalid codes | Validation error shown | | User submits valid transponder values | Serial + activation code | Transponder linked; user returned to vehicle summary | | System fails to link transponder | Backend error | Error shown; user remains in transponder view | ##### Wireframe(s) Figure 53 – Wireframe – Vehicles and Plates – Add Vehicle Screen Figure 54 – Wireframe – Vehicles and Plates – One Completed Vehicle Screen Figure 55 – Wireframe – Vehicles and Plates – Add Multiple Vehicles Screen Figure 56 – Wireframe – Vehicles and Plates – Request a Transponder Figure 57 – Wireframe – Vehicles and Plates – Link Transponder Screen #### Onboarding – Payments **Purpose:**** **Collect payment details and establish the customer’s payment model. **Payment Models:** Prepaid Account - Requires initial deposit (minimum values defined by CBOS rules) - Requires selection of replenishment amount - Supports Credit/Debit Card, ACH, Google Pay, Apple Pay - Billing address defaults to account address unless overridden Pay-As-You-Go (PAYG) - No initial deposit or replenishment required - Payment method required for future billing - For Business Postpaid accounts: - Account enters “Pending Contract” status until agreements are executed - Tolling functionality remains disabled until activation **Controls:** “Finalize Account” or “Finalize Account & Pay” enabled only when payment method and required fields are valid. Dynamic summary panel reflects fees, deposit, or replenishment selections. Payment failures return appropriate system errors without losing form state. ##### Business Rules Table 47 – Business Rules – Onboarding – Pre-Pay Payments Details | Rule Name | Description | | --- | --- | | Payment Required | Initial payment required before activation | | Replenishment Required | Replenishment amount selection required | | Dynamic Payment Summary | Payment total updates dynamically | | Finalize Enablement | Finalize button enabled only when user fills in all required details, on click triggers the PSP process | Table 48 – Business Rules – Onboarding – PAYG Payments Details | Rule Name | Description | | --- | --- | | No Deposit Requirement | No upfront deposit required | | Payment Method Mandatory | Payment method must be selected | | Fee Visibility | Any applicable fees displayed in payment summary | ##### Validation and System Responses Table 49 – Website Validations – Onboarding – Pre-Pay Payments Details | Event | Input | Output | | --- | --- | --- | | User selects Pre-Pay | Pre-Pay selected | Deposit + replenishment controls displayed | | User edits initial deposit | Deposit amount | Total payable updates dynamically; the minimum deposit will be limited by CBOS rules. | | User does not select replenishment amount | None selected | Finalize disabled; validation message shown, CBOS to confirm if there is a minimum amount a user will need to replenish by. | | User selects payment method | Card/ACH/Wallet | Payment method activated | | User leaves payment method empty | None selected | Finalize disabled | | User toggles billing address same as account | Checkbox on/off | If off, billing address form displayed | | User enters invalid payment details | Invalid card/bank details | Inline error shown; submission blocked This is Payment Service Provider dependent. | | User completes all required fields | Valid deposit + replenishment + payment method | Finalize Account & Pay enabled | | User clicks Finalize Account & Pay | Valid submission | Payment processed; account activated; onboarding completed | | Payment fails | Declined/processing error | Error shown; user remains on payment step; retry available | Table 50 – Website Validations – Onboarding – PAYG Payments Details | Event | Input | Output | | --- | --- | --- | | User selects Pay-As-You-Go | PAYG selected | Deposit/replenishment hidden; PAYG explanation shown | | System shows fees if applicable | Transponder/fees | Amount summary updated accordingly | | User leaves payment method empty | None selected | Finalize disabled | | User toggles billing address same as account | Checkbox on/off | If off, billing address form displayed | | User enters invalid payment details | Invalid input | Inline error shown; submission blocked | | User completes required fields | Valid payment method | Finalize Account enabled | | User clicks Finalize Account | Valid submission | Account activated; onboarding completed; User is sent to the Account Overview | | Finalize fails | Backend/ processing error | Error shown; user remains on payment step; retry available | ##### Wireframe(s) Figure 58 – Wireframe – Payments Screen ### Business Account Creation #### Introduction Creating a CTIO Business Account follows the same structured and guided journey as Personal Account creation, ensuring consistent user experience, validation logic, and system behavior across both account types. The Business Account journey extends the Personal Account flow to support organizational use cases. This includes capturing company-level information, enabling fleet-based vehicle management. Unless explicitly stated otherwise in the sections below, all behaviors, validations, and system responses follow those defined in the Personal Account Creation flow. Table 51 – Key Differences Overview | Area | Business Account Difference | | --- | --- | | Account Creation | Requires Company Name field | | Vehicles & Plates | Supports Bulk Vehicle Upload (CSV) | | Account Status | May remain inactive until contract approval | #### Navigation Flow The following figure depicts the navigation flow of the web user when creating a business account. Each of the steps below is described in more detail in the sections below. It is split in two parts: the digital account creation, the first three steps until the email is verified, and the onboarding, where the user finalizes providing the business as well as the vehicle(s) and payment details. Figure 59 – Business Account Creation Navigation Flow #### Account Type Selection **Purpose:** Identify whether the user is creating a Personal or Business account. This section covers Business Account selection. **Controls:** “Type of Account” radio button Title: “Sign up for a new account” Account category selector (Personal / Business) **Behavior:** The Account Type Selection step follows the same behavior as defined in the Personal Account flow. When the user selects the Business Account option, the system routes the user to the Business Account creation form. ##### Business Rules Table 52 – Business Rules – Account Type Selection (Business) | Rule Name | Description | | --- | --- | | Sequential Onboarding | All subsequent steps follow the same sequence as the Personal Account creation flow | | Step Gating | Users cannot proceed until the current step validates successfully | ##### Validation and System Responses Handling There are no additional website validations on this screen. ##### Wireframe Figure 60 – Wireframe – Account Type Selection Screen #### Account Creation **Purpose:** Capture the business identity and credential information required for user authentication. **Inputs:** Company Name (required) First Name (required) Last Name (required) Email Address (required; validated for format and uniqueness) Password Confirm Password Terms & Conditions and Privacy Policy acceptance (required) **Controls:** “Create Account” button enabled only when all required inputs pass validation. **Behavior****:** The Business Account creation form follows the same structure and validation logic as the Personal Account creation form, with the addition of a Company Name field. ##### Business Rules Table 53 – Business Rules – Account Creation (Business) | Rule Name | Description | | --- | --- | | Mandatory Company Field | Company Name is required for Business Account creation | | Email Validation | Email must follow valid format and be unique | | Password Policy | Password must meet defined security requirements | | Legal Consent Required | Terms & Conditions must be accepted before submitting | ##### Validation and System Responses Table 54 – Validation and System Response – Account Creation (Business) | Event | Input | Output | | --- | --- | --- | | User leaves Company Name empty | Missing company name | Inline error shown; Create Account disabled │ | | User enters email already in use | Email | Error message shown; account creation blocked | | User enters invalid inputs | Invalid values | Inline validation errors displayed | | User completes all fields correctly | Valid inputs | Create Account enabled | | User clicks Create Account | Valid submission | Account created; verification code triggered | | Backend failure | | Error message shown; user remains on form | ##### Wireframe Figure 61 – Wireframe – Create Account (Business) Screen #### Email Verification **Purpose:** Validate the customer’s email address to confirm account ownership. **Behavior:** The Email Verification step follows the same process as defined in the Personal Account flow. This includes verification code entry, validation handling, expiry rules, and resend behavior. No additional Business-specific behavior is introduced at this stage. All business rules follow the Personal Account Creation flow. All validations and system responses follow the Personal Account Creation flow. ##### Business Rules Table 55 – Business Rules – Email Verification | Rule Name | Description | | --- | --- | | Mandatory Email Verification | Email must be verified before onboarding can continue | | Verification Code Matching | Entered code must match the system-issued token | | Code Expiry | Verification code expires after a defined time period | | Resend Limiting | Resend requests are rate-limited to prevent abuse | | Onboarding Unlock | Successful verification unlocks onboarding flow | ##### Validation and System Responses Table 56 – Validation and System Responses Handling – Email Verification | Event | Input | Output | | --- | --- | --- | | System sends verification code | Account created | Code emailed to user | | User enters incomplete code | Partial code | Inline error shown; Continue disabled | | User enters incorrect code | Wrong code | Error message shown; user remains on verification screen | | User enters expired code | Expired token | Expired message shown; prompt to resend | | User requests resend code | Resend action | New code issued; confirmation shown | | Code request sent | Code request | 60 second cooldown is applied between each code request; user will not be able to request more than one code per minute | | User submits valid code | Correct full code | Email verified; user progresses to onboarding (Details step) | | System verification fails | Backend error | Error shown; user remains on verification screen | ##### Wireframe Figure 62 – Wireframe – Email Verification Screen #### Onboarding – Business Details **Purpose:** Capture business address and contact information required for billing, communication, and account correspondence. **Behavior:** This step follows the same structure and behavior as the Personal Details step, including address auto-lookup, manual override handling, and notification preferences. For Business Accounts, the information captured represents the company’s address and contact details rather than individual user information. Where applicable, users may specify a delivery address that differs from the primary company address. ##### Business Rules Table 57 – Business Rules – Onboarding (Business Details) | Rule Name | Description | | --- | --- | | Mandatory Address Fields | Company address fields must be completed | | Delivery Address Option | User may specify a separate delivery address | | Shared Validation Logic | All address and phone validation rules follow Personal flow | ##### Validation and System Responses Table 58 – Validation and System Responses – Onboarding (Business Details) | Event | Input | Output | | --- | --- | --- | | User overrides address | Manual input | Address confirmation prompt displayed | | User completes all required fields | Valid data | Continue enabled; progresses to Vehicles | ##### Wireframe(s) Figure 63 – Wireframe – Details Screen Figure 64 – Wireframe – Address Confirmation Figure 65 – Wireframe – Phone Verification #### Onboarding – Vehicles and Plates **Purpose:** Register vehicles used for tolling under the Business Account. **Behavior:** The manual vehicle registration flow, validation logic, conditional fields, and transponder functionality follow the same behavior as defined in the Personal Account flow. Business Accounts extend this step by enabling bulk vehicle registration to support fleet onboarding. Business users may upload multiple vehicles using a CSV file. Uploaded vehicles are processed using the same validation rules as manually entered vehicles and are displayed within a structured table view to support large datasets. ##### Business Rules Table 59 – Business Rules – Onboarding – Vehicles (Business) | Rule Name | Description | | --- | --- | | Bulk Upload Availability | Available for Business Accounts only | | CSV Format Requirement | Uploaded file must follow defined structure | | Shared Vehicle Validation | Same validation logic as manual entry | | Fleet Management Support | Vehicles displayed in structured table view | | Minimum Vehicle Requirement | At least one valid vehicle required | ##### Validation and System Responses Table 60 – Validation and System Responses – Onboarding – Vehicles (Business) | Event | Input | Output | | --- | --- | --- | | User uploads CSV | Valid file | Vehicles added successfully | | User uploads invalid file | Incorrect format | Error shown | | User edits vehicle | Edit action | Editable form displayed | | User removes vehicle | Remove action | Confirmation prompt shown | ##### Wireframe(s) Figure 66 – Wireframe – Add Vehicle Screen Figure 67 – Wireframe – Vehicle Summary Figure 68 – Wireframe – Bulk Upload Modal Figure 69 – Wireframe – Bulk Vehicles Table Figure 70 – Wireframe – Link Transponder #### Onboarding – Payments **Purpose:** Collect payment details and establish the Business Account payment model. **Behavior:** The Payment step follows the same structure as the Personal Account flow. ##### Wireframe(s) Figure 71 – Wireframe – Payments Screen (Pre-Pay) Figure 72 – Wireframe – Payments Screen (Postpaid) ### Additional Account Plans Following sections depict other account plans that have special rules. #### Non-Revenue ##### Introduction The Non-Revenue Plan allows eligible customers to travel on designated roadways free of charge, provided the plan is active on their account. To obtain this plan, customers must submit a formal request. Requests can be submitted via the website (Contact Us form) or through email and must include, at minimum: contact person details, justification for eligibility, vehicle plates to be included, requested roadways/toll points for exemption, and a payment method for any tolls incurred outside the approved scope. A designated non-revenue agent reviews the request and, upon approval, configures the account by assigning the specified vehicle plates in the CBOS and applying toll exemptions to the approved roadways. Once set up, all qualifying transactions for those vehicles on the approved toll points are processed free of charge. ##### Business Rules Table 61 – Business Rules – Non-Revenue Plan | Rule Name | Description | | --- | --- | | No Online Account Creation | Non-revenue accounts cannot be created through the website; requests must be submitted via the Contact Us form or email. | | Mandatory Approval Process | All requests must be reviewed and approved by CTIO. Once approved, an authorized CSR will proceed with the account creation | | Restricted Plan Management | Customers cannot manage or modify the non-revenue plan directly via the website. | | Vehicle Changes via Request | Adding or removing vehicles from the plan requires submission of a new request via the Contact Us form or email | | Plan Scope Changes via Request | Any changes to eligible roadways or toll points must follow the same request and approval process. | | Account Access Provision | Upon approval and setup, customers are provided with login credentials to access the portal. | | Limited Portal Capabilities | Non-revenue users have restricted functionality within the portal. | | Allowed Actions | Users can add/remove payment methods, make payments, download statements/transactions, and request account closure. | | Restricted Actions | Users cannot add/remove vehicles, modify personal details, or add authorized users through the portal. | | Payment Coverage Rule | A valid payment method must be maintained for tolls incurred outside the non-revenue coverage. | #### Equity ##### Introduction The Equity Plan provides eligible customers with an annual balance (e.g. $100 per vehicle) that can be used exclusively on designated roadways or toll points. The plan is administered by third-party vendors. Customers apply for the Equity Plan directly through the third-party vendor. Once approved, the vendor submits the list of eligible customers and associated data to CBOS via case management for review and operational processing. The plan is assigned at vehicle level (License Plate + Transponder). CBOS agents are responsible for creating and configuring the plan in the backend. ##### Business Rules Table 62 – Business Rules –Equity Plan | Rule Name | Description | | --- | --- | | Third-Party Request Only | Equity Plan must be requested through approved third-party vendors; it cannot be created via the website. | | Backend Account Setup | Approved Equity Plans are created by agents in CBOS based on vendor-provided data. | | Vehicle-Level Assignment | Equity Plan is assigned to a specific vehicle (License Plate + Transponder). | | Annual Balance Allocation | Each approved vehicle receives a defined annual balance (e.g. 100 units). | | Priority Consumption Rule | Equity balance is consumed before any prepaid account balance. | | No Fund Transfer | Equity funds cannot be transferred between vehicles or accounts. | | Vehicle Restriction | Equity funds are strictly limited to the assigned vehicle and cannot be used by other vehicles. | | Debt Restriction | Equity Plan cannot be added to an account with outstanding debt. | #### HOV (High Occupancy Vehicle) Purist ##### Introduction The HOV Purist Plan is a discount configuration available to eligible private prepaid customers, allowing travel on designated HOV roadways free of charge when applicable occupancy requirements are met. The plan is linked to a specific vehicle and transponder pairing, and HOV occupancy verification is required to qualify for non-revenue treatment. HOV Purist accounts can be created through self-service via the website or mobile application. The plan is limited to private prepaid accounts and does not require an initial payment, starting balance, or upfront transponder fee. Where applicable, a switchable transponder is issued free of charge during account creation. ##### Business Rules Table 63 – Business Rules – HOV | Rule | Description | | --- | --- | | Self-Service Enrollment | HOV Purist accounts can be created via website or mobile self-service registration. | | Private Prepaid Only | The plan is available only to private prepaid account types. | | No Initial Payment | No upfront payment or starting balance is required during account creation. | | Occupancy Verification Required | HOV occupancy validation is required to qualify for non-revenue treatment. | | Designated Roadway Restriction | Benefits apply only on configured HOV roadways or toll points. | | Vehicle and Transponder Binding | The HOV Purist plan is linked to a specific vehicle and transponder pairing. | | Prepaid Account Rules Apply | Standard prepaid account rules continue to apply for non-HOV toll activity. | ### Sign In #### Introduction **Purpose:**** **Enables registered users to authenticate and access their Personal Account within the CTIO User Portal. Once authenticated, users can manage their account information, vehicles, payment methods, invoices, disputes, and other related account activities. Users access the sign-in form by selecting the Sign in option from the website interface. Upon successful authentication, users are redirected to the Account Overview page. **Inputs****:** Email address Password Remember-me selection **Outputs****:** Successful login and redirection to the Account Overview page Authentication error message when credentials are invalid Account lock after repeated failed attempts Redirection to the **Forgot Password** flow when account lock occurs #### Navigation Flow Figure 73 – Flow – Registered Account Sign In Online Figure 74 – Flow – Forgotten Password #### Business Rules Table 64 – Business Rules – Sign-In Form | Rule Name | Description | | --- | --- | | Registered Users Only | Only users with a registered account may authenticate using the sign-in form. | | Credential Validation | Email and password credentials must be validated against backend authentication services. | | Password Minimum Length | Password must meet security policy. | | Required Fields | Both email and password fields must be completed before the login action is enabled. | | Invalid Credential Handling | If credentials are invalid, login is blocked and an error message is displayed. | | Account Lock Protection | After three consecutive failed authentication attempts (configurable), the account is temporarily locked. | | Forced Password Reset | When an account becomes locked due to failed login attempts, the user must complete the password reset flow to regain access. | | Persistent Session Option | If the user selects “Remember me,” the session persistence is stored securely according to authentication security policies. | | Secure Transmission | All credentials are transmitted using encrypted secure protocols. | | Authentication Redirect | Successful authentication redirects the user to the Account Overview page. | #### Validation and System Responses Handling Table 65 – Validation and System Responses – Sign-In Form | Event | Input | Output | | --- | --- | --- | | User enters password with less than 8 characters / or does not meet complexity requirements | Password | Sign-in button remains disabled | | User leaves required fields empty | Email and/or Password missing | Log in button remains disabled and cannot be clicked | | User enters valid email and password and clicks Log in | Email, Password | Credentials submitted; if valid, user is authenticated and redirected to Account Overview | | User enters invalid email or password and clicks Log in | Email, Password | Inline error message displayed; authentication blocked | | User exceeds failed login attempt limit | Multiple failed login attempts | Account temporarily locked | | Account lock occurs | Locked account | User redirected to Forgot Password flow | | Account locked message displayed | Locked account | “Due to multiple failed attempts, this account has been locked. Please reset your password to regain access.” | | User clicks Forgot your password | Forgot password action | User redirected to password reset flow | | User selects Remember me | Checkbox selected | Persistent session preference stored securely | #### Wireframe(s) Figure 75 – Wireframes – Sign In ### First-Time Login #### Introduction **Purpose**: Enables users whose account was created outside the self-service registration flow to activate their online access and create their login credentials. The purpose of this flow is to allow the user to verify ownership of the email address associated with the account and create a secure password for future sign-in to the CTIO User Portal. This section covers the following steps: Step 1 – Verify Email Step 2 – Create Password To avoid duplication and maintain consistency with the wider authentication journey: Password policy and authentication rules should align with the standard Sign-In / Reset Password flows. API-level validations are defined in DDD (CDRL06), Volume 6, Interfaces. Back-office and CBOS-driven business rules are defined in DDD (CDRL06), Volume 2, Emovis Transact CBOS. #### Navigation Flow Figure 76 – Flow – First-Time Login #### Email Verification **Purpose:**** **Confirms that the user has access to the email address associated with the account created by CTIO or its representatives. This protects account access and ensures that login credentials are created only by the intended account holder. **Inputs****:** Verification code **Outputs****:** Verified email address Progression to Create Password step New verification code sent, where resend is requested successfully ##### Business Rules Table 66 – Business Rules – First-Time Login Verify Email | Rule Name | Description | | --- | --- | | Mandatory Email Verification | The user must complete email verification before they are allowed to create login credentials. | | Verification Code Matching | The entered code must match the verification code issued for the account activation journey. | | Code Expiry | Verification codes expire after a defined period according to authentication rules. | | Submit Gating | The Submit Code button remains disabled until all verification code fields are completed. | | Resend Limiting | Requests for a new code are rate-limited to prevent abuse. | | Contact Support Path | A Contact Support link must be displayed in case the user does not receive the verification email. | | Sequential Progression | Successful code verification is required before the Create Password step is shown. | | Account Context Binding | The verification code must be associated with the correct pre-created account and email address. | ##### Validation and System Responses Handling Table 67 – Validation and System Responses – First-Time Login Verify Email | Event | Input | Output | | --- | --- | --- | | User enters incomplete verification code | Partial code input | Submit Code button remains disabled | | User enters invalid verification code | Invalid verification code | Inline error message displayed; verification fails | | User enters valid verification code | Complete valid code | Code submitted for validation; loading state displayed | | User submits expired verification code | Expired verification code | Error message displayed; user prompted to request a new code | | User requests a new verification code | Click on Request new code | New verification code sent; countdown timer resets | | User completes verification successfully | Valid verification code | Email verified; user progresses to Create Password step | ##### Wireframe(s) Figure 77 – Wireframe – First-Time Login Verify Email #### Create Password **Purpose: **The Create Password step allows the user to create their online login credentials for the first time following successful email verification. **Inputs:** New password Confirm password **Outputs:** Online login credentials created Password stored securely First-time login flow completed ##### Business Rules Table 68 – Business Rules – First-Time Login Create Password | Rule Name | Description | | --- | --- | | Verified Entry Requirement | The Create Password step is available only after successful first-time email verification. | | Mandatory Password Fields | Both password fields are required. | | Password Security Policy | Password must meet configured password complexity requirements. | | Password Match Rule | Confirm Password must match the Create Password field. | | Visibility Toggle Support | Both password fields may include show / hide controls. | | CTA Enablement Rule | The Create Password button remains disabled until both fields are completed, passwords match, and all password rules are satisfied. | | Secure Credential Creation | Password creation must be processed securely using the authentication service. | | Completion Outcome | Once the password is successfully created, the first-time login setup is complete, and the user can access standard sign-in using their email address and password. | ##### Validations and System Responses Table 69 – Validation and System Responses – First-Time Login Create Password | Event | Input | Output | | --- | --- | --- | | User enters password that does not meet requirements | Invalid password value | Password guidance indicates unmet criteria; Create Password button remains disabled | | User enters passwords that do not match | Password, Confirm Password | Inline mismatch error shown; Create Password button remains disabled | | User enters valid matching passwords | Valid password pair | All guidelines satisfied; Create Password button becomes enabled | | User clicks Create Password | Valid matching passwords | Credentials submitted securely; password created successfully | | System error occurs during password creation | Credential creation request | Error message displayed; user remains on Create Password page | | User completes password creation successfully | Valid credential setup | First-time login flow completed; user redirected to login page or authenticated account entry point, depending on configured implementation | ##### Wireframe(s) Figure 78 – Wireframe – First-Time Login Create Password ### Forgot Password #### Introduction **Purpose:**** **Enables users who cannot access their account due to a forgotten password to initiate the password recovery process. Users can access this form by clicking the “Forgot your password?” link on the Sign-In form. Additionally, users who have been temporarily locked out after multiple failed login attempts are automatically redirected to the Forgot Password journey. When redirected due to account lock, the following message will be displayed: “Due to multiple failed attempts, this account has been locked. Please reset your password to regain access.” The password reset process is handled through secure backend authentication services that generate a time-limited password reset link sent to the user’s email address. **Inputs****:** Email address **Outputs****:** Password reset email sent to user Confirmation message displayed to the user Validation errors where applicable #### Business Rules Table 70 – Business Rules – Forgot Password | Rule Name | Description | | --- | --- | | Password Reset Entry Point | Users can access the Forgot Password form from the Sign-In page or after account lock due to multiple failed login attempts. | | Valid Email Requirement | The reset link request requires a valid email address format. | | Backend Account Verification | The system checks whether the email address is associated with an existing account. | | Secure Email Handling | The reset email is sent only through secure backend authentication services. | | Account Lock Recovery | Users whose accounts are locked after multiple failed login attempts must complete the password reset process to regain access. | | Reset Link Security | Password reset links are time-limited and may only be used once. | | Information Disclosure Protection | Error responses must not expose whether an email address is registered beyond necessary guidance. | #### Validations and System Responses Table 71 – Validation and System Responses – Forgot Password | Event | Input | Output | | --- | --- | --- | | User enters valid email and clicks “Email me a reset link” (account exists) | Email address linked to account | Password reset email sent to the provided address; confirmation message displayed | | User enters valid email and clicks “Email me a reset link” (no account found) | Email address not linked to account | Inline message displayed prompting user to sign up | | User enters invalid email format | Invalid email input | Form submission blocked; inline validation error displayed | | User leaves email field empty | No email entered | Reset button remains disabled | | User account locked after multiple failed login attempts | Locked account | User redirected to Forgot Password flow and lock message displayed | #### Wireframe(s) Figure 79 – Wireframes – Forgot Password Form ### Reset Password #### Introduction **Purpose:**** **Page allows a user to create a new account password after initiating the password recovery process through the Forgot Password flow. Users access this page via a secure password reset link sent to their registered email address. The link contains a time-limited password reset token that validates the user’s identity and allows them to create a new password. Once the password has been successfully updated, the reset flow is completed, and the user is redirected to the Sign-In page. **Inputs****:** New password Confirm new password **Outputs****:** Updated account password Completion of the password reset flow Redirect to the Sign-In page Validation messages where applicable #### Navigation Flow Figure 80 – Flow – Reset Password #### Web Business Rules Table 72 – Business Rules – Reset Password | Rule Name | Description | | --- | --- | | Password Requirement Enforcement | New passwords must meet all configured password complexity rules. | | Password Match Validation | The New Password and Confirm Password fields must match before submission is allowed. | | Required Fields | Both password fields must be completed before submission. | | Secure Password Update | Password updates are processed through secure backend authentication services. | | Completion Redirect | After a successful password reset, the user is redirected to the Sign-In page. | | Invalid Token Handling | If the reset token is expired or invalid, the user must restart the Forgot Password process. | #### Validation and System Responses Handling Table 73 – Validation and System Responses – Reset Password | Event | Input | Output | | --- | --- | --- | | User enters passwords that do not match | New password, Confirm password | Inline validation error displayed; button remains disabled | | User enters password not meeting requirements | New password | Inline validation message displayed; submission blocked | | User enters valid matching passwords | New password, Confirm password | Password guidelines satisfied; “Set new password” button becomes enabled | | User clicks “Set new password” | Valid matching passwords | Password updated successfully; user redirected to Sign-In page | | User accesses page with expired or invalid token | Reset token | Error message displayed; user prompted to restart Forgot Password flow | **Password Creation Guidelines****:** Displayed directly below the password fields. Provides clear requirements for acceptable passwords. Example guidelines include: - At least 8 characters - At least 1 uppercase and 1 lowercase character - At least 1 special character and 1 numeric character These guidelines provide real-time feedback to the user as password conditions are satisfied. #### Wireframe(s) Figure 81 – Wireframes – Reset Password Page ### Multi-Account Switcher #### Introduction The Multi-Account Switcher enables a logged-in user to access and manage multiple accounts where those accounts are related through a parent / child account structure. The feature supports a primary account with linked sub-accounts, allowing an account holder to move between accounts and access the relevant management portal for each one. This section also defines the related Profile Settings and Authorized Contacts areas, as these are accessed from the same authenticated header controls and form part of the same account access model. The account hierarchy supports: Primary account One or more linked child / sub-accounts Authorized contact profiles with credential-based access to one or more accounts, subject to assigned permission level. Child accounts are not created online by the end user. Where an account owner wishes to add a child account, this must be completed through CSR. Once created by CSR, the child account will be surfaced on the Multi-Account Switcher page as a separate account card with its own account information and dashboard entry point. If the authenticated user has only one account available to them, the Multi-Account Switcher page is bypassed, and the user is directed straight to the relevant account management overview page. The header account menu provides direct access to: View Account Profile Settings Authorized Contacts Logout Email addresses are unique within the system, and an authorized contact is not treated as a separate full account but as an additional credential-based profile attached to one or more accounts. #### Navigation Flow Figure 82 – Global Navigation Controls – Logged In Users #### Multi-Account Switcher Page **Purpose****:** The Multi-Account Switcher page provides the authenticated user with a central landing page from which they can select and enter any accessible account within their account hierarchy. **Inputs:** Accessible account list Account number Account type Vehicle count Balance, where applicable **Outputs:** Account selection Navigation into selected account dashboard Routing into profile settings **Controls:** The Multi-Account Switcher page consists of: Page title Accounts section heading Account count indicator Repeating account cards displaying: - Account Number - Account Type - Vehicle Count - Current Balance, where applicable View Account Dashboard CTA Account settings icon ##### Business Rules Table 74 – Business Rules – Multi-Account Switcher Page | Rule Name | Description | | --- | --- | | Accessible Accounts Only | Only accounts available to the authenticated user may be shown on the page. | | Full Account Card Display | Each CSR-created child account must be presented as a separate full account on the page. | | Contextual Balance Display | Balance is displayed where the account type supports / returns it. | | Account Management Entry Point | View Account Dashboard opens the selected account overview page. | | Settings Shortcut | The settings icon opens Profile Settings overview rather than the account overview. | ##### Validation and System Responses Table 75 – Website Validations – Multi-Account Switcher Page | Event | Input | Output | | --- | --- | --- | | Page loads | Multiple accessible accounts | Account cards displayed | | User selects View Account Dashboard | CTA click | Selected account overview page displayed | | User selects settings icon | Icon click | Profile Settings overview displayed | ##### Wireframe(s) Figure 83 – Wireframes – Multi-Account Switcher Page #### Header Account Menu **Purpose****:** The Header Account Menu provides direct access to account switching, profile actions and logout functions from anywhere within the authenticated experience. **Inputs****:** Authenticated user context Current account context **Outputs****:** Navigation to account switcher Navigation to profile settings Navigation to authorized contacts Logout **Controls****:** The Header Account Menu consists of: View Accounts Profile Settings Authorized Contacts Logout ##### Wireframe(s) Figure 84 – Wireframes – Global User Menu #### Profile Settings Overview **Purpose****:** The Profile Settings Overview page provides the authenticated user with access to their own profile-level settings and account credential management. **Inputs:** Profile creation date Profile email address **Outputs:** Navigation to Personal Information Navigation to Security and Password Settings **Controls****:** The Profile Settings Overview consists of: Profile summary card showing: - Date Joined - Email Personal Information card / CTA Security and Password Settings card / CTA ##### Wireframe(s) Figure 85 – Wireframes – Profile Settings Overview #### Personal Information **Purpose:** The Personal Information view allows the authenticated user to review and update their own profile information. **Inputs:** First name Last name / display name Email address Mobile number Date of birth **Outputs****:** Updated profile information **Controls****:** The Personal Information view consists of: Back navigation Summary card displaying profile details Edit Details CTA Update Personal Details modal ##### Business Rules Table 76 – Business Rules – Personal Information | Rule Name | Description | | --- | --- | | Self-Profile View | The authenticated user views their own personal information in this section. | | Edit Action Availability | Edit Details opens the update modal for permitted fields. | | Profile-Level Update | Changes apply to the user profile rather than universally rewriting all account-level data. | ##### Validation and System Responses Table 77 – Website Validations – Personal Information | Event | Input | Output | | --- | --- | --- | | User opens Personal Information | Navigation action | Current personal information displayed | | User selects Edit Details | CTA click | Update Personal Details modal opened | | User submits valid profile updates | Valid input | Profile saved and summary refreshed | | User submits invalid profile updates | Invalid or missing input | Validation error displayed | ##### Wireframe(s) Figure 86 – Wireframes – Personal Information View Figure 87 – Wireframes – Update Personal Details Modal #### Update Personal Details Modal **Purpose:** The Update Personal Details modal allows the authenticated user to amend editable profile fields. **Inputs****:** First Name Last Name Date of Birth Email Address Mobile Number **Outputs****:** Updated profile data Updated verification status where applicable **Controls****:** The Update Personal Details modal consists of: Modal title Close (x) control First Name field Last Name field Date of Birth field Email Address field Mobile Number field Verify button Update Details CTA ##### Wireframe(s) Figure 88 – Wireframes – Update Personal Details Modal #### Security and Password Settings **Purpose****: **The Security and Password Settings view allow the authenticated user to manage the email used for login and access related credential actions. **Inputs:** Current email address **Outputs:** Password reset initiation Email update initiation **Controls:** The Security and Password Settings view consist of: Back navigation Informational text Current Email Address display Reset Password CTA – user is directed to reset password flow Update Email CTA – user is directed to update email flow ##### Wireframe(s) Figure 89 – Wireframes – Security and Password Settings View #### Authorized Contacts Overview **Purpose**: The Authorized Contacts Overview allows the account owner to review all authorized contacts associated with the current account and to add or update credential-based contacts together with their permission levels. **Inputs****:** Authorized contact list Relationship Permission level summary Current account context Linked sub-account context **Outputs****:** Display of contact list Navigation to Authorized Contact Details form Add Authorized Contact action **Controls****:** The Authorized Contacts Overview consists of: Back navigation Description text Repeating authorized contact cards showing: - Name - Relationship - Permissions summary Row arrow action Add Authorized Contact CTA ##### Navigation Flow Figure 90 – Flow – Authorized Contacts – Add ##### Business Rules Table 78 – Business Rules – Authorized Contacts Overview | Rule Name | Description | | --- | --- | | Current Account Context | The page is opened within a selected account context | | Cross-Sub-Account Visibility | In addition to the current account’s authorized contacts, the user must be able to review linked sub-account authorized contacts and their permission structures. | | Permission Summary Display | Each listed contact must display the headline permission level currently assigned in that account context. | | Add Contact Entry Point | The Add Authorized Contact CTA opens the contact details / creation form. | ##### Validation and System Responses Table 79 – Website Validations – Authorized Contacts Overview | Event | Input | Output | | --- | --- | --- | | User selects a contact | Row action | Authorized Contact Details form opened | | User selects Add Authorized Contact | CTA click | Blank Authorized Contact Details form opened | ##### Wireframe(s) Figure 91 – Wireframes – Authorized Contacts Overview #### Authorized Contact Details **Purpose:** The Authorized Contact Details form allows the account owner to create or update a credential-based authorized contact and assign permissions across individual accounts / sub-accounts. **Inputs:** Contact email address First name Last name Mobile number Account-level permission assignments **Outputs:** New or updated authorized contact Saved permission matrix per account / sub-account **Controls:** The Authorized Contact Details form consists of: Back navigation Form title Contact email field First Name field Last Name field Mobile Number field Permissions section Permissions matrix containing: - Account Number - Full Access - Restricted - No Access Update Details CTA ##### Business Rules Table 80 – Business Rules – Authorized Contact Details | Rule Name | Description | | --- | --- | | Email-Based Credential Identity | Email is used as the unique identifier for the authorized contact credential set. | | One Contact / Many Account Permissions | A single authorized contact may be granted different permissions across multiple accounts / sub-accounts. | | Per-Account Exclusivity | For each account row, only one permission state may be active at a time. | | Full Access Behavior | Full Access grants the same operational capability as the account holder for that account. | | Restricted Behavior | Restricted access excludes payment details / payment method management (read only) | | No Access Behavior | No Access removes account visibility for that authorized contact | | Account Owner Managed | Only the account owner or an appropriately permitted user may manage authorized contact permissions. | #### Validation and System Responses Table 81 – Website Validations – Authorized Contact Details | Event | Input | Output | | --- | --- | --- | | User opens details form | Existing or new contact | Form displayed | | User enters duplicate email | Existing system email already in use | Validation error displayed | | User leaves required fields incomplete | Missing mandatory data | Validation errors shown | | User submits valid form | Valid contact + permissions | Contact saved and permissions updated | ##### Wireframe(s) Figure 92 – Wireframes – Authorized Contact Details Form ### Personal Account Management #### Introduction The Personal Account Management provides registered CTIO customers with a secure and centralized environment to manage their tolling accounts after successful onboarding and activation. The portal enables users to access and maintain account information, review transaction activity, manage vehicles and transponders, make payments, upload or review documents, and interact with customer support services. The portal is designed as a self-service interface that supports ongoing account management across web and mobile applications. All information displayed within the portal is dynamically retrieved from backend systems and scoped exclusively to the authenticated user. Portal layout, navigation, and interactive functionality are system-defined and are not managed through the CMS. CMS usage is limited to static labels, helper text, and informational content where applicable. The portal interface is structured around modular components that provide a high-level overview of account status while allowing users to navigate to detailed account management sections. After successful authentication, the user is directed to the Account Overview Dashboard, which acts as the primary entry point for account management. From the dashboard, the user can access the following account modules through the persistent global navigation: Dashboard Vehicles Payments Documents Account History Cases & Disputes Safety Enforcement Account Settings Each module represents a dedicated management area that allows the user to view or modify specific aspects of their CTIO account. The Overview page aggregates key account information and provides shortcuts to common actions such as adding funds, reviewing transactions, or managing vehicles. Navigation between sections does not require reauthentication during an active session, and all views dynamically retrieve the most recent account information from backend systems. #### Navigation Flow Figure 93 – Account Management Functionality Overview #### Global Account Header Component **Purpose:** The Global Account Header is a persistent navigation component displayed across all authenticated pages of the Personal Account User Portal. It provides users with consistent access to all account management sections and confirms successful authentication through a personalized greeting. **Controls:** Navigation tabs for account sections Active tab indicator Greeting message displaying the user’s name when available ##### Business Rules Table 82 – Business Rules – Global Account Header Component | Rule Name | Description | | --- | --- | | Persistent Navigation | The Global Account Header must appear on all authenticated pages within the portal | | Navigation Routing | Each navigation tab must route to its corresponding account module view. | | Active State | The currently active module must be visually highlighted in the navigation tabs. | | Personalized Greeting | The greeting must display the authenticated user's first name retrieved from profile data. | | Fallback Greeting | If the user's name is unavailable, a default greeting must be displayed. | ##### Validations and System Responses Table 83 – Website Validations – Global Account Header Component | Event | Input | Output | | --- | --- | --- | | User accesses portal | Authenticated session | Global Account Header displayed | | User profile retrieved | First name available | Greeting displays user's first name | | User profile missing name | No name data | Default greeting displayed | | User clicks navigation tab | Tab selection | System routes user to selected module | ##### Wireframe(s) Figure 94 – Wireframe – Personal Account Management Overview Figure 95 – Wireframe – Global Account Header Component #### Personal Account Overview **Purpose:** The Personal Account Overview page serves as the primary dashboard for authenticated users. It provides a consolidated summary of account status, financial balance, recent transactions, vehicle information, and shortcuts to common account management actions. The overview dashboard allows users to quickly understand their current account standing and access key management functions without navigating through multiple sections. **Inputs****:** Account financial data (balance / pending tolls) Account number Payment method information Reward points data Transaction data Vehicle and transponder data Account alerts All inputs are retrieved from backend systems including CBOS. **Outputs****:** Account balance summary Recent transaction summary Vehicle summary information Reward points overview Account alerts Quick access navigation links Access to account management sections **Controls:** The Overview page contains the following functional components: Account Balance Card Add Funds Modal Auto-Replenishment Settings Recent Account History Component Quick Links Component Vehicle Summary Card ##### Account Balance Card **Purpose**: The Account Balance Card provides a visual summary of the user's financial account status and payment configuration. It displays the current prepaid balance or pending toll transactions depending on the account type and allows the user to perform balance-related actions. **Inputs:** Account balance Account number Default payment method Account alert status Auto-replenishment configuration **Outputs:** Display of prepaid account balance or pending toll activity Display of account alerts Display of payment configuration **Controls:** Add funds button Edit default payment method link Edit your auto replenishment settings link ###### Business Rules Table 84 – Business Rules – Account Balance Card | Rule Name | Description | | --- | --- | | Balance Display | The system must display the current prepaid account balance for prepaid accounts. | | Postpaid Behavior | For postpaid accounts balance should be shown to indicate the amount of unpaid tolls. | | Account Number Display | The account number must be visible within the balance card. | | Payment Method Masking | Default payment methods must be displayed using masked details. | | Alert Visibility | Account alerts such as arrears must be displayed when applicable. | ###### Validation and System Responses Table 85 – Website Validations – Account Balance Card | Event | Input | Output | | --- | --- | --- | | User accesses dashboard | Account data retrieved | Balance card populated | | Account in arrears | Alert flag returned | Arrears alert displayed | | User clicks Add Funds | Button click | Add Funds modal opened | | User clicks Edit payment method | Link click | User redirected to payment management | ###### Wireframe(s) Figure 96 – Wireframe – Account Balance Card Figure 97 – Wireframe – Add Funds Modal ##### Add Funds Modal **Purpose****:** The Add Funds modal enables users to add credit to their prepaid account through a one-time payment transaction. The modal is presented as an overlay that prevents interaction with the underlying page until the transaction is completed or cancelled. **Inputs:** Recommended top-up amount (system generated) Default payment method Card verification code (CVC) Alternative payment method selection **Outputs:** Payment transaction request Updated account balance Payment confirmation **Controls:** Close modal control Editable top-up amount field Card verification input field Add Funds action button Alternative payment method selection options ###### Business Rules Table 86 – Business Rules – Add Funds Modal | Rule Name | Description | | --- | --- | | Recommended Amount | The system generates a recommended top-up amount based on recent toll activity. | | Editable Amount | Users may modify the recommended top-up amount. | | Default Payment Method | The system displays the configured default payment method | | CVC Requirement | The user must enter the card verification code for stored card payments. | | Alternative Payment Methods | Users may select alternative payment options depending on PSP capabilities. | | Modal Blocking | Interaction with background content is disabled while the modal is active. | ###### Validations and System Responses Table 87 – Website Validations – Add Funds Modal | Event | Input | Output | | --- | --- | --- | | Modal opens | Add Funds selected | Recommended amount displayed | | User edits amount | New amount | Updated amount stored for payment | | CVC missing | Empty input | Add Funds button disabled | | User enters CVC | Valid input | Add Funds button enabled | | User enters CVC | Invalid input | Error message shown | | Payment submitted | Payment request | Transaction processed via PSP | | Payment fails | PSP error | Error message displayed | ###### Navigation Flows Figure 98 – Flow – Add Funds ###### Wireframe(s) Figure 99 – Wireframe – Add Funds Modal ##### Auto-Replenishment Settings **Purpose**: The Auto-Replenishment feature allows users to automatically top up their account balance when it falls below a defined threshold. This ensures uninterrupted service usage and reduces the risk of insufficient balance during toll transactions. Users can view their current threshold and replenishment amount directly within the Auto Replenishment component and may update the replenishment amount via the “Edit Your Auto Replenishment Settings” link. **Inputs:** Auto-replenishment configuration Threshold amount Replenishment amount Default payment method **Outputs:** Display of replenishment configuration Display of threshold and top-up amounts **Controls:** View auto-replenishment configuration Edit Your Auto Replenishment Settings link ###### Business Rules Table 88 – Business Rules – Auto-Replenishment Settings | Rule Name | Description | | --- | --- | | Threshold Trigger | Replenishment must occur when account balance falls below the defined threshold. | | Replenishment Amount | The system must charge the configured replenishment amount. | | Payment Source | Replenishment transactions must use the default payment method. | | Edit Settings Access | Users must be able to open the auto-replenishment configuration flow from the Auto Replenishment component via the “Edit Your Auto Replenishment Settings” link. | | Configurable Replenishment Amount | Users must be able to update the replenishment amount using one of the predefined values or a custom value, subject to backend rules. | | Updated Setting Persistence | Once successfully updated, the new replenishment amount must be saved to backend systems and reflected in the Auto Replenishment component. | ###### Validation and System Responses Table 89 – Website Validations – Auto-Replenishment Settings | Event | Input | Output | | --- | --- | --- | | Balance falls below threshold | Balance < threshold | Replenishment triggered | | Payment processed | Payment request | Balance updated | | User selects Edit Your Auto Replenishment Settings | Edit link action | Edit Auto Replenishment Settings modal opened | | User submits valid update | Valid replenishment amount | Updated setting saved; Auto Replenishment component refreshed with new value | ###### Navigation Flow Figure 100 – Flow – Auto-Replenishment Settings ###### Wireframe(s) Figure 101 – Wireframe – Auto-Replenishment Settings Figure 102– Wireframe – Edit Auto Replenishment Settings Modal ##### Recent Account History Component **Purpose****:** The Recent Account History component provides a summary of the most recent transactions associated with the account, including toll charges and payments. **Inputs:** Transaction data from CBOS Toll information Payment records **Outputs:** Transaction list summary Access to transaction detail views **Controls:** View Account History link Transaction detail navigation arrow ###### Business Rules Table 90 – Business Rules – Recent Account History Component | Rule Name | Description | | --- | --- | | Data Source | Transaction data must be retrieved from CBOS. | | Transaction Types | Transactions may represent toll charges or payment records | | Detail Access | Users must be able to open transaction detail views. | ###### Validations and System Responses Table 91 – Website Validations – Recent Account History Component | Event | Input | Output | | --- | --- | --- | | Dashboard loads | Account retrieved | Recent transactions displayed | | User selects transaction | Transaction ID | Transaction detail view opened (toll or payment view) | ###### Wireframe(s) Figure 103 – Wireframe – Recent Account History Component Figure 104 – Wireframe – Toll View Figure 105 – Wireframe – Payment View ##### Quick Links Component **Purpose****:** The Quick Links component provides shortcuts to frequently used account management actions. **Inputs:** Quick link configuration Navigation routes **Outputs:** Direct navigation to account modules **Controls:** Quick link buttons including: Received Invoice Edit Details Edit Communication Preferences View Notifications View Statements Access Support Center Edit Payment Details ###### Business Rules Table 92 – Business Rules – Quick Links Component | Rule Name | Description | | --- | --- | | Navigation Shortcut | Quick links must route users directly to the corresponding account section. | ###### Validations and System Responses Table 93 – Website Validations – Quick Links Component | Event | Input | Output | | --- | --- | --- | | User clicks quick link | Link click | User navigated to module | ###### Wireframe(s) Figure 106 – Wireframe – Quick Links Component ##### Vehicle Summary Card **Purpose****:** The Vehicle Summary Card provides a high-level overview of vehicles and transponders associated with the user's account. **Inputs:** Vehicle count Transponder count **Outputs:** Display of vehicle and transponder summary Access to vehicle management section **Controls:** Manage Vehicles & Transponders button ###### Business Rules Table 94 – Business Rules – Vehicle Summary Card | Rule Name | Description | | --- | --- | | Vehicle Count | System must display the number of vehicles associated with the account. | | Transponder Count | System must display the number of active transponders | | Vehicle Management | Users must be able to navigate to the vehicle management module. | ###### Validations and System Responses Table 95 – Website Validations – Vehicle Summary Card | Event | Input | Output | | --- | --- | --- | | Dashboard loads | Vehicle data retrieved | Vehicle summary displayed | | User clicks manage vehicles | Button click | Redirect to vehicle page | ###### Wireframe(s) Figure 107 – Wireframe – Vehicle Summary Card #### Vehicle Page **Purpose**: The Vehicles page is an authenticated section of the Personal Account User Portal that allows users to view and manage vehicles and associated transponders linked to their account. The page provides a summary of vehicle and transponder counts together with a detailed tabular list of all vehicles registered under the authenticated user account. All vehicle and transponder information displayed on this page is dynamically retrieved from backend systems and is scoped exclusively to the authenticated user. **Inputs:** Authenticated user session Vehicle records linked to the account Transponder records linked to the account Vehicle status data Transponder status data Account type configuration Replacement transponder fee configuration Replacement transponder reasons list Account address for transponder dispatch System-configured vehicle makes list System-configured vehicle type list Country and state / province datasets **Outputs:** Display of vehicle and transponder summary counts Display of vehicle list with associated transponder and status information Creation of a new vehicle record Update of an existing vehicle record Removal of a vehicle, subject to validation rules Creation of a transponder order request Creation of a replacement transponder order request Linking of an existing transponder to a vehicle Update of displayed summary counts and vehicle list after successful actions **Controls:** The Vehicles page consists of the following functional components: Vehicles navigation tab Summary cards Add Vehicle primary action Request a Transponder primary action Vehicle list table Vehicle-level actions Pagination controls ##### Vehicle Page Overview ###### Business Rules Table 96 – Business Rules – Vehicle Page | Rule Name | Description | | --- | --- | | Authenticated Access Only | The Vehicles page is available only to authenticated users. | | Active Navigation State | The Vehicles tab must be displayed as the active tab while the user is on the Vehicles page. | | User-Scoped Data | Only vehicles and transponders associated with the authenticated account may be displayed. | | Dynamic Counts | Vehicle and transponder summary counts are read-only and update automatically based on backend data. | | Vehicle Limit by Account Type | The maximum number of vehicles that may be linked to an account is determined by account type and backend rules. | | Paginated Results | If the number of vehicles exceeds the records shown on a single page, pagination controls must be displayed. | | Contextual Actions | Available row-level actions depend on whether a transponder is already linked to the vehicle and on the vehicle / transponder status. | | Shared Vehicle Data Rules | Add Vehicle and Edit Vehicle follow the same core validation and data rules as vehicle capture during onboarding, unless explicitly amended for portal management. | | Request Transponder Vehicle Dependency | A transponder request must always be associated with a selected existing vehicle on the account. | | Replacement Flow Trigger | If the selected vehicle already has a linked transponder, the user must follow the replacement transponder workflow rather than the new transponder request workflow. | | New Transponder Order Handling | A successful request for a new transponder creates an order / case for dispatch to the account address. | | Replacement Transponder Handling | A successful replacement transponder request places the replacement order and charges the applicable amount using available account charging rules. | | Mobile Scan Restriction | Scan functionality for linking a transponder is available only on mobile app | | Vehicle Removal Rules | A vehicle may only be removed if backend validation rules allow the removal. | | Status Display | Vehicle and transponder status values are retrieved from backend systems and displayed read-only on the page. | | Minimum Vehicle Rule | At least one motorized vehicle needs to be added to the account | | Account Vehicle Dependency Rule | If all vehicles are removed from the account, the system must return a “no vehicles” state and trigger user notifications prompting the addition of a vehicle. Backend (CBOS) may enforce automated account closure if no vehicle is associated with the account for a defined period. | | Vehicle and Trailer Management Rules | License plates are uniquely associated per asset (vehicle or trailer). Trailers must be created as a separate asset type (Type = Trailer) and are not required to be linked to a vehicle. However, at least one motorized vehicle must exist on the account before a trailer can be added. | ###### Validations and System Responses Table 97 – Website Validations – Vehicle Page | Event | Input | Output | | --- | --- | --- | | User opens Vehicles page | Authenticated session | Vehicles tab displayed as active; summary cards and vehicle list loaded | | Backend returns vehicle records | Vehicle records | Vehicle list table populated | | Backend returns counts | Vehicle and transponder totals | Summary cards populated with read-only counts | | No vehicles exist | Empty vehicle | Empty state shown or table shown without rows; Add Vehicle remains available | | User has more vehicle records than current page size | Vehicle records exceed page limit | Pagination controls displayed | | User selects Add Vehicle | Add Vehicle action | Add Vehicle modal opened | | User selects Request a Transponder | Request a Transponder action | Request Transponder modal opened | | User selects Edit | Row action | Edit Vehicle modal opened with pre-populated values | | User selects Remove | Row action | Remove workflow initiated; backend validation required before deletion | | User selects Link Transponder | Row action on vehicle without linked transponder | Link Transponder modal opened | | Selected vehicle already has a transponder | Vehicle transponder present | Replacement transponder workflow is used instead of new transponder request | | User changes page using pagination | Pagination control | Selected page of vehicle results displayed | | User attempts to add a trailer without existing vehicle | Add Vehicle action with Type = Trailer and no motorized vehicles on account | Validation error displayed preventing trailer creation; user prompted to add a motorized vehicle first | | User adds trailer with valid account state | Add Vehicle action with Type = Trailer and at least one motorized vehicle present | Trailer successfully created as independent asset (no vehicle linkage required) | ###### Wireframe(s) Figure 108 – Wireframe – Vehicles Page Figure 109 – Wireframe – Add a Vehicle Modal Figure 110 – Wireframe – Request a Transponder Modal Figure 111 – Wireframe – Edit a Vehicle Modal (No Linked Transponder) Figure 112 – Wireframe – Edit a Vehicle Modal (Linked Transponder Present) Figure 113 – Wireframe – Request a Replacement Transponder Modal Figure 114 – Wireframe – Link Transponder to Vehicle Modal ##### Summary Cards **Purpose****:** The Summary Cards provide a high-level count of vehicles and transponders associated with the authenticated account. **Inputs:** Total number of vehicles linked to the account Total number of transponders linked to the account **Outputs:** Display of vehicle count Display of transponder count **Controls:** Title / label Read-only total value ###### Business Rules Table 98 – Business Rules – Summary Cards | Rule Name | Description | | --- | --- | | Read-Only Counts | Vehicle and transponder totals are informational only and cannot be edited by the user from this component. | | Automatic Update | Counts must reflect the current account data returned by backend systems. | | User Scope | Counts must only reflect items associated with the authenticated user account. | ###### Validation and System Responses Table 99 – Website Validations – Summary Cards | Event | Input | Output | | --- | --- | --- | | Vehicles page loads | Vehicle and transponder totals returned | Summary card values displayed | | Vehicle successfully added | Updated account data | Vehicle count refreshed | | Vehicle successfully removed | Updated account data | Vehicle count refreshed | | Transponder successfully requested or linked | Updated account data | Transponder count refreshed where applicable | ###### Wireframe(s) Figure 115 – Wireframes – Vehicles Summary Cards ##### Add Vehicle **Purpose****:** The Add Vehicle functionality allows the user to add a new vehicle to their account from within the authenticated portal. This functionality follows the same core structure and validation pattern as vehicle capture during account onboarding, with the difference that the vehicle is added to an already active account and immediately appears in the Vehicles list following successful submission. **Inputs:** Country State / Province Plate Number Make Model Vehicle Type Temporary License Plate toggle Temporary Access Vehicle toggle Any additional fields conditionally required by backend rules for temporary plate or temporary access vehicles **Outputs:** Creation of a new vehicle record linked to the account Updated vehicle list Updated summary card counts **Controls:** Title: Add a vehicle Close (x) control Country dropdown State / Province dropdown Plate Number field Make dropdown Model field Vehicle Type dropdown Temporary License Plate toggle with supporting text and info icon Temporary Access Vehicle toggle with supporting text and info icon Add Vehicle primary action **Field Notes:** **Country:** Mandatory dropdown field. Displays a list of available countries. Search-assisted selection is supported. **State / Province: **Dropdown field. Displays available options based on the selected country. Search-assisted selection is supported. This field may be optional or required depending on selected country and backend rules. **Plate Number:** Mandatory free-text field for the vehicle registration plate. **Make: **Dropdown field populated from a predefined system list of vehicle makes. **Model: **Free-text alphanumeric field. **Vehicle Type:** Dropdown field populated from a predefined list of vehicle types. Search-assisted selection is supported. **Temporary License Plate Toggle:** Indicates whether the vehicle has a temporary license plate. **Temporary Access Vehicle Toggle:** Indicates whether the vehicle is a temporary access vehicle, for example a rental. ###### Business Rules Table 100 – Business Rules – Add Vehicle | Rule Name | Description | | --- | --- | | Maximum Vehicle Limit | Users may only add vehicles up to the maximum allowed for the account type and backend account rules. | | Mandatory Country | Country is required before the vehicle can be added. | | Mandatory Plate Number | Plate Number is required before the vehicle can be added. | | State / Province Dependency | When selecting an option, the USA and Colorado state will appear at the first in their corresponding dropdowns. State / Province options are controlled by the selected country. Requirement rules are determined by configuration and backend validation. | | Make Source | Vehicle make options are populated from a predefined system dataset. This dataset will be manually created to ensure data consistency for internal reporting. | | Vehicle Type Source | Vehicle type options are populated from a predefined system dataset. | | Search-Assisted Selection | Country, state / province, make, and vehicle type controls support filtered lookup as the user types. | | Temporary Plate Indicator | Vehicles identified as temporary plates must be marked accordingly and displayed as such in the list view. | | Temporary Access Indicator | Vehicles identified as temporary access vehicles must be stored with the relevant classification. | | Successful Submission | On successful validation and backend save, the vehicle is added to the account and displayed in the Vehicles list. | | Failed Submission | If validation fails, the vehicle must not be added, and relevant error messaging must be displayed. | ###### Validations and System Responses Table 101 – Validation and System Responses – Add Vehicle | Event | Input | Output | | --- | --- | --- | | User opens Add Vehicle modal | Add Vehicle action | Modal opened | | User leaves mandatory fields empty | Missing country or plate number or other required fields | Inline validation errors shown; Add Vehicle not submitted | | User selects country | Country selected | Country stored; state / province options updated | | User enters plate number | Plate number input | Input captured and validated | | User selects make | Make selected | Make stored | | User enters model | Model input | Input captured | | User selects vehicle type | Vehicle type selected | Value stored | | User enables Temporary License Plate | Toggle on | Temporary plate state stored; additional rules applied if configured. Users will be asked for an expiry date for the Temporary Plate. | | User enables Temporary Access Vehicle | Toggle on | Temporary access state stored; additional rules applied if configured. Users will be asked to provide dates and times for when they had access or lost access to the vehicle. | | User submits valid vehicle data | Valid vehicle data | Vehicle created; modal closed; vehicle list refreshed | | Backend rejects vehicle creation | Duplicate / invalid / blocked by backend rules | Error shown; modal remains open; no new record added | | User closes modal | Close action | Modal dismissed without saving changes | ###### Navigation Flow Figure 116 – Flow – Add Vehicle ###### Wireframe(s) Figure 117 – Wireframe – Add a Vehicle Modal ##### Request a Transponder **Purpose**: The Request a Transponder functionality allows a user to request a new transponder for a vehicle already associated with their account. A transponder must always be assigned to a specific vehicle. This functionality includes two related paths: “New transponder request flow” for vehicles that do not currently have a linked transponder. “Replacement transponder flow” for vehicles that already have a linked transponder. **Inputs:** Selected vehicle Vehicle transponder status Account address Replacement reason, where applicable Replacement confirmation, where applicable Replacement cost configuration, where applicable **Outputs:** Creation of a transponder order / request Creation of a replacement transponder order / request Dispatch request to account address Account charge or balance deduction for replacement transponder, where applicable **Controls:** The transponder request process includes: Request a Transponder modal Request a Replacement Transponder modal Close (x) control Vehicle selection dropdown Replacement reason dropdown Confirmation checkbox Submit / order action button Informational text relating to address and charges ###### Business Rules Table 102 – Business Rules – Request a Transponder | Rule Name | Description | | --- | --- | | Vehicle Selection Required | A vehicle must be selected before a transponder request can be submitted | | Vehicle Scope | Only vehicles associated with the authenticated account may be shown in the vehicle selection list | | Existing Transponder Check | The selected vehicle must be checked for an existing linked transponder before determining the workflow. | | New Transponder Flow | If the selected vehicle does not have a linked transponder, the system initiates the new transponder request flow. | | Replacement Transponder Flow | If the selected vehicle already has a linked transponder, the system initiates the replacement transponder flow. | | Dispatch Address | Requested transponders are dispatched to the account address. | | New Transponder Order Outcome | Successful new transponder requests create an order / ticket for dispatch. | | Replacement Reason Required | A replacement request requires the user to select a valid replacement reason. | | Replacement Fee Display | The replacement charge amount must be displayed to the user and sourced from backend configuration. | | Confirmation Required | The user must explicitly confirm acknowledgement of the replacement charge before submission is enabled. | | Replacement Charge Handling | On successful replacement request, the configured charge is applied using supported account charging rules before or as part of order placement. The charge amount will be determined by CBOS. | ###### Validation and System Responses Table 103 – Website Validations – Request a Transponder | Event | Input | Output | | --- | --- | --- | | User opens Request a Transponder modal | Request a Transponder action | Modal opened | | User opens vehicle dropdown | Vehicle selection control | Only account-linked vehicles displayed | | User selects vehicle without linked transponder | Vehicle selected | New transponder request path remains available | | User selects vehicle with linked transponder | Vehicle selected | User redirected to replacement transponder workflow | | User submits without selecting vehicle | No vehicle selected | Validation error shown; submission blocked | | User submits valid new transponder request | Vehicle selected without existing transponder | Order / case raised for dispatch to account address; confirmation shown | | User opens replacement transponder modal | Replacement action initiated | Modal opened | | User submits replacement request without selecting reason | Missing reason | Validation error shown; order blocked | | User submits replacement request without confirmation | Checkbox not selected | Submission disabled or blocked | | User submits valid replacement request | Vehicle selected, reason selected, confirmation checked | Replacement order placed; applicable charge applied; confirmation shown | | Backend fails to create order | Backend / integration error | Error message shown; modal remains open | ###### Navigation Flow Figure 118 – Flow – Request a Transponder ###### Wireframe(s) Figure 119 – Wireframes – Request a Transponder Modal Figure 120 – Wireframes – Request a Transponder Modal Confirmation Figure 121 – Wireframes– Request a Replacement Transponder Modal ##### Vehicle List Table **Purpose****:** The Vehicle List Table provides a tabular view of all vehicles registered to the authenticated account, including associated transponder and status information. **Inputs:** Vehicle records (state, plate, make – model) Temporary plate indicator Vehicle type Linked transponder ID Vehicle status Available contextual actions **Outputs:** Display of paginated vehicle records Access to vehicle-specific actions **Controls:** The Vehicle List Table consists of the following columns: State Plate Number Make – Model Vehicle Type Transponder Vehicle Status Actions **Column Notes****:** **Plate Number:** includes a visual indicator where the vehicle is marked as a temporary plate. **Transponder:** Displays the linked transponder ID where present, or a placeholder when none is assigned. **Vehicle Status:** Displays the current backend-driven status value. **Actions:** Displays contextual row-level actions depending on the vehicle state. ###### Business Rules Table 104 – Business Rules – Vehicle List Table | Rule Name | Description | | --- | --- | | Backend-Driven Records | All rows are generated from backend vehicle data for the authenticated account. | | Temporary Plate Visual Tag | Temporary plate vehicles must be visually indicated in the Plate Number column. | | Transponder Placeholder | If no transponder is linked, a placeholder value must be shown. | | Status Read-Only | Vehicle status values are informational and cannot be edited directly in the table. | | Contextual Actions by State | Actions shown in each row depend on available vehicle and transponder actions for that record. | ###### Validation and System Responses Table 105 – Website Validations – Vehicle List Table | Event | Input | Output | | --- | --- | --- | | Vehicles page loads | Vehicle dataset | Table populated | | Vehicle has temporary plate flag | Temporary plate = true | Temporary plate indicator shown | | Vehicle has linked transponder | Transponder ID present | Transponder ID displayed | | Vehicle has no linked transponder | No transponder ID | Placeholder shown; Link Transponder action may be available | | Backend provides vehicle status | Status value | Status displayed in corresponding row | ###### Wireframe(s) Figure 122 – Wireframes – Vehicle List Table / Vehicles Page ##### Vehicle-Level Actions **Purpose****:** Vehicle-level actions allow the user to manage a specific vehicle directly from the Vehicles list. Available actions vary depending on whether a transponder is already linked and on backend validation rules. **Inputs:** Selected vehicle record Vehicle status Linked transponder state Replacement cost configuration Replacement reason list **Outputs:** Vehicle record update Vehicle removal Linked transponder association New transponder order Replacement transponder order **Controls:** The following contextual actions may be available per vehicle: Edit Remove Link Transponder ###### Business Rules Table 106 – Business Rules – Vehicle-Level Actions | Rule Name | Description | | --- | --- | | Edit Availability | Users may edit vehicle details for records returned in the vehicle list | | Remove Availability | Users may remove a vehicle subject to backend validation rules. | | Remove Availability | Users may remove a vehicle subject to backend validation rules. | | Link Transponder Availability | Link Transponder is available only when no transponder is currently associated with the vehicle. | | Replacement Transponder Availability | Request Replacement Transponder is available when a transponder is already associated with the vehicle. | | Pre-Populated Edit Data | Edit modal fields must be pre-populated with the currently stored vehicle information. | | Shared Edit Rules | Edit Vehicle uses the same core field and validation rules as Add Vehicle, with amended submission behavior | ###### Validation and System Responses Table 107 – Website Validations – Vehicle-Level Actions | Event | Input | Output | | --- | --- | --- | | User clicks Edit on vehicle without transponder | Edit action | Edit modal opened with pre-populated values and Request a Transponder option | | User clicks Edit on vehicle with transponder | Edit action | Edit modal opened with pre-populated values and Request Replacement Transponder option | | User clicks Remove | Remove action | Removal workflow initiated; backend validation performed | | User clicks Link Transponder | Link Transponder action | Link Transponder modal opened | ###### Navigation Flow Figure 123 – Flow – Vehicle Actions (Link Transponder) ###### Wireframe(s) Figure 124 – Wireframes – Edit a Vehicle Modal (No Linked Transponder) Figure 125 – Wireframes – Edit a Vehicle Modal (Linked Transponder Present) Figure 126 – Wireframes – Link Transponder Modal ##### Edit Vehicle **Purpose: **The Edit Vehicle functionality allows the user to modify details of an existing vehicle already linked to their account. **Inputs:** Existing vehicle data Updated Country Updated State / Province Updated Plate Number Updated Make Updated Model Updated Vehicle Type Updated Temporary License Plate flag Updated Temporary Access Vehicle flag **Outputs:** Updated vehicle record **Controls:** The Edit Vehicle modal follows the same structure and field set as Add Vehicle, with all values pre-populated from the selected vehicle record. Primary actions vary depending on whether the selected vehicle has a linked transponder. Where no transponder is linked: Edit Vehicle Request a Transponder Where a transponder is already linked Edit Vehicle Request Replacement Transponder ###### Business Rules Table 108 – Business Rules – Edit Vehicle | Rule Name | Description | | --- | --- | | Pre-Populated Values | All editable fields must load with the current stored vehicle values | | Shared Field Rules | The same field structure and core validations used in Add Vehicle apply to Edit Vehicle. | | Successful Edit | On successful validation and save, the selected vehicle record is updated and the list refreshed. | | Action Variation by Transponder State | Secondary transponder-related action depends on whether the vehicle already has a linked transponder. | ###### Validation and System Responses Table 109 – Website Validations – Edit Vehicle | Event | Input | Output | | --- | --- | --- | | User opens Edit Vehicle | Edit action | Modal displayed with pre-populated vehicle values | | User changes values and submits valid data | Valid amended dataset | Vehicle record updated; modal closed; list refreshed | | User submits invalid data | Invalid or incomplete values | Inline errors shown; save blocked | | User selects Request a Transponder from edit modal | Secondary action on vehicle without transponder | Request a Transponder modal opened | | User selects Request Replacement Transponder from edit modal | Secondary action on vehicle with transponder | Replacement transponder modal opened | ##### Request Replacement Transponder **Purpose****:** The Request Replacement Transponder modal allows a user to request a replacement for an existing transponder already associated with a vehicle on their account. The modal is transactional in nature and prevents interaction with the underlying page until the request is completed or dismissed. The modal informs the user of the applicable replacement cost and requires explicit confirmation before the request can be submitted. **Inputs:** Selected vehicle Replacement reason Replacement cost Confirmation checkbox **Outputs:** Replacement transponder order Charge applied according to account charging rules Confirmation of successful request **Controls:** The Request Replacement Transponder modal consists of: Title Close (x) control Vehicle Selection Dropdown Replacement Reason Dropdown Replacement Cost Information Confirmation checkbox and acknowledgement text Order Replacement Transponder button ###### Business Rules Table 110 – Business Rules – Request Replacement Transponder | Rule Name | Description | | --- | --- | | Eligible Vehicles Only | Only vehicles with an existing linked transponder may be selected. | | Replacement Reason Mandatory | A valid replacement reason must be selected before submission. | | Cost Disclosure | Replacement cost must be shown to the user before confirmation and submission | | Mandatory Confirmation | The acknowledgement checkbox must be selected before the request may be submitted. | | Charge Application | The replacement cost is charged based on supported account charging logic defined by backend systems. | | Dispatch Handling | The replacement transponder is dispatched to the account address | ###### Validation and System Responses Table 111 – Website Validations – Request Replacement Transponder | Event | Input | Output | | --- | --- | --- | | Modal loads | Eligible vehicle list and fee returned | Fields and cost information displayed | | User submits without vehicle | No vehicle selected | Validation error shown | | User submits without reason | No reason selected | Validation error shown | | User submits without acknowledgement | Checkbox not selected | Submission blocked | | User submits valid request | Valid vehicle, reason, acknowledgement | Replacement order created; charge applied; confirmation shown | | Backend rejects replacement request | Integration / validation error | Error shown; modal remains open | ###### Navigation Flow Figure 127 – Flow – Request a Replacement Transponder Modal ###### Wireframes Figure 128 – Wireframes – Request a Replacement Transponder Modal ##### Link Transponder **Purpose:** The Link Transponder functionality allows a user to associate an existing transponder with a specific vehicle on their account. **Inputs:** Selected vehicle Transponder Serial Number / ID Activation Code Scan result, where mobile app scanning is used **Outputs:** Linked transponder associated to vehicle **Controls:** The Link Transponder modal consists of: Title identifying the selected vehicle Scan code functionality for mobile applications Transponder Serial Number / ID field Activation Code field Back action Continue action ###### Business Rules Table 112 – Business Rules – Link Transponder | Rule Name | Description | | --- | --- | | Vehicle-Specific Link | A transponder link action must apply to the selected vehicle only. | | Mandatory Serial Number | Transponder Serial Number / ID is required for submission | | Mandatory Activation Code | Activation Code is required for submission | | Mobile Scan Support | Scan functionality is available only on mobile app | | Desktop Manual Entry | On unsupported devices, manual entry fields remain the only available method. | ###### Validation and System Responses Table 113 – Website Validations – Link Transponder | Event | Input | Output | | --- | --- | --- | | User opens Link Transponder | Link Transponder action | Modal opened for selected vehicle | | User taps Scan on supported mobile device | Scan action | Camera / scanning process started | | Scan successful | Read transponder value | Serial Number / ID field populated | | User submits without serial number | Missing serial number | Validation error shown | | User submits without activation code | Missing activation code | Validation error shown | | User submits valid details | Valid serial number and activation code | Transponder linked to vehicle; modal closed; list refreshed | | Backend rejects link request | Invalid or already used transponder/ activation code | Error shown; modal remains open | ###### Wireframe(s) Figure 129 – Wireframes – Link Transponder to Vehicle Modal ##### Pagination **Purpose****:** Pagination enables the user to navigate through multiple pages of vehicle results when the number of registered vehicles exceeds the number displayed on a single page. **Inputs: ** Current page number Total record count Page size Vehicle dataset **Outputs:** Current record range display Navigation between pages of vehicle records **Controls:** Record range text, for example “Showing X–Y of Z” Previous page control Next page control Page number controls ###### Business Rules Table 114 – Business Rules – Pagination | Rule Name | Description | | --- | --- | | Conditional Display | Pagination controls are displayed only when multiple pages of records exist | | Record Range Visibility | The current visible record range must be displayed to the user | | Page Navigation | Users must be able to navigate to previous, next, or specific result pages where available. | ###### Validation and System Responses Table 115 – Website Validations – Pagination | Event | Input | Output | | --- | --- | --- | | Multiple pages of results exist | Total records exceed page size | Pagination controls displayed | | User selects next page | Next action | Next set of vehicle records loaded | | User selects previous page | Previous action | Previous set of vehicle records loaded | | User selects page number | Page selection | Selected result page loaded | ###### Wireframe(s) Figure 130 – Wireframes – Vehicles Table Pagination #### Payments Page **Purpose:** The Payments page is an authenticated section of the Personal Account User Portal that enables users to view their prepaid balance, manage stored payment methods, review auto-replenishment settings, add funds, and review historical payment transactions. All payment-related data displayed on this page is dynamically retrieved from backend systems and is specific to the authenticated user account. **Inputs:** Authenticated user session Account balance data Account number Default payment method data Stored payment methods Auto-replenishment configuration Payment transaction history Payment status data Payment service provider capabilities **Outputs:** Display of prepaid balance and default payment configuration Display of stored payment methods Creation of new stored payment method Update of existing stored payment method Removal of stored payment method, subject to validation rules Update of default payment method designation Display of payment history records Updated payment method list and payment history following successful actions **Controls:** The Payments page consists of the following functional components: Payments navigation tab Account Balance Card Payment Methods Management Section Payment History Table Pagination controls for payment history, where applicable ##### Payments Page Overview ###### Business Rules Table 116 – Business Rules – Payments Page | Rule Name | Description | | --- | --- | | Authenticated Access Only | The Payments page is available only to authenticated users | | Active Navigation State | The Payments tab must be displayed as the active tab while the user is on the Payments page. | | User-Scoped Data | Only payment data associated with the authenticated account may be displayed. | | Balance Card Reuse | The Account Balance Card on the Payments page follows the same behavior defined under the Overview page. | | The Account Balance Card on the Payments page follows the same behavior defined under the Overview page. | Users may view, add, edit, remove, and set default stored payment methods, subject to system rules. | | Minimum One Active Payment Method | At least one active payment method must remain on the account. | | Default Payment Method Required | A default payment method must always be designated on the account. | | Default Payment Method Dependency | The default payment method is used for account transactions where required, including auto-replenishment where configured. | | Dynamic Payment History | Payment history records are dynamically retrieved from backend systems and displayed read-only. | ###### Validation and System Responses Table 117 – Website Validations – Payments Page | Event | Input | Output | | --- | --- | --- | | User opens Payments page | Authenticated session | Payments tab displayed as active; page data loaded | | Backend returns account payment data | Payment dataset | Balance card, payment methods, and payment history displayed | | User selects Add Payment Method | Add Payment Method action | Add Payment Method modal opened | | User selects Remove payment method | Remove action | Remove workflow initiated; backend validation performed | | User selects Make Default | Make Default action | Selected payment method becomes default; previous default removed | | Payment history exceeds single page limit | Payment history exceeds page limit | Pagination controls displayed | | Backend prevents payment method removal | Validation rule triggered | Error shown; payment method remains unchanged | ###### Wireframe(s) Figure 131 – Wireframes – Payments Page Figure 132 – Wireframes – Add New Payment Method Modal Figure 133 – Wireframes – Edit Auto Replenishment Settings Modal ##### Account Balance Card **Purpose**: The Account Balance Card on the Payments page provides a summary of the user’s current prepaid balance, account number, default payment method, and auto-replenishment settings. This functionality follows the same structure and behavior already defined under the Overview page and is repeated here to support payment-related actions from within the Payments section. ##### Payment Methods Management Section **Purpose****:** The Payment Methods Management Section enables users to view, add, remove, and designate default payment methods associated with their account. **Inputs:** Stored payment methods linked to the account Payment method type Masked payment method identifier Expiration date Default payment method flag **Outputs:** Display of stored payment methods Creation of a new stored payment method Update of an existing stored payment method Removal of an existing stored payment method Update of default payment method designation **Controls:** The Payment Methods Management Section consists of: Title: Payment Methods Add Payment Method button Stored payment method cards / list items. Row-level actions: - Remove - Make Default Each stored payment method entry displays: Masked card number Expiration date, where applicable Badge – indicating default payment method ###### Business Rules Table 118 – Business Rules – Payment Methods Management | Rule Name | Description | | --- | --- | | Add Payment Method Availability | Users may add a new payment method from the Payments page | | Stored Method Display | Each stored payment method must display masked identifying details and relevant status / expiry information | | Default Badge Display | The default payment method must be visually indicated | | Single Default Method | Only one payment method may be designated as default at any time. | | Minimum One Active Method | At least one active payment method must remain on the account. | | Default Reassignment | If a default payment method is changed, the selected method becomes the new default and the previous default loses default status | | Secure Payment Data Handling | Sensitive payment information must be handled through secure PSP-compliant flows and not stored or displayed in full in the portal UI. | ###### Validation and System Responses Table 119 – Website Validations – Payment Methods Management | Event | Input | Output | | --- | --- | --- | | User opens Payments page | Stored payment methods dataset | Payment methods list displayed | | User clicks Add Payment Method | Add action | Add Payment Method modal opened | | User clicks Remove | Remove action | Removal attempted; backend validation performed | | User removes non-default method | Valid removal request | Confirmation message initiated, if confirmed by user method is removed; list refreshed | | User attempts to remove last active payment method | Removal would leave zero active methods | Removal blocked; validation error shown | | User attempts to remove default payment method without permitted reassignment | Default method removal violates default rule | Removal blocked or reassignment required, user is required to add additional payment method before removal | | User clicks Make Default | Valid method selected | Selected method becomes default; list refreshed | ###### Navigation Flow Figure 134 – Flow – Default Payment Method Figure 135 – Flow – Remove Payment Method ###### Wireframe(s) Figure 136 – Wireframes – Payment Methods Section Figure 137 – Wireframes – Add New Payment Method Modal ##### Add Payment Method **Purpose****:** The Add Payment Method functionality allows a user to securely add a new payment method to their account. This is presented as a modal. **Inputs:** Name on card Card number CVC Card expiry (MM/YY) Alternative payment type selection, where supported **Outputs:** New stored payment method linked to the account Updated payment methods list **Controls:** The Add Payment Method modal consists of: Title Close (x) control Add New Card section Name on card field Card Number field CVC field Card Expiry field Add Card Details button Alternative payment method options, where supported: - Add Bank Details - Add Google Pay Account - Add PayPal Account ###### Business Rules Table 120 – Business Rules – Add Payment Method | Rule Name | Description | | --- | --- | | Mandatory Card Fields | Name on card, card number, CVC, and card expiry are required for card entry. | | Add Button Enablement | Add Card Details remains disabled until all mandatory card fields are completed and pass validation. | | Secure Submission | Card submission must be handled through secure PSP-compliant processing. | | Alternative Methods Availability | Alternative payment method options are displayed | | Modal Dismissal | Closing the modal exits the flow without saving incomplete data. | ###### Validation and System Responses Table 121 – Website Validations – Add Payment Method | Event | Input | Output | | --- | --- | --- | | User opens Add Payment Method modal | Add Payment Method action | Modal opened | | User leaves mandatory fields incomplete | Missing required values | Add Card Details button disabled | | User enters invalid card details | Invalid card number / CVC / expiry | Validation error shown; submission blocked | | User completes valid card details | Complete | Add Card Details button enabled | | User submits valid payment method | Valid payment method data | Payment method stored; modal closed; list refreshed | | Backend / PSP rejects submission | Processing / validation error | Error shown; modal remains open | | User closes modal | Close action | Modal dismissed without saving | ###### Navigation Flow Figure 138 – Flow – Add Payment Method ###### Wireframe(s) Figure 139 – Wireframes – Add New Payment Method Modal ##### Payment History **Purpose****:** The Payment History section displays historical payment-related transactions associated with the authenticated account, including one-time payments, auto-replenishment transactions, and other payment-related account activity. **Inputs:** Payment transaction history records Payment method identifier Amount Transaction date **Outputs:** Display of historical payment transaction records Paginated history list where applicable **Controls:** The Payment History table consists of the following columns: ID Method Amount Date ###### Business Rules Table 122 – Business Rules – Payment History | Rule Name | Description | | --- | --- | | Read-Only History | Payment history is informational and cannot be edited from this section. | | Backend-Driven Records | Payment history records are retrieved from backend systems and displayed read-only | | Pagination | Pagination controls must be displayed where the number of payment history records exceeds the page limit | ###### Validation and System Responses Table 123 – Website Validations – Payment History | Event | Input | Output | | --- | --- | --- | | Payments page loads | Payment history dataset | Payment history table displayed | | No payment history exists | Empty dataset | Empty state shown | | Payment history exceeds single page limit | Dataset exceeds page size | Pagination controls displayed | | User changes page | Pagination action | Selected page of payment history records displayed | ###### Wireframe(s) Figure 140 – Wireframes – Payment History Table #### Documents Page **Purpose****:** The Documents page is an authenticated section of the Personal Account User Portal that allows users to search, view, filter, and pay outstanding invoices, as well as access historical account statements. All invoice and statement data displayed on this page is dynamically retrieved from backend systems and is specific to the authenticated user account. **Inputs:** Authenticated user session Invoice records linked to the account Invoice status data Invoice PDF / document assets Vehicle / plate data linked to invoices Statement records Statement PDFs Date range filter values Invoice number search input Invoice reference data entered manually by the user Default payment method and available payment methods for invoice payment **Outputs:** Display of invoice list Display of filtered invoice results Retrieval and association of an invoice to the account where valid Display of invoice detail records Payment of selected or all displayed invoices Display of statement list Access to statement PDF view and download Paginated invoice and statement lists where applicable **Controls:** The Documents page consists of the following functional components: Documents navigation tab Invoices Section Invoice Table Invoice Pagination Statements Section Statements Table Statements Pagination ##### Documents Page Overview ###### Business Rules Table 124 – Business Rules – Documents Page | Rule Name | Description | | --- | --- | | Authenticated Access Only | The Documents page is available only to authenticated users. | | Active Navigation State | The Documents tab must be displayed as the active tab while the user is on the Documents page | | User-Scoped Data | Only invoice and statement records associated with the authenticated account may be displayed | | Conditional Invoices Section | If no invoices exist for the account, the invoices section is not displayed. | | Dynamic Filtering | Invoice and statement results update based on entered filter criteria. | | Invoice Retrieval Validation | An invoice can only be manually associated to the account where the invoice exists in backend systems, and the provided vehicle plate matches the invoice record. | | Immediate Status Refresh | Successful invoice payments must update invoice status immediately or as soon as backend confirmation is returned. | | Document Access | Statements and invoice documents are retrieved from backend systems and presented in table format. Users are also able to download pdfs to their device. | ###### Validation and System Responses Table 125 – Website Validations – Documents Page | Event | Input | Output | | --- | --- | --- | | User opens Documents page | Authenticated session | Documents tab active; invoice and statement data loaded | | Account has invoices | Invoice dataset present | Invoices section displayed | | Account has no invoices | No invoice dataset | Invoices section hidden | | User applies filters | Search / date range values | Results refreshed | | User selects Received an Invoice | Add Invoice action | Add Invoice modal opened | | User submits valid invoice reference details | Valid invoice number and vehicle plate match | Invoice Details modal opened | | User submits invalid invoice reference details | Invalid or unmatched values | Error shown; Add Invoice modal remains open | | User pays invoices successfully | Valid payment submission | Invoice statuses refreshed | | Statement results exceed single page limit | Dataset exceeds page size, limit of 10 items per page | Pagination controls displayed | ###### Navigation Flows Figure 141 – Flow – View & Download Functions The user will have the option to view online and download a PDF version of their statements and invoices to the device they are accessing the online registered account. Figure 142 – Flow – Received an Invoice This flow describes how a user will be able to add an Invoice to their account in the event they have received an invoice not connected to their online Registered Account – For example, if the user has forgotten to add a vehicle. ###### Wireframe(s) Figure 143 – Wireframes – Documents Page Figure 144 – Wireframes – Received an Invoice Modal Figure 145 – Wireframes – Invoice Details Modal ##### Invoices Section **Purpose: **The Invoices Section provides a searchable and filterable list of all invoices associated with the authenticated account and allows users to manually retrieve and associate an invoice to their personal account by entering invoice reference details. This section is displayed only when invoice data exists for the account. **Inputs:** Invoice ID search value From date To date Invoice records linked to the account **Outputs:** Filtered invoice list Access to Add Invoice workflow **Controls:** The Invoices Section consists of: Title Invoice ID search field Date range filter - From date (DD-MM-YYYY) - To date (DD-MM-YYYY) Filter button Received an Invoice button ###### Business Rules Table 126 – Business Rules – Invoices Section | Rule Name | Description | | --- | --- | | Conditional Display | The Invoices Section is shown only where invoice records exist for the account. | | Invoice Search | Users may search invoices by invoice number. | | Date Range Filter | Users may filter invoice records using a from and to date range | | Dynamic Filtering | Results refresh based on applied invoice filters | | Add Invoice Entry Point | The Received an Invoice action opens the Add Invoice modal. | ###### Validation and System Responses Table 127 – Website Validations – Invoices Section | Event | Input | Output | | --- | --- | --- | | Invoices exist for account | Invoice dataset | Invoices section displayed | | No invoices exist for account | Empty invoice dataset | Invoices section hidden | | User enters invoice search value | Search input | Results filtered after filter action/ dynamic refresh | | User enters date range | From / to dates | Results filtered after filter action / dynamic refresh | | User clicks Received an Invoice | Button click | Add Invoice modal opened | ###### Wireframe(s) Figure 146 – Wireframes– Invoices Section ##### Add Invoice **Purpose:** The Add Invoice modal allows the user to manually retrieve and associate an invoice with their personal account by entering invoice reference details. **Inputs:** Invoice number License Plate State License Plate Number ZIP **Outputs:** Successful retrieval of matching invoice record Opening of Invoice Details modal where invoice reference is validated successfully **Controls:** The Add Invoice modal consists of: Title Close (x) control Invoice number field License Plate State field License Plate Number field ZIP field Add Invoice button ###### Business Rules Table 128 – Business Rules – Add Invoice | Rule Name | Description | | --- | --- | | Mandatory Invoice Number | Invoice Number is required before submission | | Mandatory Vehicle Plate | Vehicle Plate is required before submission | | Add Button Enablement | Add Invoice remains disabled until all mandatory fields are completed. | | Mandatory License Plate state and ZIP | Mandatory License Plate state and ZIP are required before submission | | Invoice Existence Validation | The invoice must exist in backend systems to be retrieved | | Vehicle Match Validation | The entered vehicle plate must match the invoice record | | Successful Validation Outcome | If invoice validation succeeds, the user is taken to the Invoice Details modal. | | Failed Validation Outcome | If validation fails, the user remains on the modal and receives an error message. | ###### Validation and System Responses Table 129 – Website Validations – Add Invoice | Event | Input | Output | | --- | --- | --- | | User opens Add Invoice modal | Received an Invoice action | Modal opened | | User leaves mandatory fields empty | Missing invoice number or vehicle plate | Add Invoice button disabled | | User submits invalid invoice details | Invalid invoice number / vehicle plate mismatch / no backend match | Error shown; modal remains open | | User submits valid invoice details | Matching invoice number and vehicle plate | Invoice Details modal opened | | User closes modal | Close action | Modal dismissed without saving | ###### Wireframe(s) Figure 147 – Wireframes – Received an Invoice Modal ##### Invoice Table **Purpose****:** The Invoice Table displays all invoices linked to the authenticated account and provides access to invoice-related actions. **Inputs:** Invoice dataset Vehicle / plate data Invoice date Amount due Due date Invoice status Available invoice actions **Outputs:** Display of invoice records Access to invoice actions: - View Details - Make a Payment - Dispute **Controls:** The Invoice Table consists of the following columns: Selection checkbox Invoice ID Vehicle / Plate Date Issued Amount Due Status – retrieved from backend Due Date Actions menu ###### Business Rules Table 130 – Business Rules – Invoice Table | Rule Name | Description | | --- | --- | | Backend-Driven Records | Invoice rows are generated from backend invoice data associated with the account. | | Read-Only Record Data | Invoice metadata shown in the table is informational and cannot be directly edited. | | Action Availability | Available actions per invoice depend on the invoice state and backend rules. For example an Unpaid Invoice will have the option to Pay or Dispute. | | Dispute Entry Action | The Dispute action initiates the relevant dispute workflow where available. | | Make a Payment Action | Make a payment action initiates the relevant payment details page | | View Details Action | View details action initiates invoice details screen | ###### Validation and System Responses Table 131 – Website Validations – Invoice Table | Event | Input | Output | | --- | --- | --- | | Documents Page Loads | Invoice dataset | Invoice table populated | | User Selects View | View action | Invoice PDF opened | | User Selects Download | Download action | Invoice file downloaded to user device and / or opened in new tab | | User Selects Dispute | Dispute action | Dispute workflow initiated | ###### Wireframe(s) Figure 148 – Wireframes – Invoice Table Figure 149 – Wireframes – Invoice Table Actions ##### Statements Section **Purpose: **The Statements Section provides access to historical account statements, including toll and payment statements generated as PDF documents and retrieved from backend systems. **Inputs:** Statement records Statement date range filter values Statement PDF assets **Outputs:** Filtered statement list Access to statement view and download actions **Controls:** The Statements Section consists of: Date range filter - From date (DD-MM-YYYY) - To date (DD-MM-YYYY) Filter button ###### Business Rules Table 132 – Business Rules – Statements Section | Rule Name | Description | | --- | --- | | Date Range Filter | Users may filter statements by from and to dates | | Dynamic Filtering | Statement results refresh based on applied filter criteria | | Backend-Sourced PDFs | Statement documents are retrieved from backend systems in PDF format. | ###### Validation and System Responses Table 133 – Website Validations – Statements Section | Event | Input | Output | | --- | --- | --- | | User enters statement date range | From / to dates | Statement results filtered after filter action/ dynamic refresh | | User clears filters or changes values | Updated filter values | Statement results refreshed | ###### Wireframe(s) Figure 150 – Wireframes – Statements Section ##### Statements Table **Purpose****:** The Statements Table displays generated account statements and provides access to view or download each statement document. **Inputs:** Statement date Statement number Available statement document asset **Outputs:** Display of statement records Access to view statement PDF Access to download statement PDF **Controls:** The Statements Table consists of the following columns: Date Statement Number Actions Available actions: View Statement Download Statement ###### Business Rules Table 134 – Business Rules – Statements Table | Rule Name | Description | | --- | --- | | Read-Only Records | Statement records are informational and cannot be edited from the portal | | View Statement Action | View Statement opens the statement PDF for the user | | Download Statement Action | Download Statement downloads the statement to the user device and may open it in a new browser tab depending on system behavior. There is no limitation to the invoices that can be downloaded. | | Pagination Support | Pagination is displayed where statement result volume exceeds the configured page limit. | ###### Validation and System Responses Table 135 – Website Validations – Statements Table | Event | Input | Output | | --- | --- | --- | | Statements loaded | Statement dataset | Statements table populated | | User selects View Statement | View action | Statement PDF opened | | User selects Download Statement | Download action | Statement downloaded to device and / or opened in new tab | | Statement results exceed single page limit | Dataset exceeds page size | Pagination controls displayed | ###### Wireframe(s) Figure 151 – Wireframes – Statements Table #### Account History Page **Purpose: **The Account History page is an authenticated section of the Personal Account User Portal that provides users with a complete transactional record of toll activity, payments, and account balance changes. The page enables users to search, filter, export, review details, pay outstanding tolls, and access dispute entry points where applicable. All transaction data displayed on this page is dynamically retrieved from backend systems and is specific to the authenticated user account. **Inputs****:** Authenticated user session Transaction history records Unpaid toll transaction records Vehicle records linked to the account Toll point / road reference data Transaction type values Transaction status values Account balance values Export selection state Search input Filter values Default payment method and available payment methods Dispute flow configuration **Outputs****:** Display of unpaid toll transactions Display of full account transaction history Filtered and searched result sets Exported selected transactions in supported file formats Transaction detail modal views Payment initiation for unpaid tolls Dispute flow entry point with prefilled contextual data Updated unpaid toll and account history data after successful payment or resolution **Controls****:** The Account History page consists of the following functional components: Account History navigation tab Search field Advanced Filter control Export Selected controls Unpaid Tolls section Account History section Transaction action menus Pagination controls ##### Account History Page Overview ###### Business Rules Table 136 – Business Rules – Account History Page | Rule Name | Description | | --- | --- | | Authenticated Access Only | The Account History page is available only to authenticated users. | | Active Navigation State | The Account History tab must be displayed as the active tab while the user is on the Account History page. | | User-Scoped Data | Only transaction data associated with the authenticated account may be displayed. | | Dynamic Data Source | Transaction and unpaid toll data are dynamically retrieved from backend systems. | | Shared Filter Scope | Search and applied filters affect both the Unpaid Tolls and Account History sections where relevant. | | Export Selected Only | Only transactions selected by checkbox may be exported. | | Unpaid Toll Section Conditional Display | The Unpaid Tolls section is displayed only when there are unpaid toll records associated with the account. | | Unpaid Toll Removal Rule | Once an unpaid toll is successfully paid or otherwise resolved, it is removed from the Unpaid Tolls section and reflected in Account History. | | Transaction Detail Modal by Type | View Details must display a detail modal appropriate to the transaction type, for example toll transaction or payment transaction. | | Dispute Entry Context | The Raise a Dispute action must direct the user into the dispute flow with available contextual information prefilled, such as Toll ID and support inquiry type. | | Pagination Display | Pagination controls are displayed only when the number of records exceeds the page limit for the relevant section. | | Search and Filter Independence | Empty search or filter fields are ignored and do not block result retrieval. | ###### Validation and System Responses Table 137 – Website Validations – Account History Page | Event | Input | Output | | --- | --- | --- | | User opens Account History page | Authenticated session | Account History tab displayed as active; page data loaded | | Backend returns unpaid tolls | Unpaid toll dataset present | Unpaid Tolls section displayed | | Backend returns no unpaid tolls | Empty unpaid toll dataset | Unpaid Tolls section hidden | | Backend returns transaction records | Transaction dataset | Account History table displayed | | User enters search value | Search input | Matching transaction results returned | | User applies filters | Selected filter values | Result sets updated in relevant sections | | User selects records for export | Checkbox selection | Selected records marked for export | | User clicks CSV or PDF export | Export action | Only selected records exported to device | | User selects View Details | Action menu | Transaction detail modal opened | | User selects Make a Payment | Action menu | Make a Payment modal / workflow opened | | User selects Raise a Dispute | Action menu | User directed to dispute flow with contextual values prefilled | | Successful toll payment occurs | Paid / resolved unpaid toll | Item removed from Unpaid Tolls and reflected in Account History | ###### Wireframe(s) Figure 152 – Wireframes – Account History Page Figure 153 – Wireframes – Filters Modal Figure 154 – Wireframes – Toll Details Modal Figure 155 – Wireframes – Payment Details Modal Figure 156 – Wireframes – Make a Payment Modal ##### Search and Advanced Filter Controls **Purpose: **The Search and Advanced Filter controls allow users to locate specific transactions and refine the transaction datasets displayed on the page. These controls apply to both the Unpaid Tolls and Account History sections, where relevant. **Inputs:** Search term Selected vehicle Selected toll point / road Selected transaction type Selected transaction status From date To date **Outputs****:** Filtered transaction result sets Refined unpaid toll results Refined account history results **Controls****:** The Search and Advanced Filter controls consist of: Search field Advanced Filter control Filters modal / panel Apply Filters button **Search Field:** Supports searching by: Toll location Vehicle plate Transaction ID **Advanced Filter Modal / Panel:** Consists of: Title Close (x) control Vehicle dropdown Toll Point / Road dropdown Transaction Type dropdown Transaction Status dropdown Date Range selector - From date (DD-MM-YYYY) - To date (DD-MM-YYYY) Apply Filters button ###### Business Rules Table 138 – Business Rules – Search and Advanced Filter Controls | Rule Name | Description | | --- | --- | | Search Scope | Search must support matching by toll location, vehicle plate, or transaction ID. | | Vehicle Filter Scope | Vehicle dropdown must list only vehicles associated with the authenticated account. | | Toll Point / Road Values | Toll Point / Road filter values are sourced from backend systems. | | Transaction Type Values | Transaction Type filter includes supported transaction type values, such as Toll, Auto-replenishment payment, and One-time payment. | | Transaction Status Values | Transaction Status filter includes supported status values, such as Paid, Unpaid, Success, and Invoiced. | | Combined Filters | Multiple filters may be applied at the same time. | | Empty Fields Ignored | Empty or unselected filter fields must be ignored during filtering. | | Date Range Filtering | From and To dates narrow result sets to the selected date range where valid. | | Apply Filters Action | Selecting Apply Filters updates the result sets dynamically. | ###### Validation and System Responses Table 139 – Website Validations – Search and Advanced Filter Controls | Event | Input | Output | | --- | --- | --- | | User enters search term | Search text | Matching records returned in relevant sections | | User opens Advanced Filter | Filter action | Filters modal / panel opened | | User selects one or more filters | Filter values | Selected values stored in filter state | | User leaves some filters empty | Partial filter input | Empty fields ignored | | User clicks Apply Filters | Valid filter input | Results refreshed in Unpaid Tolls and Account History | | User closes filter modal | Close action | Modal dismissed without applying further changes | | User enters invalid date range | Invalid or incomplete date combination | Validation error shown or filter action blocked, depending on implementation | ###### Wireframe(s) Figure 157 – Wireframes – Search and Advanced Filter Controls Figure 158 – Wireframes – Filters Modal ##### Export Selected Controls **Purpose: **The Export Selected controls allow users to export selected transaction records from the page in supported file formats. **Inputs****:** Selected transaction records Export format selection **Outputs****:** Exported file downloaded to the user’s device **Controls****:** The Export Selected controls consist of: Export Selected label CSV export action PDF export action ###### Business Rules Table 140 – Business Rules – Export Selected Controls | Rule Name | Description | | --- | --- | | Export by Selection Only | Only records selected by checkbox may be exported. | | Supported Formats | Export formats include CSV and PDF. | | Device Download | Exported files must be downloaded to the user’s device. | | Cross-Section Selection Handling | Export logic must respect the records selected in the currently available transaction views. | ###### Validation and System Responses Table 141 – Website Validations – Export Selected Controls | Event | Input | Output | | --- | --- | --- | | User selects records | Checkbox selection | Records marked as selected | | User clicks CSV export | Selected records + CSV action | CSV file generated and downloaded | | User clicks PDF export | Selected records + PDF action | PDF file generated and downloaded | | User clicks export with no records selected | No selection | Export blocked or validation message shown | ###### Navigation Flow Figure 159 – Flow – Export Selected Controls ###### Wireframe(s) Figure 160 – Wireframes – Export Selected Controls ##### Unpaid Tolls Section **Purpose: **The Unpaid Tolls section displays all outstanding toll transactions that have not yet been paid or otherwise settled. It provides focused visibility of unpaid toll liabilities and allows the user to review details, make payment, raise disputes, or export selected records. If there are no unpaid tolls associated with the user’s account, this section is not displayed. **Inputs:** Unpaid toll transaction dataset Vehicle / plate data Toll point / road data Transaction amount Transaction status Transaction selection state **Outputs:** Display of unpaid toll transactions Access to payment and dispute workflows Export selection support Removal of records after successful resolution **Controls:** The Unpaid Tolls section consists of the following columns: Selection checkbox Transaction ID State – Plate Toll Point / Road Date and Time Amount Transaction Type Status Actions Menu Supported status values include: Unpaid Unpaid – Invoiced Available actions include: View Details Make a Payment Raise a Dispute ###### Business Rules Table 142 – Business Rules – Unpaid Tolls Section | Rule Name | Description | | --- | --- | | Conditional Display | The section is displayed only when one or more unpaid toll records exist. | | Unpaid Status Scope | Only unpaid or unsettled toll transactions appear in this section. | | Status Display | Status values such as Unpaid and Unpaid – Invoiced are displayed as provided by backend systems. | | Resolution Removal | Once a toll is paid or resolved, it must be removed from the Unpaid Tolls section. | | Account History Inclusion | Once paid or resolved, the transaction must remain visible in Account History according to backend transaction history rules. | | Actions Availability | Users may view details, make payment, or raise a dispute for eligible unpaid toll records. | | Pagination Support | Pagination is displayed when unpaid toll volume exceeds the page limit. | ###### Validation and System Responses Table 143 – Website Validations – Unpaid Tolls Section | Event | Input | Output | | --- | --- | --- | | Unpaid tolls exist | Unpaid toll dataset | Section displayed | | No unpaid tolls exist | Empty unpaid toll dataset | Section hidden | | User selects unpaid toll row | Checkbox selection | Row marked for export / selection | | User opens action menu | Row action menu | Available actions displayed | | User selects View Details | View action | Toll detail modal opened | | User selects Make a Payment | Payment action | Make a Payment modal / workflow opened | | User selects Raise a Dispute | Dispute action | User directed to dispute flow with contextual data | | User successfully pays toll | Successful payment | Toll removed from Unpaid Tolls; Account History refreshed | | Unpaid toll count exceeds page limit | Dataset exceeds page size | Pagination controls displayed | ###### Wireframe(s) Figure 161 – Wireframes – Unpaid Tolls Section ##### Transaction Details **Purpose: **The Transaction Details modal provides detailed information for a selected transaction. The content of the modal depends on the transaction type and displays either toll transaction details or payment transaction details. **Inputs:** Selected transaction record Transaction type Toll details, where applicable Payment details, where applicable **Outputs:** Detailed transaction view Access to Make a Payment for eligible tolls Access to Raise a Dispute for eligible tolls **Controls:** The Transaction Details modal consists of: Title Close (x) control Transaction details content Primary action buttons, where applicable **Toll Transaction Details:** Displays: Vehicle (plate number) Amount charged Toll road name Toll entry point Toll exit point Entry date and time Exit date and time Operator Primary actions: Make a Payment Raise a Dispute **Payment Transaction Details** Displays: Payment Method Amount Date Status ###### Business Rules Table 144 – Business Rules – Transaction Details | Rule Name | Description | | --- | --- | | Type-Specific Detail View | The detail modal content must vary depending on whether the selected transaction is a toll or payment transaction. | | Toll Detail Actions | Toll transaction details may provide Make a Payment and Raise a Dispute actions where applicable. | | Payment Detail Read-Only | Payment transaction detail views are informational only unless further actions are explicitly configured. | | Modal Dismissal | Closing the modal exits the detail view without changing transaction data. | ###### Validation and System Responses Table 145 – Website Validations – Transaction Details | Event | Input | Output | | --- | --- | --- | | User selects toll transaction details | Toll transaction | Toll Details modal opened | | User selects payment transaction details | Payment transaction | Payment Details modal opened | | User closes details modal | Close action | Modal dismissed | | User selects Make a Payment from toll detail | Payment action | Payment workflow opened | | User selects Raise a Dispute from toll detail | Dispute action | User directed to dispute flow with contextual data | ###### Wireframe(s) Figure 162 – Wireframes – Toll Details Modal Figure 163 – Wireframes – Payment Details Modal ##### Make a Payment **Purpose: **The Make a Payment functionality allows the user to pay an outstanding toll transaction from within the Account History flow. The modal presents the amount due, the current default payment method, and supported alternative payment options. For more detailed functional behavior, this flow should align with the corresponding account payment workflow defined elsewhere in the document set. **Inputs:** Outstanding transaction amount Default payment method Card verification code (CVC) – send through providers’ iFrame for validation Alternative payment method selection **Outputs:** Payment submission for selected toll transaction Updated transaction status following successful payment Removal of paid toll from the Unpaid Tolls section **Controls:** The Make a Payment modal consists of: Title Close (x) control Amount due Default payment method summary CVC input field Pay button Alternative payment method options: - Pay with a new card - Pay with new bank details - Pay with Google Pay - Pay with Apple Pay ###### Business Rules Table 146 – Business Rules – Make a Payment | Rule Name | Description | | --- | --- | | Transaction-Specific Payment | The payment action applies to the selected outstanding transaction only. | | Amount Display | The amount shown in the modal must match the amount due for the selected transaction. | | Default Payment Method Display | The default payment method must be displayed where available. | | CVC Requirement for Stored Card | The user must enter the card verification code when paying with a stored card. | | Alternative Payment Options | Alternative payment methods: bank details, Google Pay and Apple Pay | | Successful Payment Outcome | On successful payment, the transaction status is updated, and the unpaid toll is removed from the Unpaid Tolls section. | | Failed Payment Outcome | On failed payment, the transaction remains unpaid and an error message is displayed. | ###### Validation and System Responses Table 147 – Website Validations – Make a Payment | Event | Input | Output | | --- | --- | --- | | User opens Make a Payment modal | Payment action | Modal opened with amount due and default payment method | | User leaves CVC empty | Missing required field | Pay button disabled or submission blocked | | User enters valid CVC | Valid input | Pay action enabled | | User selects alternative payment option | Alternative payment route | User directed to relevant PSP-supported flow | | User submits successful payment | Valid payment submission | Payment succeeds; status refreshed; item removed from Unpaid Tolls | | User submits failed payment | Payment failure | Error shown; item remains unpaid | | User closes modal | Close action | Modal dismissed without payment | ###### Wireframe(s) Figure 164 – Wireframes – Make a Payment Modal ##### Raise a Dispute **Purpose: **The Raise a Dispute action directs the user into the dispute workflow for the selected toll transaction. The dispute flow is initiated with contextual transaction information prefilled to reduce user effort and ensure the dispute is associated with the correct transaction. **Inputs:** Selected toll transaction Toll ID Support enquiry type Additional contextual transaction data **Outputs****:** User directed to dispute flow with prefilled contextual data **Controls****:** Raise a Dispute action ###### Business Rules Table 148 – Business Rules – Raise a Dispute | Rule Name | Description | | --- | --- | | Toll Context Required | Raise a Dispute is available only for dispute-eligible toll transactions. | | Prefilled Data | Available dynamic information, such as Toll ID and support enquiry type, must be prefilled in the dispute flow. | | Workflow Handover | The Account History page acts as an entry point into the dispute process rather than containing the full dispute workflow. | ###### Validation and System Responses Table 149 – Website Validations – Raise a Dispute | Event | Input | Output | | --- | --- | --- | | User selects Raise a Dispute | Eligible toll transaction | User directed into dispute flow | | Dispute flow opens | Transaction context passed | Relevant dynamic fields prefilled | ###### Wireframe(s) Figure 165 – Wireframes – Raise a Dispute Entry Point from Toll Details ##### Account History Section **Purpose: **The Account History section provides a complete chronological log of account transactions, including toll charges, auto-replenishment payments, one-time payments, and associated account balance changes. **Inputs:** Full transaction history dataset Vehicle / plate data Toll point / road data Date and time Amount Transaction type Account balance after transaction Transaction status **Outputs:** Display of transaction history Access to transaction detail actions Support for export and filtering Paginated transaction history view **Controls:** The Account History section consists of the following columns: Selection checkbox Transaction ID State – Plate Toll Point / Road Date & Time Amount Transaction Type Account Balance after Transaction Status Actions Menu Supported transaction types include: Toll Auto-replenishment payment One-time payment Supported status values include: Paid Unpaid Success Failed Available actions are as described for transaction actions above. ###### Business Rules Table 150 – Business Rules – Account History Section | Rule Name | Description | | --- | --- | | Complete Chronological Log | The Account History section provides the complete historical record of account transactions returned by backend systems. | | Read-Only Transaction Data | Transaction data displayed in the history table is informational and cannot be edited directly. | | Type Display | Transaction type values are displayed as returned by backend systems and supported configuration. | | Balance After Transaction | Where available, the account balance after the transaction must be displayed. | | Shared Action Behavior | Actions available from Account History follow the same logic as other transaction details and payment / dispute entry behaviors described above. | | Pagination Support | Pagination is displayed when transaction volume exceeds the page limit. | ###### Validation and System Responses Table 151 – Website Validations – Account History Section | Event | Input | Output | | --- | --- | --- | | Account History page loads | Transaction history dataset | Account History table displayed | | User selects transaction row | Checkbox selection | Row marked for export / selection | | User opens action menu | Row action menu | Available actions displayed | | User selects View Details | View action | Appropriate detail modal opened | | User selects Make a Payment on eligible record | Payment action | Payment workflow opened | | User selects Raise a Dispute on eligible record | Dispute action | User directed to dispute flow | | Transaction history exceeds page limit | Dataset exceeds page size | Pagination controls displayed | ###### Wireframe(s) Figure 166 – Wireframes – Account History Section #### Support and Dispute Pages **Purpose: **The Support & Disputes page is an authenticated section of the Personal Account User Portal that allows users to view case summaries, review case and dispute history, open existing support requests, submit new support requests, upload supporting documentation, and communicate within active or historical cases. All case and dispute data displayed on this page is dynamically retrieved from backend systems and is specific to the authenticated user account. Following the current solution approach, disputes are treated as a type of support request raised through a unified support request flow. The same flow can be initiated from multiple entry points across the portal, including the Support & Disputes page, Account History, and Invoice-related views. Where the flow is triggered contextually, relevant values are prefilled automatically. **Inputs:** Authenticated user session Case and dispute records associated with the account Case status values Case metadata Support request type configuration Enquiry type configuration Enquiry category configuration Enquiry detail configuration Contextual source data from other portal sections, where applicable Transaction ID, invoice ID, toll ID, and related record data, where applicable Uploaded evidence files Existing case comments Registered user account data Non-registered user contact details, where applicable in the wider shared support flow **Outputs****:** Display of case summary counts Display of support and dispute history Opening of support request details for selected case Submission of new support requests and disputes Upload of supporting files Addition of case comments Creation of context-aware prefilled support requests Updated case history and status information following successful submission or updates **Controls:** The Support & Disputes page consists of the following functional components: Support & Disputes navigation tab Case Summary Cards Support and Dispute History Table Submit a Support Request button Support Request Details view Unified Support Request view Pagination controls ##### Support and Dispute Page Overview ###### Business Rules Table 152 – Business Rules – Support & Disputes Page | Rule Name | Description | | --- | --- | | Authenticated Access Only | The Support & Disputes page is available only to authenticated users. | | Active Navigation State | The Support & Disputes tab must be displayed as the active tab while the user is on the Support & Disputes page. | | User-Scoped Data | Only cases and disputes associated with the authenticated account may be displayed in the authenticated portal view. | | Unified Support Request Model | Disputes are handled as a type of support request raised through a single shared support request flow. | | Contextual Entry Points | The support request flow may be launched from multiple areas of the portal, including Support & Disputes, Account History, and Invoice views. | | Contextual Prefill | When the support request flow is launched from a contextual source, relevant values such as Enquiry Type, Enquiry Category, Transaction ID, or Invoice reference must be automatically prefilled. | | Variable Form Behavior | The support request form is dynamic and changes based on the selected Enquiry Type, Enquiry Category, and Enquiry Details. | | Authenticated Default Context | When the user initiates the support request flow directly from the Support & Disputes page, the default initial view is the general support enquiry path unless another path is selected. | | Case Detail Access | Selecting a Case / Dispute ID opens the Support Request Details view for that record. | | Comment Thread Chronology | Comments must be displayed in chronological order according to system-defined sort logic. | | Attachment Display Limit | The Support Request Details view displays up to two image evidence attachments in the current design. | | Pagination Display | Pagination controls are displayed where case history volume exceeds the page limit. | ###### Validation and System Responses Table 153 – Website Validations – Support & Disputes Page | Event | Input | Output | | --- | --- | --- | | User opens Support & Disputes page | Authenticated session | Support & Disputes tab displayed as active; page data loaded | | Backend returns case summary values | Summary dataset | Summary cards populated | | Backend returns case history records | Case history dataset | Support and Dispute History table displayed | | User clicks Case / Dispute ID | Selected case ID | Support Request Details view opened | | User clicks Submit a Support Request | Submit Support Request action | Unified Support Request view opened | | User initiates dispute from another portal area | Contextual support request entry | Unified Support Request view opened with relevant fields prefilled | | Case history exceeds page limit | Dataset exceeds page size | Pagination controls displayed | ###### Wireframe(s) Figure 167 – Wireframes– Support & Disputes Page Figure 168 – Wireframes – Support Request Details View Figure 169 – Wireframes– Unified Support Request View – General Enquiry Figure 170 – Wireframes – Unified Support Request View – Transaction-Level Dispute Example Figure 171 – Wireframes – Unified Support Request View – Invoice-Level Dispute Example ##### Case Summary Cards **Purpose: **The Case Summary Cards provide high-level metrics for the support requests and disputes associated with the authenticated account. **Inputs****:** Total cases and disputes count Open cases and disputes count Resolved cases and disputes count **Outputs****:** Display of summary values for account-associated support cases and disputes **Controls****:** Three summary cards are displayed: Total Cases & Disputes Open Cases & Disputes Resolved Cases & Disputes Each card consists of: Title Value ###### Business Rules Table 154 – Business Rules – Case Summary Cards | Rule Name | Description | | --- | --- | | Read-Only Summary Values | Summary card values are informational only and cannot be edited by the user. | | Backend-Driven Counts | Summary values are retrieved dynamically from backend systems. | | User Scope | Counts must reflect only support requests and disputes associated with the authenticated account. | | Automatic Refresh | Counts update automatically when backend data changes and the page is refreshed or reloaded. | ###### Validation and System Responses Table 155 – Validation and System Responses – Case Summary Cards | Event | Input | Output | | --- | --- | --- | | Support & Disputes page loads | Summary dataset | All three cards displayed with current values | | New support request submitted successfully | Updated backend data | Summary values refreshed on next load / refresh | | Case status changes in backend | Updated backend data | Summary values reflect new state | ###### Wireframe(s) Figure 172 – Wireframes – Case Summary Cards ##### Support and Dispute History Table **Purpose: **The Support and Dispute History Table provides a list of all support requests and disputes associated with the authenticated account and acts as the primary entry point into case-level detail views. **Inputs:** Case / Dispute ID Reason Date submitted Current status Last update date Resolution summary Pagination state **Outputs****:** Display of case history records Access to Support Request Details view **Controls****:** The Support and Dispute History Table consists of the following columns: Case / Dispute ID Reason Submitted Status Last Update Resolution Additional controls: Pagination Submit a Support Request button The Case / Dispute ID is clickable and opens the Support Request Details view. ###### Business Rules Table 156 – Business Rules – Support and Dispute History Table | Rule Name | Description | | --- | --- | | Backend-Driven Records | Table rows are generated from backend case and dispute data associated with the authenticated account. | | Clickable Case ID | Selecting a Case / Dispute ID opens the Support Request Details view for that specific record. | | Read-Only History Data | Case summary data shown in the table is informational and cannot be edited directly from the table. | | Status Display | Status values such as Pending Review, Resolved, or In Progress are displayed as returned by backend systems. | | Resolution Display | Resolution summary is shown where a value is available from backend systems. | | Pagination Support | Pagination is displayed when the number of case history records exceeds the page limit. | | Submission Entry Point | The Submit a Support Request button opens the unified support request flow. | ###### Validation and System Responses Table 157 – Website Validations – Support and Dispute History Table | Event | Input | Output | | --- | --- | --- | | Page loads | Case history dataset | Table populated | | No case history exists | Empty dataset | Empty state shown; Submit a Support Request remains available | | User clicks Case / Dispute ID | Selected case ID | Support Request Details view opened | | User clicks Submit a Support Request | CTA selected | Unified Support Request view opened | | History volume exceeds page limit | Dataset exceeds page size | Pagination controls displayed | | User changes page | Pagination action | Selected page of case history displayed | ###### Wireframe(s) Figure 173 – Wireframes – Support and Dispute History Table ##### Support Request Details View **Purpose: **The Support Request Details view displays detailed information for a selected support request or dispute and allows ongoing communication between the user and the support team through the case comment thread. **Inputs:** Selected Case / Dispute ID Case status Created date Last updated date Support request type Detailed support reason Case title Case description Evidence attachments Existing comments New comment input **Outputs****:** Detailed display of case content Display of supporting evidence Display of chronological case comments Submission of a new comment to the case **Controls****:** The Support Request Details view consists of: Title — Support Request Details: [ID] Close (x) control **Case Metadata****:** Status Created date Last updated date Support request type **Case Content****:** Detailed support reason Title Description Evidence attachments (up to two images displayed in current design) **Comments Section****:** Comment input field Add a Comment button Comment thread displaying: - Comment content - Comment author - Date and time ###### Business Rules Table 158 – Business Rules – Support Request Details View | Rule Name | Description | | --- | --- | | Backend ID Source | The case ID displayed in the view title is pulled from backend systems. | | Read-Only Metadata | Case metadata and core case content are informational and cannot be directly edited from this view unless explicitly enabled elsewhere. | | Image Display and Limit | Up to two image attachments are displayed in the current view design. Providing images associated with image-based Toll Transactions available to customers. | | Comment Thread Visibility | Existing comments for the selected case must be displayed in the comment thread. | | Chronological Comment Ordering | Comments are displayed in chronological order according to the configured system sort order. | | Comment Submission | Users may add a new comment to the selected case using the comment field and action button. | | Modal / Overlay Dismissal | Selecting the Close (x) control closes the view without modifying case data. | ###### Validation and System Responses Table 159 – Website Validations – Support Request Details View | Event | Input | Output | | --- | --- | --- | | User opens case details | Selected case ID | Support Request Details view opened and populated | | Backend returns case attachments | Attachment dataset | Up to two evidence images displayed | | Backend returns case comments | Comment dataset | Comment thread displayed | | User enters comment text | Comment input | Value stored in input field | | User submits valid comment | Comment text present | Comment added to case; thread refreshed | | User submits empty comment | No comment content | Validation error shown or submission blocked | | User closes details view | Close action | View dismissed | ###### Wireframe(s) Figure 174 – Wireframes – Support Request Details View ##### Unified Support Request View **Purpose: **The Unified Support Request View is the global support form used to create both general support enquiries and disputes. The form supports dynamic behavior and changes based on user selections and the context from which the form is launched. When accessed directly from the Support & Disputes page, the user is presented with a standard general enquiry path by default. When accessed from a contextual source such as Account History or Invoice views, correlating information is prefilled automatically and some questions may be prefilled, obscured, or removed depending on the final implementation. **Inputs:** Entry source Enquiry Type Enquiry Category Enquiry Details values Detailed support reason / comments Uploaded files Contextual transaction or invoice data, where applicable Dispute reason Additional dynamic fields required by selected form path Confirmation statement, where applicable **Outputs:** Submission of a general support request Submission of a dispute support request Upload of supporting evidence Creation of a backend support ticket / dispute record **Controls:** The Unified Support Request View consists of: Title Close (x) control Enquiry Type dropdown Enquiry Category dropdown, where applicable Dynamic Enquiry Details fields Comments / Description Field File upload control, where applicable Confirmation statement, where applicable Back button Submit button ###### Business Rules Table 160 – Business Rules – Unified Support Request View | Rule Name | Description | | --- | --- | | Unified Form Structure | The same core support request form is used for both general support enquiries and disputes. | | Dynamic Form Variation | The visible fields and required inputs change according to the selected Enquiry Type, Enquiry Category, and Enquiry Details. | | Contextual Prefill | Where the form is launched from a contextual source, related values must be prefilled automatically. | | Optional Question Suppression | Prefilled contextual entry may allow some questions, such as Enquiry Type or Enquiry Category, to be hidden or locked depending on final implementation. | | Registered User Simplification | For authenticated users, account-related identity information is assumed from the signed-in profile and does not need to be re-entered. | | File Upload Optionality | File upload is optional unless a specific dynamic path makes evidence mandatory. | | Submit Enablement | Submit remains disabled until all mandatory fields visible for the active form path are completed and validated. | | Backend Submission | On successful submission, the request is sent to backend systems, and a case / dispute record is created. | ###### Validation and System Responses Table 161 – Website Validations – Unified Support Request View | Event | Input | Output | | --- | --- | --- | | User opens support request flow from Support & Disputes page | Submit a Support Request action | General enquiry path shown by default | | User opens support request flow from contextual source | Contextual entry such as Account History or Invoice | Relevant values prefilled automatically | | User changes Enquiry Type | Selected Enquiry Type | Form fields refresh dynamically | | User changes Enquiry Category | Selected Enquiry Category | Dependent detail fields refresh dynamically | | User uploads file | Selected file | File attached to request if valid | | User leaves required fields incomplete | Missing required values | Submit button disabled or submission blocked | | User submits valid request | Valid visible form data | Support request / dispute created successfully | | Backend rejects submission | Validation or processing failure | Error shown; form remains open | | User clicks Back | Back action | Flow closed or returned to prior step / context according to final implementation | | User clicks Close (x) | Close action | Form dismissed without saving | ###### Wireframe(s) Figure 175 – Wireframes – Unified Support Request View – General Enquiry Figure 176 – Wireframes – Unified Support Request View – Transaction-Level Dispute Example Figure 177 – Wireframes – Unified Support Request View – Invoice-Level Dispute Example ##### General Support Enquiry **Purpose: **The General Support Enquiry path allows users to submit a broad support enquiry where no specific transactional dispute context is required. **Inputs:** Enquiry Type Comments / description Optional supporting file **Outputs****:** General support ticket submitted to backend systems **Controls****:** The General Support Enquiry view consists of: Title Close (x) control Enquiry Type dropdown Comments / description field File upload control Back button Submit button ###### Business Rules Table 162 – Business Rules – General Support Enquiry | Rule Name | Description | | --- | --- | | Default Path | When launched directly from the Support & Disputes page, the standardized default support path is General Enquiry unless another option is selected. | | Enquiry Type Required | Enquiry Type must be selected before the request can be submitted where not already prefilled. | | Comments Required | The free-text description area is required unless replaced by a more specific dynamic field requirement. | | Optional Attachment | File upload is optional unless business rules for the selected enquiry path state otherwise. | ###### Validation and System Responses Table 163 – Website Validations – General Support Enquiry | Event | Input | Output | | --- | --- | --- | | User opens default support request flow | Direct CTA entry | General Enquiry variant shown | | User leaves required fields incomplete | Missing required values | Submit disabled or blocked | | User submits valid general enquiry | Valid form data | Support request created | | User uploads optional evidence | Valid file | File attached to request | ###### Wireframe(s) Figure 178 – Wireframes – Unified Support Request View – General Enquiry ##### Transaction-Level Dispute Example **Purpose: **The Transaction-Level Dispute path allows a user to dispute a toll transaction from a contextual source such as the Account History view. In this example flow, the form is automatically prefilled using the selected transaction context and the user is required to complete only the remaining dispute-specific information. **Inputs:** Prefilled Enquiry Type Prefilled Enquiry Category Prefilled selected transaction Selected dispute reason Dynamic evidence fields required by the chosen reason Comments Confirmation statement **Outputs:** Dispute support request created against the selected toll transaction **Controls****:** The Transaction-Level Dispute view may include: Enquiry Type dropdown or locked value Enquiry Category dropdown or locked value Selected Transaction field Select Dispute Reason field Dynamic evidence upload fields Comments field Confirmation statement Back button Submit button **Example Contextual Prefill** Where the user disputes transaction TRP-784512 from the Account History view: Enquiry Type is prefilled as **Payments ****&**** Billing** Enquiry Category is prefilled as **Dispute a Toll Transaction** Select a Transaction is prefilled with the selected transaction ID The user is still required to select a dispute reason. **Example Dynamic ****Behavior** If the user selects the dispute reason Sold Vehicle, the form presents an additional evidence requirement such as Proof of Sale upload. ###### Business Rules Table 164 – Business Rules – Transaction-Level Dispute Example | Rule Name | Description | | --- | --- | | Contextual Transaction Prefill | The selected transaction ID must be automatically populated when the dispute is initiated from transaction-level context. | | Enquiry Type Prefill | Enquiry Type may be automatically set based on the source context. | | Enquiry Category Prefill | Enquiry Category may be automatically set based on the source context. | | Dispute Reason Mandatory | The user must select a dispute reason before submission. | | Dynamic Evidence by Reason | Additional evidence fields may become visible and required depending on the selected dispute reason. | | Confirmation Requirement | A confirmation statement may be required before submission depending on the dispute path configuration. | ###### Validation and System Responses Table 165 – Website Validations – Transaction-Level Dispute Example | Event | Input | Output | | --- | --- | --- | | User launches dispute from Account History | Selected toll transaction | Form opened with contextual values prefilled | | User selects dispute reason | Reason selected | Dynamic fields refresh based on selected reason | | User selects Sold Vehicle | Sold Vehicle reason | Proof of Sale upload field displayed | | User leaves dispute reason empty | No reason selected | Submission blocked | | User omits required dynamic evidence | Missing required file / field | Validation error shown; submission blocked | | User submits valid dispute | Valid form data | Dispute case created successfully | ###### Wireframe(s) Figure 179 – Wireframes – Unified Support Request View – Transaction-Level Dispute Example ##### Invoice-Level Dispute Example **Purpose: **The Invoice-Level Dispute path allows a user to dispute an invoice from a contextual source such as the Invoice or Documents views. As with the transaction-level dispute path, the form is automatically prefilled using the originating invoice context and then dynamically adapts based on the selected dispute reason. **Inputs:** Prefilled Enquiry Type Prefilled Enquiry Category Prefilled selected invoice Selected dispute reason Dynamic evidence fields required by the chosen reason Date of incident, where applicable Comments Confirmation statement **Outputs:** Dispute support request created against the selected invoice **Controls:** The Invoice-Level Dispute view may include: Enquiry Type dropdown or locked value Enquiry Category dropdown or locked value Selected Invoice field Select Dispute Reason field Date of Incident field, where required Evidence upload field, where required Comments field Confirmation statement Back button Submit button **Example Dynamic ****Behavior** If the user selects the dispute reason Vehicle Stolen, the form presents: Date of Incident Upload Police Report ###### Business Rules Table 166 – Business Rules – Invoice-Level Dispute Example | Rule Name | Description | | --- | --- | | Contextual Invoice Prefill | The selected invoice reference must be automatically populated when the dispute is initiated from invoice context. | | Dispute Reason Mandatory | The user must select a dispute reason before submission. | | Dynamic Incident Fields | Additional date and file fields may be displayed based on the selected dispute reason. | | Vehicle Stolen Requirements | For the Vehicle Stolen path, Date of Incident and Police Report upload are required. | | Confirmation Requirement | A confirmation statement may be required before submission depending on the dispute path configuration. | ###### Validation and System Responses Table 167 – Website Validations – Invoice-Level Dispute Example | Event | Input | Output | | --- | --- | --- | | User launches dispute from invoice context | Selected invoice | Form opened with contextual values prefilled | | User selects Vehicle Stolen | Vehicle Stolen reason | Date of Incident and Police Report fields displayed | | User leaves required fields incomplete | Missing required values | Submission blocked | | User omits required police report | Missing required upload | Validation error shown | | User submits valid dispute | Valid form data | Dispute case created successfully | ###### Wireframe(s) Figure 180 – Wireframes– Unified Support Request View – Invoice-Level Dispute Example #### Safety Enforcement Page **Purpose:** The Safety Enforcement page is an authenticated section of the Personal Account User Portal that allows registered users to view, review, and act on Safety Enforcement notices associated with their account and linked vehicles. The page provides a consolidated summary of Safety Enforcement notices and enables the user to: Review notice-level summary information View full notice details Select notices for payment Pay all eligible displayed notices Access invoice-level detail where applicable Navigate to the dispute workflow All data displayed on this page is dynamically retrieved from backend systems and is scoped to the authenticated user account and its linked vehicles. **Inputs:** Authenticated user session Safety Enforcement notice records linked to the account Vehicle identifiers Notice number Notice date Amount due Discounted / escalated amount rules, where applicable Notice status Full notice detail data Related invoice and toll data, where applicable Payment eligibility data **Outputs:** Display of Safety Enforcement notices linked to the account Display of full notice details Display of invoice details linked to a vehicle, where accessed Payment of selected notices Payment of all eligible displayed notices Progression to dispute workflow **Controls:** The Safety Enforcement section consists of the following functional components: Safety Enforcement navigation tab Safety Enforcement list table View Full Notice action Pay Selected action Pay All action Dispute entry point Full Notice Details modal Invoice Details modal Pagination controls ##### Safety Enforcement Page Overview ###### Business Rules Table 168 – Business Rules – Safety Enforcement Page | Rule Name | Description | | --- | --- | | Authenticated Access Only | The Safety Enforcement page is available only to authenticated users. | | Active Navigation State | The Safety Enforcement tab must be displayed as the active tab while the user is on the Safety Enforcement page. | | User-Scoped Data | Only Safety Enforcement notices associated with the authenticated account or linked vehicles may be displayed | | Notice Selection for Payment | Users may select one or more eligible notices for payment where selection controls are available. | | Pay All Availability | Pay All applies to all currently displayed and eligible notices in the list. | | View Full Notice Availability | Users must be able to open the full notice details for a selected Safety Enforcement notice. | | Dispute Entry Point | Users must be able to initiate the dispute flow from the Safety Enforcement experience. | | Dynamic Amount Rules | Displayed amounts may include discounted values if paid by a specified date, or escalated values if paid after that date, as returned by backend rules. | | Backend-Driven Statuses | Notice statuses are retrieved from backend systems and displayed read-only. | | Pagination Support | Pagination must be shown where the number of notices exceeds the configured page size. | ###### Validation and System Responses Table 169 – Website Validations – Safety Enforcement Page | Event | Input | Output | | --- | --- | --- | | Authenticated user opens Safety Enforcement page | Valid session | Safety Enforcement tab displayed as active; notices loaded | | Backend returns notice records | Safety Enforcement dataset | Notice table populated | | User selects one or more notices | Checkbox selection | Pay Selected amount updated | | User clicks Pay Selected | Valid selected notices | Payment workflow initiated | | User clicks Pay All | Displayed eligible notices | Payment workflow initiated | | User clicks View Full Notice | Notice row action | Users will be able to view the Full Notice once clicking on the action link. | | User clicks dispute link | Dispute entry action | User routed to dispute workflow | | No Safety Enforcement records found | Empty dataset | If there are no active safety notices in place, users will still be able to access the page. It will act as a navigation page allowing users to see the basic information related to the STEP program. | | Results exceed page size | Dataset exceeds page limit | Pagination controls displayed | ###### Wireframe(s) Figure 181 – Wireframes – Safety Enforcement List Page Figure 182 – Wireframes – Full Notice Details Modal Figure 183 – Wireframes – Invoice Details Modal ##### Safety Enforcement List **Purpose:** The Safety Enforcement List provides a tabular summary of Safety Enforcement notices associated with the authenticated user account. It allows the user to review notice metadata, see payment status, select liabilities for payment, and open full notice details. **Inputs:** Safety Enforcement notice records Notice number Vehicle state and plate Notice date Amount data Status data Eligibility for payment **Outputs:** Display of Safety Enforcement records Selection of records for payment Access to full notice detail view Access to payment actions **Controls:** The Safety Enforcement List consists of the following items: Selection checkbox Notice Number State Plate Notice Date Amount Status View Full Notice action Pagination controls Pay Selected button Pay All button Dispute link / helper text **Status Notes:** Supported status values may include: Overdue Not Paid Partial Paid Paid Disputed A full list and definition of each status will be included as part of the CBOS documentation. **Amount Notes:** Where applicable, the amount column may display: Current amount due Discounted amount if paid by a stated date Increased amount if paid after a stated date ###### Business Rules Table 170 – Business Rules – Safety Enforcement List | Rule Name | Description | | --- | --- | | Read-Only Notice Data | Notice metadata displayed in the table is informational and cannot be edited directly. | | Checkbox Selection | Users may select eligible notices using row-level checkboxes. | | Dynamic Pay Selected Amount | The Pay Selected button label and amount must reflect the currently selected eligible notices. | | Full Notice Access | The View Full Notice action opens full notice details for the selected notice. | | Backend Status Display | Statuses must be displayed exactly as returned by backend systems or mapped UI values. | | Discount / Escalation Display | Where amount rules apply, discounted or escalated values must be displayed with their associated conditions. | | Pagination Support | Pagination controls are displayed when the number of records exceeds the page limit. | ###### Validation and System Responses Table 171 – Website Validations – Safety Enforcement List | Event | Input | Output | | --- | --- | --- | | Safety Enforcement page loads | Notice dataset | Table populated | | User selects notice rows | Checkbox input | Selected records marked; Pay Selected total recalculated | | User deselects notice rows | Checkbox input | Selected total updated | | User clicks View Full Notice | Notice action | Full Notice Details modal opened | | User clicks Pay Selected with valid selections | One or more selected eligible rows | Payment flow initiated | | User clicks Pay Selected with no selection | No selected rows | Action blocked or validation message shown | | User clicks Pay All | All displayed eligible rows | Payment flow initiated | | Notice results exceed page size | Dataset exceeds page limit | Pagination controls displayed | ###### Wireframe(s) Figure 184 – Wireframes – Safety Enforcement List ##### Full Notice Details **Purpose:** The Full Notice Details modal allows the user to view the full content of a Safety Enforcement notice, including vehicle details, penalty details, violation information, and supporting evidence imagery returned by backend systems. **Inputs:** Notice identifier Vehicle details VIN Civil penalty number Violation reason Violation location Violation date and time Evidence images **Outputs:** Display of full notice detail record Access to notice information for review prior to payment or dispute **Controls:** The Full Notice Details modal consists of: Title Close (x) control Vehicle Details section Penalty Details section Evidence section with image assets ###### Business Rules Table 172 – Business Rules – Full Notice Details | Rule Name | Description | | --- | --- | | Notice-Specific Retrieval | Full Notice Details must be retrieved for the selected notice only. | | Read-Only Detail View | All data in the Full Notice Details modal is informational and cannot be edited. | | Evidence Display | Supporting evidence images are displayed where available from backend systems. | | Vehicle Context | Vehicle identifiers such as license plate and VIN must be displayed where provided. | ###### Validation and System Responses Table 173 – Website Validations – Full Notice Details | Event | Input | Output | | --- | --- | --- | | User opens full notice | Valid notice selection | Full Notice Details modal opened | | Backend returns full notice record | Full notice dataset | Vehicle details, penalty details, and evidence displayed | | Evidence not available | No image assets returned | Evidence section shown empty or hidden based on design | | User closes modal | Close action | Modal dismissed | ###### Wireframe(s) Figure 185 – Wireframes – Full Notice Details Modal #### Account Settings Page **Purpose:**** **The Account Settings section is an authenticated area within the Account Management portal that allows users to view and manage both account-specific configuration and global user settings associated with their profile. This section operates within the context of the selected account from the Multi-Account Switcher and provides a structured separation between: Account-level settings, which apply only to the currently selected account Global settings, which apply to the authenticated user profile across all accessible accounts Account-level settings include: Account metadata (account name, number, type, status, date joined) Account information and configuration Communication and statement preferences tied to the selected account Global settings include: Authorized contacts management Personal profile information Security and credential management The section acts as a central entry point for managing account configuration and user profile data, ensuring that changes are applied at the correct scope (account vs global) depending on the type of setting being updated. All data displayed within this section is dynamically retrieved from backend systems and is scoped based on the: Authenticated user Selected account context User’s permission level (account owner or authorized contact) **Inputs:** Authenticated user session Selected account context (from Multi-Account Switcher) Account profile data (account name, number, type, status, date joined) Account-level configuration data Communication and statement preferences (account-level) User profile data (personal information) Security credentials metadata Permission levels (account owner vs. authorized contact) Backend validation rules **Outputs:** Display of account-specific configuration data for the selected account Display of global profile settings Updates to account-level configuration (e.g. communication preferences) Updates to authorized contacts and permission assignments Updates to personal profile information Execution of credential management actions (password reset, email update) Context-aware navigation between account-level and global settings Enforcement of permission-based visibility and actions **Controls:** Account Settings navigation tab Account Summary Card (read-only account metadata) Settings navigation list (grouped into Account Settings and Global Settings) Section entry cards (e.g. Account Information, Communication Preferences) Global settings entry points (Authorized Contacts, Personal Information, Security Settings) Edit actions (buttons / links) Modal dialogs (edit forms, verification flows) Back navigation controls ##### Account Setting Page Overview ###### Navigation Flow Figure 186 – Flow – Account Settings Verification The account settings area is protected from editing with an additional layer of security. This is handled via an authentication process and the use of session tokens. In the event a token has expired, the user will be asked when trying to edit any of the Account Settings functionalities (Account setting, Authorized Contacts, Personal Settings) to re-enter their password before being allowed to make the edits. ###### Wireframe Figure 187 – Wireframe – Account Settings Page ##### Account Summary Card **Purpose:** Displays high-level account metadata and provides access to primary administrative actions. **Inputs:** Account Owner Name Account number Account status Account type Account creation date **Outputs:** Summary display of account information Access to administrative actions **Controls:** Account Owner Name Account Number (read-only) Account Status Account Type Date Joined Close Account button ###### Business Rules Table 174 – Business Rules – Account Summary Card | Rule Name | Description | | --- | --- | | Read-Only Fields | Account number and metadata are not editable | | Status Source | Status is controlled by backend system | | Close Account | Initiates account closure flow | ###### Validation and System Responses Table 175 – Validation and System Responses– Account Summary Card | Event | Input | Output | | --- | --- | --- | | Page Load | Account data | Summary card populated | | Click Close Account | User action | Navigate to closure flow | ###### Wireframe (s) Figure 188 – Wireframes – Account Summary Card ##### Account Specific Settings Navigation List **Purpose:** The Account-Specific Settings section allows users to manage configuration and preferences that apply **only to the currently selected account**. These settings are scoped at the account level and do not impact other accounts linked to the same user. The section is presented as a structured list of configurable areas, each leading to a more detailed view or edit flow. Account-specific configuration includes: Account Information Communication and Statement Preferences This separation ensures that users managing multiple accounts can maintain distinct configurations per account. **Inputs:** Selected account context Account configuration data Communication preferences dataset Statement delivery preferences Backend validation rules **Outputs:** Display of account-specific configuration sections Navigation to detailed configuration screens Updates to account-level settings **Controls:** Account settings navigation cards (clickable sections) Forward navigation indicators (e.g. arrows) Back navigation controls ###### Business Rules Table 176 – Business Rules – Account Specific Settings Navigation List | Rule Name | Description | | --- | --- | | Account-Level Scope | All settings in this section apply only to the currently selected account. | | Independent Configuration | Each account must maintain its own independent configuration settings. | | Navigation-Based Editing | Selecting a settings item must navigate the user to a dedicated detail or edit screen. | | Permission Enforcement | Available actions must be restricted based on user role (account owner vs authorized contact). | | Cross-Account Isolation | Changes made in one account must not impact other accounts. | ###### Wireframe(s) Figure 189 – Wireframe – Account Specific Settings – Navigation List ##### Global Account Settings **Purpose:** The Global Settings section allows users to manage profile-level configuration that applies **across all accounts** associated with their identity. Unlike account-specific settings, these configurations are **user-centric** and persist regardless of which account is currently selected. Global settings include: Authorized Contacts Personal Information Security and Password Settings This section ensures consistent user identity management while supporting multi-account access. **Inputs:** Authenticated user profile Authorized contacts data Personal information data Security credentials metadata Permission model Backend validation rules **Outputs:** Display of global settings sections Updates to authorized contacts Updates to personal profile data Execution of credential management flows **Controls:** Global settings navigation cards Edit actions (buttons / links) Modal dialogs (for editing and verification) Back navigation ###### Business Rules Table 177 – Business Rules – Global Account Settings | Rule Name | Description | | --- | --- | | Global Scope | Settings in this section apply across all accounts linked to the user. | | Single Identity Model | Each user must have a single profile that governs global settings | | Authorized Contact Management | Authorized contacts must be managed at the global level but may have account-specific permissions. | | Permission-Based Visibility | Available global settings actions must depend on user role and permissions. | | Credential Security | Security-related updates must follow strict validation and verification processes. | | Cross-Account Consistency | Changes to global settings must be reflected across all accessible accounts. | ###### Wireframes Figure 190 – Wireframes – Global Account Settings ##### Account Information **Purpose:** The Account Information section allows users to view and manage core details associated with the currently selected account. This section presents a combination of: **Read-only account metadata** (account number, type, status, date joined) **Editable account owner details** (name, contact information, mailing address) Users can update account-related personal and contact details via a modal-based edit flow. All updates are validated and persisted through backend systems. This section operates within the context of the selected account from the Multi-Account Switcher, ensuring that all displayed and updated data applies only to that specific account. **Inputs:** Authenticated user session Selected account context Account metadata (name, number, type, status, date joined) Account owner details (name, email, mobile number) Mailing address data Verification channels (email / mobile) Backend validation rules **Outputs:** Display of account information Updates to account name Updates to mobile number (with verification) Updates to mailing address Triggering of account closure flow **Controls:** Edit Details button Update Account Details modal Form inputs Verify mobile action Update Details button ###### Business Rules Table 178 – Business Rules – Account Settings – Account Information | Rule Name | Description | | --- | --- | | Account Context Binding | All data must reflect the currently selected account | | Metadata Read-Only | Account number, type, status, and date joined cannot be edited | | Editable Fields Scope | Only account name, contact details, and mailing address may be updated | | Modal-Based Editing | Updates must be performed through the modal | | Verification Requirement | Mobile number updates require verification before saving | | Email Update and Verification | Email address can be edited and it needs to be verified | | Account Closure Entry Point | The Close Account button must initiate the dedicated account closure flow. | ###### Validation and System Responses Table 179 – Website Validations – Account Settings – Account Information | Event | Input | Output | | --- | --- | --- | | Click Edit Details | User action | Editable modal opens | | Update fields | User input | Validation applied | | Submit changes | Valid input | Password verification triggered | | User updates mobile number | New value | Verification required before submission | | Password verification success | Valid password | Changes saved | | Password verification failure | Invalid password | Error message displayed | ###### Wireframe(s) Figure 191 – Wireframes – Account Information Figure 192 – Wireframes – Account Information – Edit Modal Figure 193 – Wireframes – Password Verification ##### Authorized Contacts Please refer to Section **Error! Reference source not found.**, **Error! Reference source not found.**. Authorized Contacts within Account Settings are detailed in Sections 4.3.9.9, Authorized Contacts Overview and 4.3.9.10, Authorized Contact Details. ##### Communications & Statements Preferences **Purpose:** The Communications & Statements Preferences section allows users to manage how they receive notifications and account-related communications for the currently selected account. This includes: Viewing configured communication channels (email, mobile, mailing address) Selecting types of notifications to receive Choosing preferred delivery methods (email, push, SMS) Defining statement delivery preferences (digital or paper-based) All preferences configured in this section apply only to the selected account and do not impact other accounts. **Inputs:** Authenticated user session Selected account context Account contact details (email, mobile, address) Notification preferences dataset Statement delivery preferences **Outputs:** Display of communication methods Updates to notification preferences Updates to delivery channels (email, push, SMS) Updates to statement delivery preferences **Controls:** Edit Account Details button Toggle controls (on/off) Enable All / Disable All actions Save Changes button ###### Business Rules Table 180 – Business Rules – Communications & Statements Preferences | Rule Name | Description | | --- | --- | | Account-Level Scope | Preferences apply only to the currently selected account | | Contact Source Dependency | Communication methods (email, mobile, address) are sourced from Account Information and are not editable directly in this section. | | Critical Notifications Override | Critical notifications must still be delivered regardless of user opt-out selections. | | Toggle-Based Preferences | Notification types and delivery methods must be controlled via toggle inputs | | Bulk Preference Actions | Users must be able to enable or disable all notification types using bulk actions. | | Channel Availability | Notification channels (email, push, SMS) must only be selectable if supported and verified. | | Statement Delivery Selection | Users must select at least one statement delivery method (email or paper). | | Paper Statement Charge | Selecting paper-based statements may incur a fee, which must be clearly communicated. | | Explicit Save Action | Changes are not persisted until the user selects "Save Changes". | ###### Validation and System Responses Table 181 – Website Validations – Communications & Statements Preferences | Event | Input | Output | | --- | --- | --- | | User toggles notification type | Toggle action | Preference updated in form state | | User selects Enable All / Disable All | Action | All notification toggles updated accordingly | | User updates delivery channels | Toggle action | Channel preferences updated in form state | | User selects statement delivery option | Toggle action | Statement preference updated | | User clicks Edit Account Details | Action | Redirect to Account Information section | | User clicks Save Changes | Valid inputs | Preferences saved and confirmed | ###### Wireframe(s) Figure 194 – Wireframes- Communications & Preferences ##### Profile Settings Overview Please refer to Section 4.3.9.5, Profile Settings Overview. ##### Personal Information Please refer to Section 4.3.9.6, Personal Information. ##### Update Personal Details Modal Please refer to Section 4.3.9.7, Update Personal Details Modal. ##### Security and Password Settings Please refer to Section **Error! Reference source not found.**, **Error! Reference source not found.**. ##### Re-Authentication (OTC Verification and Re-Enter Password Verification) **Purpose:** The Re-Authentication flows provide an additional security layer for sensitive account actions. The flow supports two different security mechanisms depending on the action being performed: **Password Re-Authentication: **Required before editing protected account information for: - Personal Information - Authorized Contacts **Email Verification (One-Time Code)****:**** **Required when changing sensitive credential-related fields for: - Email address - Mobile phone number - Password Password re-authentication creates a temporary authorized session that allows protected edits without repeated password prompts for a limited duration. **Inputs:** Authenticated user session Password entry Email-based one-time verification code Sensitive action request **Outputs:** Verified user identity Temporary authorized session Permission to proceed with protected action Verified credential update request **Controls:** Password input field Submit button One-time code input fields Verify Email button Resend code option Modal close action ###### **Business Rules** Table 182 – Business Rules – Re-Authentication | Rule Name | Description | | --- | --- | | Password Re-Authentication Required | Users must re-enter their password before editing protected profile information or authorized contacts | | Credential Update Verification | Email verification is required when updating email address, mobile number, or password | | Email Verification Only | One-time verification codes are sent only via email. | | Temporary Authorized Session | Successful password re-authentication creates an authorized editing session. | | Session Duration | The authorized editing session remains valid for 15 minutes. | | Session Expiry | After session expiry, users must re-enter passwords to perform additional protected edits. | | Code Expiry | Email verification codes expire after a defined duration (15 minutes). | | Code Request Limit | Verification code may only be requested once every 60 seconds. | | Retry Limits | Verification attempts are limited to 3 attempts before triggering a lockout; then requiring a new token to reduce the attack risks | ###### Validation and System Responses Table 183 – Validation and System Responses – Re-Authentication | Event | Input | Output | | --- | --- | --- | | User initiates protected edit | Protected action | Password re-authentication modal displayed | | User enters password | Password input | Password validated | | Password valid | Correct credentials | Authorized editing session created | | Password invalid | Incorrect credentials | Error message displayed | | User edits email / phone / password | Sensitive field change | Email verification required (OTC) | | Verification code requested | Email address | Code sent to registered email | | User enters verification code | Code input | Code validated | | Valid code | Correct code | Sensitive update permitted | | Invalid code | Incorrect code | Error message displayed | | Session exceeds 15 minutes | Session timeout | Re-authentication required again | ###### Wireframe(s) Figure 195 – Wireframes – Re-Enter Password Verification Figure 196 – Wireframes – OTC Verification ##### Account Closure Flow **Purpose****:** The Account Closure functionality enables authenticated users to permanently close their CTIO account. This process is designed to ensure that all outstanding obligations are resolved prior to closure and that users explicitly acknowledge the consequences of closing their account. Account closure is irreversible and includes validation checks, user confirmations, and final processing steps to ensure compliance with business and financial rules. ###### Pre-Closure Validation **Purpose****:** Ensures the account is eligible for closure by validating that there are no outstanding financial or enforcement obligations. **Inputs:** Account status data Outstanding balances (tolls, invoices, STEP notices) **Outputs:** Eligibility status (Pass / Fail) Ability to proceed or block closure **Controls:** Informational text (closure implications) Validation status indicators: - Outstanding Toll Transactions - Outstanding Invoices - Outstanding STEP Notices Back button Continue button - Business Rules Table 184 – Business Rules – Pre-Closure Validation | Rule Name | Description | | --- | --- | | Account Standing Requirement | Account must have no outstanding tolls, invoices, or STEP notices | | Validation Check | All validation items must return “Pass” before proceeding | | Irreversibility Notice | User must be informed that closure is permanent | | Outstanding Charges | Users remain liable for any toll usage prior to closure | - Validation and System Responses Table 185 – Validation and System Responses | Event | Input | Output | | --- | --- | --- | | Load screen | Account data | Display validation results | | Validation fails | Outstanding balance exists | Disable Continue / block progression | | Validation passes | No outstanding items | Enable Continue | | Click Continue | Valid state | Navigate to confirmation screen | - Wireframe(s) Figure 197 – Account Closure – Validation Screen ###### Closure Confirmation **Purpose****:** Captures user intent, reason for closure, and explicit acknowledgement of account closure implications. **Inputs****:** Reason for closing account Optional user comments User confirmations (checkboxes) **Outputs****:** Closure request submission **Controls****:** Reason dropdown (predefined values, pulled from CBOS) Additional comments text area Confirmation checkboxes: - Acknowledgement of switch to paper billing (if applicable) - Acknowledgement of loss of promotions/benefits - Acknowledgement that closure is permanent and irreversible Back button Close Account button - Business Rules Table 186 – Business Rules – Closure Confirmation | Rule Name | Description | | --- | --- | | Mandatory Acknowledgement | All required checkboxes must be selected before submission | | Reason Capture | Reason for closure must be selected | | Irreversible Action | Closure cannot be undone once submitted | | Compliance Messaging | Legal and financial implications must be clearly presented | - Validation and System Responses Table 187 – Validation and System Responses – Closure Confirmation | Event | Input | Output | | --- | --- | --- | | Submit closure | Missing inputs | Error message displayed | | Submit closure | Valid input | Closure request submitted | | Checkbox not selected | Attempt submission | Block submission with validation message | - Wireframe(s) Figure 198 – Account Closure – Confirmation Screen ###### Closure Processing and Confirmation **Purpose**: Confirms that the account closure request has been successfully submitted and provides post-closure information. **Inputs****:** Closure request **Outputs****:** Confirmation message Next steps information **Controls****:** Informational message: - Request processing timeline (e.g. X days) - Refund details (if applicable) CTA: - Return to Account Dashboard - Business Rules Table 188 – Business Rules – Closure Processing and Confirmation | Rule Name | Description | | --- | --- | | Processing Time | Closure may take a defined number of days to complete | | Refund Handling | Remaining balance must be refunded to default payment method | | Finalization | Account is deactivated upon completion of closure process | - Validation and System Responses Table 189 – Validation and System Responses – Closure processing and Confirmation | Event | Input | Output | | --- | --- | --- | | Closure submitted | Valid request | Display confirmation screen | | Refund applicable | Positive balance | Trigger refund process | | Completion | Closure finalized | Account marked as closed | - Wireframe(s) Figure 199 – Account Closure – Confirmation / Success Screen ##### Notifications (System Messages) **Purpose****:** Displays system-generated notifications related to account activity. **Inputs****:** Notification records **Outputs:** Notification list display **Controls:** Notification list Pagination Remove selected ###### Business Rules Table 190 – Business Rules – Notifications | Rule Name | Description | | --- | --- | | **Backend Driven** | Notifications retrieved from backend | | **Categorized Types** | Info, Transaction, Alerts | | **Pagination Enabled** | For large datasets | ###### Validation and System Responses Table 191 – Validation and System Responses – Notifications | Event | Input | Output | | --- | --- | --- | | Load notifications | Dataset | Display list | | Remove notification | User action | Remove from list | ###### Wireframe(s) Figure 200 – Wireframes – Notifications List View ### Business Account Management #### Introduction The Business Account User Portal provides registered business customers with a secure and centralized environment to manage their CTIO accounts following successful onboarding and activation. The portal enables business users to access and maintain account information, manage fleet vehicles and transponders, review financial activity, process payments, manage documents and invoices, and interact with customer support services. The Business Account User Portal follows the same structure, navigation model, and interaction patterns as the Personal Account User Portal, ensuring a consistent and intuitive experience across account types. All data displayed within the portal is dynamically retrieved from backend systems and is scoped to the authenticated business account. Unless explicitly stated otherwise, all functionality, workflows, business rules, validation logic, and system behaviors follow those defined in the Personal Account Management. #### Navigation Flow Figure 201 – Flow – Account Creation #### Shared Functional Behavior with Personal Account Portal **Purpose:** Ensure consistency in user experience, system behavior, and validation logic across account types. **Behavior:** The following modules and components are functionally identical to the Personal Account Management portal: Account Overview Vehicle Management (standard flows) Payments Management Documents & Invoices Account History Support & Disputes Safety Enforcement Account Settings For full functional definitions, refer to the Personal Account Management section. ##### Business Rules Table 192 – Business Rules – Shared Functional Behavior with Personal Account Portal | Rule Name | Description | | --- | --- | | Shared UX Model | Business portal must follow same UX structure as Personal Account portal | | Shared Validation Logic | All field validations follow Personal Account Portal rules | | Shared Data Behavior | Data retrieval is dynamic and scoped to authenticated account | #### Business Account–Specific Behavior **Overview: **Business Account Management introduces additional capabilities to support organizational use cases such as fleet management. The following sections describe only the functionality that differs from the Personal Account portal. ##### Vehicles Page – Bulk Upload Functionality **Purpose:** Enable business users to register and manage multiple vehicles in a single action to support fleet onboarding and management. **Inputs:** CSV file containing vehicle data (the file format is specified in Detailed Design Document (CDRL06), App 6.36_Web API document) Vehicle dataset (plate, state, make, model, type) Bulk upload configuration rules **Outputs:** Multiple vehicle records created Updated vehicle list Updated vehicle and transponder summary counts **Controls:** “Bulk Upload Vehicles” action File upload control Validation feedback panel Bulk vehicles table view **Behavior:** The Bulk Upload functionality extends the standard vehicle management flow by allowing business users to upload multiple vehicles simultaneously. All uploaded vehicles are validated using the same rules as manual vehicle entry. Invalid records are flagged and must be corrected before submission. ###### Business Rules Table 193 – Business Rules – Bulk Upload Vehicles | Rule Name | Description | | --- | --- | | Bulk Upload Availability | Available only for Business Accounts | | CSV Format Validation | Uploaded file must match predefined structure | | Shared Validation Rules | Each vehicle must pass same validation as manual entry | ###### Validation and System Responses Table 194 – Validation and System Responses – Bulk Upload Vehicles | Event | Input | Output | | --- | --- | --- | | User uploads file | CSV file | File processed and validated | | File format invalid | Incorrect structure | Error message shown; upload rejected | | Valid file uploaded | Valid dataset | Vehicles created and displayed | | Backend fails | System error | Upload fails; error displayed | ###### Wireframe(s) Figure 202 – Wireframes – Bulk Upload Option ### Non-Account Users #### Introduction The Non-Account Users section describes the public-access payment and dispute journeys available to users who do not access CTIO through the authenticated Personal Account User Portal. These journeys are initiated from the public website and allow a user to retrieve a bill or notice using identifying information, review liabilities associated with the related vehicle and proceed to payment or dispute submission. The public experience supports: Pay a Bill (invoice and/or STEP notice) Dispute a Bill (invoice and/or STEP notice) Check and Pay Tolls (toll transactions within the last 7 days) Guest payment Create Account & Save The experience is designed around a combined vehicle-level liability model. Once a valid invoice or notice is retrieved, the user may also be shown other invoices, notices, or toll liabilities associated with the same vehicle. However, full detail access remains specific to the record that the user has explicitly retrieved using the required identifying information. #### Activate Your Transponder Page **Purpose:**** **The Activate Your Transponder page is a public-facing activation gateway presented to users who possess a CTIO transponder but have not yet activated it against an account. The purpose of this page is to guide users into the appropriate workflow to connect their transponder to a CTIO account, either by logging into an existing account or creating a new account. Transponder activation is only considered complete once the transponder is successfully linked to a vehicle within a valid CTIO account. **Inputs:** User access (authenticated or unauthenticated) Transponder ownership (physical device) Account status (existing / non-existing) Vehicle data (during linking flow) Transponder serial number / ID Activation code (if applicable) **Outputs:** Routing to login flow Routing to account creation flow Initiation of transponder linking workflow Successful association of transponder to vehicle and account **Controls:** Page title Page description Login & Activate card Create Account & Activate card CTA buttons System routing logic ##### Activation Gateway Page **Purpose: **Serves as the entry point for all users attempting to activate a CTIO transponder and directs them into the appropriate workflow based on account status. **Inputs:** User selection (Login & Activate / Create Account & Activate) **Outputs:** Redirect to login or onboarding flow **Controls:** Title (CMS editable) Description (CMS editable) Activation option cards ###### Business Rules Table 195 – Business Rules – Activation Gateway Page | Rule Name | Description | | --- | --- | | Public Accessibility | Page must be accessible without authentication | | CMS-Controlled Content | Title and description are CMS editable | | Dual Path Entry | Users must be presented with both activation options | | No Direct Activation | Transponder cannot be activated directly on this page | ###### Validation and System Responses Table 196 – Validation and System Responses – Activation Gateway Page | Event | Input | Output | | --- | --- | --- | | Page load | Public access | Activation options displayed | | User selects Login & Activate | Click action | Redirect to login | | User selects Create Account & Activate | Click action | Redirect to onboarding | ###### Wireframe(s) Figure 203 – Wireframes – Activate Transponder – Gateway Page (Login vs Create Account) ##### Login and Activate Flow **Purpose:** Allows existing users to activate a transponder by logging into their account and linking the device to a vehicle. **Inputs:** User credentials Existing account session Transponder details Vehicle selection **Outputs:** Authenticated session Redirect to vehicle management Transponder linked to vehicle **Controls:** Login form Redirect logic Vehicle management interface Link Transponder modal ###### Business Rules Table 197 – Business Rules – Login & Activate Flow | Rule Name | Description | | --- | --- | | Direct Routing | Users bypass dashboard and are routed directly to Vehicles page | | Session Required | Activation requires authenticated session | | Vehicle Association Required | Transponder must be linked to a vehicle | | Unique Assignment | A transponder can only be linked to one vehicle | ###### Validation and System Responses Table 198 – Website Validations – Login & Activate Flow | Event | Input | Output | | --- | --- | --- | | User logs in successfully | Valid credentials | Redirect to Vehicles page | | System detects activation flow | Login via activation entry | Skip dashboard | | User initiates link transponder | User action | Modal opened | | Submit transponder details | Valid data | Transponder linked | | Invalid transponder data | Incorrect input | Error message displayed | ###### Wireframe(s) Figure 204 – Wireframes – Vehicles Page – With Transponder Actions Figure 205 – Wireframes – Link Transponder Modal ##### Create Account and Activate Flow **Purpose:** Allows new users to create an account and activate a transponder as part of onboarding. **Inputs:** User registration details Vehicle details Transponder details **Outputs:** New account created Vehicle registered Transponder linked **Controls:** Registration forms Vehicle entry step Transponder linking option (toggle or link) Continue actions ###### Business Rules Table 199 – Business Rules – Create Account and Activate Flow | Rule Name | Description | | --- | --- | | Full Onboarding Required | User must complete account creation before activation | | Vehicle Required | At least one vehicle must be added | | Optional Transponder Request | Users may request or link transponder during onboarding | | Sequential Flow | Details → Vehicles → Payment (if applicable) | ###### Validation and System Response Table 200 – Validation and System Response – Create Account and Activate Flow | Event | Input | Output | | --- | --- | --- | | User selects Create Account | Click action | Redirect to onboarding | | Complete registration | Valid input | Account created | | Add vehicle | Vehicle data | Vehicle saved | | Link transponder | Valid transponder data | Transponder linked | | Skip transponder | User choice | Continue onboarding | ###### Wireframe(s) Figure 206 – Wireframes – Onboarding – Vehicles & Plates Step ##### Transponder Linking **Purpose:**** **Allows users to associate a physical transponder device with a specific vehicle within their account. **Inputs:** Transponder serial number / ID Activation code (if required) Vehicle identifier **Outputs:** Transponder linked to vehicle Updated vehicle record **Controls:** Scan option (camera / QR / barcode) – available only on app Manual input fields Continue / Back buttons ###### Business Rules Table 201 – Business Rules – Transponder | Rule Name | Description | | --- | --- | | Valid Device Required | Transponder must exist in backend system | | Activation Code Validation | Activation code must match device | | One-to-One Mapping | One transponder per vehicle | | Reassignment Rules | Existing assignments must follow backend rules | ###### Validation and System Response Table 202 – Validation and System Response – Transponder | Event | Input | Output | | --- | --- | --- | | Open link modal | User action | Modal displayed | | Scan transponder (app only) | Camera input | Data populated | | Enter details manually | User input | Validation applied | | Submit valid data | Valid input | Transponder linked | | Invalid data | Incorrect input | Error displayed | ###### Wireframe(s) Figure 207 – Link Transponder Modal (Scan + Manual Entry) #### Check and Pay Tolls The Check and Pay Tolls feature enables non-registered users to search for, view, and pay outstanding toll transactions without requiring a CTIO account. This functionality provides a guided, step-based experience allowing users to: Identify unpaid tolls associated with a vehicle View a list of toll transactions Select and pay outstanding balances Receive a payment confirmation and receipt The flow is designed as a lightweight, public-access journey that minimizes friction while ensuring accurate toll identification and secure payment processing. ##### Vehicle Details **Purpose**: Allows users to search for unpaid tolls using vehicle identification details. **Inputs****:** Vehicle State Vehicle Plate Number **Outputs****:** Toll search request submitted Navigation to Toll Details step (if results found) No results state (if no tolls found) **Controls****:** Vehicle State dropdown Vehicle Plate Number input View Tolls CTA ###### Business Rules Table 203 – Business Rules – Vehicle Details | Rule Name | Description | | --- | --- | | Date Range Limit | Only tolls from the last 7 days are available | | Mandatory Fields | State and Plate Number are required | | Search Scope | Query is based on ANR (plate recognition) data | | Public Access | No authentication required | ###### Validation and System Responses Table 204 – Website Validations – Vehicle Details | Event | Input | Output | | --- | --- | --- | | Submit search | Missing required fields | Error message displayed | | Submit search | Valid input | System retrieves tolls | | No tolls found | Valid input | Display "No Tolls Found" state | | Tolls found | Valid input | Navigate to Toll Details | ###### Wireframe(s) Figure 208 – Wireframes – Check Unpaid Tolls – Vehicle Details Step Figure 209 – Wireframes – No Tolls Found State ##### Toll Details **Purpose****:** Displays a list of unpaid toll transactions associated with the provided vehicle details and allows users to select which tolls to pay. **Inputs****:** Retrieved toll transactions Vehicle identifier **Outputs****:** Display of toll list Selection of tolls for payment **Controls****:** Toll list table (Date/Time, Amount, Status) Row selection checkboxes Pay Selected CTA Pay All CTA Pagination controls Informational banner (older toll handling) ###### Business Rules Table 205 – Business Rules – Toll Details | Rule Name | Description | | --- | --- | | Multi-Selection | Users can select one or multiple tolls | | Status Display | Toll status must be clearly indicated (e.g. Unpaid) | | Payment Eligibility | Only unpaid tolls can be selected for payment | | Pagination | Required for large result sets | | No Drilldown | No detailed transaction view is available in this flow | | Time Visibility | Only tolls from last 7 days are shown | | Older Toll Handling | Tolls older than 7 days are not displayed and may be invoiced separately | ###### Validation and System Responses Table 206 – Website Validations – Toll Details | Event | Input | Output | | --- | --- | --- | | Load page | Valid data | Display toll list | | Select toll(s) | User input | Selection updated | | Click Pay Selected | Selected toll(s) | Navigate to Payment step | | Click Pay All | All tolls | All eligible tolls selected | | No selection | Attempt to proceed | Error message displayed | ###### Wireframe(s) Figure 210 – Wireframes – Toll Details Table View ##### Payment Details **Purpose**: Captures user information and payment method to process toll payment. **Inputs****:** User personal details (name, address, email) Selected toll(s) Payment method **Outputs****:** Payment request submitted Transaction processed **Controls****:** Personal details form (First Name, Last Name) Address fields (Address, City, State, ZIP, Country) Email input (for receipt delivery) Communication consent checkbox Payment method selection: - Credit/Debit Card - Bank Account (ACH) - PayPal - Google Pay - Apple Pay Payment summary panel Pay Now CTA ###### Business Rules Table 207 – Business Rules – Payment Details | Rule Name | Description | | --- | --- | | Required Fields | Mandatory user and payment fields must be completed | | Payment Methods | Multiple payment options supported | | Total Calculation | Total must reflect selected tolls | | Receipt Delivery | Email required for receipt | | Guest Checkout | No account required to complete payment | ###### Validation and System Responses Table 208 – Website Validations – Payment Details | Event | Input | Output | | --- | --- | --- | | Submit payment | Missing fields | Error message displayed | | Submit payment | Valid input | Payment processing initiated | | Payment success | Valid transaction | Redirect to receipt page | | Payment failure | Error response | Error message displayed | ###### Wireframe(s) Figure 211 – Wireframes – Payment Details Form and Summary Panel ##### Payment Receipt **Purpose****:** Provides confirmation of successful payment and displays receipt details. **Inputs****:** Payment confirmation data Receipt number **Outputs****:** Receipt displayed to user Option to retain or use receipt reference **Controls****: ** Payment confirmation message Receipt number display Informational text Create Account CTA (optional) ###### Business Rules Table 209 – Business Rules – Payment Receipt | Rule Name | Description | | --- | --- | | Receipt Generation | Unique receipt number must be generated | | User Guidance | Users must be advised to save receipt | | Account Upsell | Optional CTA to create account | ###### Validation and System Responses Table 210 – Website Validations – Payment Receipt | Event | Input | Output | | --- | --- | --- | | Payment success | Transaction complete | Receipt displayed | | Receipt generated | Valid payment | Unique ID assigned | ###### Wireframe(s) Figure 212 – Wireframes – Payment Receipt Page ##### No Tolls Found State **Purpose****:** Handles scenarios where no unpaid tolls are identified for the provided vehicle details. **Outputs****: ** Informational message displayed Alternative user actions provided **Controls****: ** Informational message Go Back CTA Create Account CTA ###### Business Rules Table 211 – Business Rules – No Tolls Found | Rule Name | Description | | --- | --- | | Informational Messaging | Users informed about possible delay (e.g. up to 24 hours) | | Alternative Action | Encourage account creation for auto payments | | Retry Option | Users can return and adjust search criteria | ###### Wireframe(s) Figure 213 – Wireframes – No Tolls Found Screen #### Pay a Bill **Purpose:** The Pay a Bill page allows an unregistered user to retrieve a bill using identifying information supplied manually (or scanning QR code with the Mobile app). This entry point supports both payment and provides a link to the dispute paths and acts as the first step for users accessing liabilities from the public website. **Inputs:** Invoice / Notice Number License Plate State License Plate Number ZIP **Outputs:** Retrieval of matching bill record Progression into Pay a Bill flow Validation errors where record matching fails **Controls:** The Pay a Bill page consists of: Title Invoice / Notice Number field License Plate State field License Plate Number field ZIP field Search button Helper link to dispute flow ##### Business Rules Table 212 – Business Rules – Public Bill Retrieval Entry | Rule Name | Description | | --- | --- | | Mandatory Search Inputs | All fields must be completed before search can proceed | | Record Match Requirement | The entered values must match a valid backend bill record before the user can proceed. | | Shared Entry Pattern | The same core identifying information is used for both payment and dispute entry. | | Vehicle-Level Debt Context | Once a valid bill is retrieved, other debts related to the same vehicle may also be shown in subsequent steps. | | Record-Level Details | Full detailed access is granted for all retrieved invoices | ##### Validation and System Responses Table 213 – Website Validation – Public Bill Retrieval Entry | Event | Input | Output | | --- | --- | --- | | User leaves mandatory fields empty | Missing required values | Search disabled or validation errors shown | | User submits invalid details | No backend match / plate mismatch | Error shown; user remains on entry page | | User submits valid details | Matching notice or invoice record | User proceeds to Bill Details | | No outstanding debt | Valid match | "No Outstanding Payments Due" state displayed | ##### Wireframe(s) Figure 214 – Wireframes – Pay a Bill Entry Page #### Pay a Bill Flow **Purpose**: The Pay a Bill flow allows an unregistered user to retrieve a bill, review the current debt for the associated vehicle, and choose how to proceed with payment. **Inputs:** Retrieved bill Related vehicle liabilities User path selection **Outputs:** Display of liabilities Payment pathway selection Progression into payment **Controls:** The Pay a Bill flow includes: Bill Details step Payment Options screen Path choice buttons: - Pay as Guest - Pay Bill & Create Account - Login & Pay Bill ##### Pay a Bill Flow Overview ###### Business Rules Table 214 – Business Rules – Pay a Bill Flow | Rule Name | Description | | --- | --- | | Primary Bill Retrieval | The searched notice or invoice must be presented first in the bill details flow. | | Additional Vehicle Debt Visibility | Other debts associated with the same vehicle may be displayed to the user in the same bill detail step. | | Full Detail Restriction | Additional liabilities shown in the list provide automatic full-detail access | | Multi-Path Payment Flow | Users may continue as guest, create an account and save, or log in with an existing account. | | Dispute Link Availability | A dispute link must be available from the payment journey. | | Liability Types | Includes invoices, notices, tolls | | Unpaid Tolls | Unpaid tolls will display as a summary of all unpaid tolls. User will not be able to see details of individual tolls. | ###### Validation and System Responses Table 215 – Website Validations – Pay a Bill Flow | Event | Input | Output | | --- | --- | --- | | User retrieves valid bill | Matching search criteria | Bill Details step displayed | | Other debts exist for same vehicle | Vehicle-level related liabilities returned | Additional debt table displayed | | User clicks Make a Payment | Guest payment path selected | Guest Payment Details step opened | | User clicks Pay Bill & Create Account | Account creation payment path selected | Create Account flow opened | | User clicks Login & Pay Bill | Existing account path selected | Login modal / authentication flow | ###### Wireframe(s) Figure 215 – Wireframes – Bill Details Step Figure 216 – Wireframes – Bill Details with Additional Vehicle Debts Figure 217 – Wireframes – Payment Options Screen Figure 218 – Wireframes – Sign In Modal ##### Bill Details Step **Purpose:** The Bill Details step displays the searched liability together with any additional debts associated with the same vehicle and allows the user to choose the liabilities to be paid. **Inputs:** Retrieved primary notice / invoice Additional related debts for the same vehicle Selection state Amount totals **Outputs:** Display of selected liabilities Updated pay totals Progression to payment details **Controls:** The Bill Details step consists of: Primary bill table Secondary related debts table, where applicable Selection checkboxes View Notice / View Invoice links Pay Selected button Pay All button Dispute helper link ###### Business Rules Table 216 – Business Rules – Bill Details Step | Rule Name | Description | | --- | --- | | Primary Record Visibility | The record retrieved using the search criteria must be displayed prominently in the first bill table. | | Additional Debt Warning | Where additional debts exist for the same vehicle, the user must be informed that other outstanding bills are present. Banner displayed. | | Selective Payment | Users may choose to pay selected displayed liabilities. | | Pay All | Pay All applies to all displayed eligible liabilities in the bill detail step. | | Liability Types | The bill details experience may contain Safety Notices, invoices, and toll debts. | | Modal Detail View | Invoice/Notice opens in modal, not navigation | ###### Validation and System Responses Table 217 – Website Validations – Bill Details Step | Event | Input | Output | | --- | --- | --- | | Primary bill returned | Bill retrieval result | Primary bill displayed | | Additional vehicle debts returned | Related debt dataset | Additional debts table shown | | User selects additional debts | Checkbox selection | Pay Selected amount recalculated | | User clicks Pay Selected | Valid selected rows | User progresses to payment details | | User clicks Pay All | All displayed liabilities | User progresses to payment details with full amount | ###### Wireframe(s) Figure 219 – Wireframes – Bill Details Step Figure 220 – Wireframes – Bill Details with Additional Vehicle Debts ##### Payment Options **Purpose:** The Payment Options screen is presented after a bill has been successfully retrieved and allows the user to choose how to continue payment. **Inputs:** Retrieved bill context Available continuation paths **Outputs:** Progression to chosen payment path **Controls:** The Payment Options screen consists of: Pay As Guest option Create Account & Save option Login and Pay option ###### Business Rules Table 218 – Business Rules – Payment Options Screen | Rule Name | Description | | --- | --- | | Multiple Continuation Paths | The user must be able to select among guest, account creation, or existing account paths. | | Benefit Messaging | The Create Account & Save option should communicate the benefits of creating an account. | | Existing User Shortcut | Existing users must be able to authenticate and continue without creating a new account. | | Create Account and Pay | In cases where only STEP notice is being paid, this section will have a variation removing the reference to saving | ###### Validation and System Responses Table 219 – Website Validations – Payment Options Screen | Event | Input | Output | | --- | --- | --- | | User selects Pay As Guest | Path selection | Guest payment path opened | | User selects Create Account & Save | Path selection | Create Account & Save path opened | | User selects Login & Pay Bill | Path selection | Authentication flow opened | ###### Wireframe(s) Figure 221 – Wireframes – Payment Options Screen ##### Guest Payment Details **Purpose:** The Guest Payment Details step allows an unregistered user to make payment for one or more selected liabilities without creating an account. **Inputs:** Recipient email address Notice / billing address Billing address preference Payment method selection Amount summary **Outputs:** Payment submission Payment receipt generation **Controls:** The Guest Payment Details step consists of: Email field Notice address summary Billing address controls Payment methods section Amount summary panel Pay Now button ###### Business Rules Table 220 – Business Rules – Guest Payment Details | Rule Name | Description | | --- | --- | | Email Required for Receipt | A valid email address is required to send the payment receipt | | Address Handling | Billing address may default to the notice address where the user confirms they are the same. | | Payment Method Selection | Users must select and complete a supported payment method before submission. | | Amount Summary | The summary panel must display the liabilities being paid and the total due today. | | Guest Payment Completion | A successful payment creates a receipt without requiring account creation. | ###### Validation and System Responses Table 221 – Website Validations – Guest Payment Details | Event | Input | Output | | --- | --- | --- | | User leaves required email empty | Missing email | Pay Now blocked or validation error shown | | User submits invalid payment details | Invalid payment method details | Validation / PSP error shown | | User submits valid payment | Valid email and payment details | Payment processed; user routed to receipt screen | | Payment fails | Backend / PSP failure | Error shown; user remains on payment step | ###### Wireframe(s) Figure 222 – Wireframes – Guest Payment Details Step Figure 223 – Wireframes – Guest Payment Receipt ##### Create Account & Save **Purpose:** The Create Account & Save path allows an unregistered user to pay current liabilities while simultaneously creating an account so that future invoices and notices may be managed through the authenticated portal. **Inputs:** Personal details Verify email Password Address details Notification preferences Vehicle details Payment method details Selected liabilities and payment totals **Outputs:** New account creation Payment submission Progression into authenticated account experience after successful completion **Controls:** The Create Account & Save path includes: Account Details step Address form (with lookup) Password validation Notification preferences Payment Details step Back / Continue actions Pay Now action ###### Business Rules Table 222 – Business Rules – Create Account & Save | Rule Name | Description | | --- | --- | | Account Creation During Payment | Users may create an account as part of the bill payment process. | | Future Savings Benefit | The flow should communicate that account creation helps the user manage future invoices, notices, and vehicles. | | Required Registration Data | Mandatory identity, account, and address fields must be completed before account creation can proceed. | | Payment and Registration Coupling | Payment completion and account creation are linked as part of the same guided flow. | | Vehicle Association | The vehicle connected to the current bill may be associated to the new account subject to backend rules. | ###### Validation and System Responses Table 223 – Website Validations – Create Account & Save | Event | Input | Output | | --- | --- | --- | | User selects Create Account & Save | Path selection | Account creation step opened | | User leaves required account fields incomplete | Missing mandatory values | Continue blocked; validation errors shown | | User submits valid account details | Valid registration dataset | User progresses to payment details | | User submits valid payment | Valid payment data | Account created and payment completed | | Backend rejects account creation or payment | Validation/processing error | Error shown; user remains in flow | ###### Wireframe(s) Figure 224 – Wireframes – Create Account & Save – Account Details Step Figure 225 – Wireframes – Create Account & Save – Payment Details Step ##### Logged-In Pay Bill **Purpose:** The Logged-In Pay Bill path allows an existing registered user to authenticate during the public bill payment journey and continue payment using their account-linked details. This path is used where the user chooses to sign in after retrieving a bill through the public Pay a Bill journey. Once authenticated, the system performs an automatic lookup to determine whether the vehicle associated with the retrieved invoice / notice is already linked to the user’s existing account. Depending on the result of that lookup, one of two scenarios applies: The invoice / notice vehicle is already linked to the same digital account, in which case the user should be routed to the existing account payment handling flow rather than adding the vehicle again. The invoice / notice vehicle is not linked to the user’s account, in which case the user may continue through the Logged-In Pay Bill flow and associate that vehicle with their account as part of the journey. **Inputs:** Existing user credentials Retrieved bill details Account lookup result Vehicle linkage state Invoice / notice vehicle details User acknowledgement to associate the vehicle to the account Temporary plate status, where applicable Temporary access / rental status, where applicable Account address / billing address Stored or available payment methods **Outputs:** Successful authentication Vehicle review and optional association acknowledgement Payment submission using logged-in account context Payment confirmation and receipt linked to the account **Controls:** The Logged-In Pay Bill flow includes: Sign In modal Vehicle Details step Payment Details step Back / Continue actions Pay Now action ###### Business Rules Table 224 – Business Rules – Logged-In Pay Bill | Rule Name | Description | | --- | --- | | Authentication Required | Existing users must authenticate before entering the logged-in bill payment flow. | | Automatic Vehicle Lookup | After successful login, the system must automatically evaluate whether the vehicle related to the retrieved invoice / notice is already linked to the authenticated account | | Same Account Vehicle Handling | If the invoice / notice vehicle is already connected to the same digital account, the user must not be asked to add it again and should instead be routed to the relevant account payment handling flow | | Unlinked Vehicle Handling | If the invoice / notice vehicle is not linked to the authenticated account, the user may continue through Logged-In Pay Bill and associate that vehicle to the account | | Vehicle Review Step | Where the vehicle tied to the bill is not already linked to the account, the user must be shown the vehicle details before continuing. | | Vehicle Association Acknowledgement | If the vehicle is to be associated to the account as part of the payment flow, the user must explicitly acknowledge that action. | | Account Address Reuse | Billing address may default to the account address where confirmed by the user. | | Account Payment Context | Logged-in users may use available payment methods associated with their account or supported payment options in the logged-in flow. | | Temporary Plate Support | Where applicable, the user must be able to identify that the vehicle has a temporary license plate and provide the relevant expiry date | | Temporary Access Vehicle Support | Where applicable, the user must be able to identify that the vehicle is only temporarily accessed (for example rental / borrowed vehicle) and provide the access start and end dates / times | ###### Validation and System Responses Table 225 – Website Validations – Logged-In Pay Bill | Event | Input | Output | | --- | --- | --- | | User opens sign-in modal | Login action | Sign In modal displayed | | User submits invalid credentials | Incorrect login details | Authentication error shown | | User submits valid credentials | Valid login | Logged-in bill payment flow opened | | Vehicle already linked to same account | Positive match | User is redirected to the existing account payment handling path; Logged-In Pay Bill add-vehicle step is bypassed | | Vehicle not linked to account | No match | Vehicle Details step displayed | | User completes required vehicle step data | Valid inputs + acknowledgement | Continue enabled | | Payment Details step loads | Valid logged-in context | Account address and payment options displayed | | User submits invalid payment details | Invalid method / PSP error | Validation / PSP error shown | | User submits valid payment | Valid payment details and totals | Payment processed successfully | | Payment succeeds | Successful transaction | Payment Receipt step displayed and receipt linked to account | ###### Wireframe(s) Figure 226 – Wireframes – Sign In Modal Figure 227 – Wireframes – Logged-In Vehicle Details Step Figure 228 – Wireframes – Logged-In Payment Details Step Figure 229 – Wireframes – Logged-In Receipt Details #### Dispute a Bill Flow **Purpose:** The Dispute a Bill flow allows a public user to dispute a notice or invoice without entering through the authenticated portal. **Inputs:** Notice / invoice number License plate state License plate number One or more notice numbers Dispute reason Comments Evidence files Personal details Address details Company details, where applicable Legal acknowledgement checkbox **Outputs:** Dispute case submission Confirmation of successful dispute registration Dynamic display of additional required information fields based on selected dispute reason, as defined and retrieved from CBOS **Controls:** The Dispute a Bill flow includes: Dispute entry page Dispute Details step Add Additional Notice action Personal Details step Summary step Submit Disputes button Confirmation page ##### Business Rules Table 226 – Business Rules – Dispute a Bill Flow | Rule Name | Description | | --- | --- | | Initial Record Lookup | The user must provide identifying bill and vehicle information before entering the dispute workflow. | | Multi-Notice Support | The user may add additional notices to the same dispute flow where supported by the UI. | | Reason Selection Required | Each disputed notice requires a dispute reason selected from a valid predefined list. | | Evidence Upload Support | Users may upload supporting evidence to support the dispute. | | Personal Details Required | The dispute flow requires the user to provide personal contact details and address information. | | Company Details Optional | Company details are completed only when the user is disputing on behalf of a business. | | Legal Acknowledgement Required | The user must acknowledge the legal statement before dispute submission is enabled. | | Confirmation Screen | A successful dispute submission must end with a confirmation message. | ##### Validation and System Responses Table 227 – Website Validations – Dispute a Bill Flow | Event | Input | Output | | --- | --- | --- | | User submits invalid lookup data | No backend match / incorrect plate details | Error shown; user remains on entry page | | User submits valid lookup data | Matching record | Dispute workflow opened | | User leaves dispute reason empty | Missing reason | Validation error shown | | User uploads evidence | Valid file upload | Evidence attached to dispute record | | User adds additional notice | Valid additional notice details | Additional notice appended to dispute | | User leaves required personal details empty | Missing mandatory details | Continue blocked; validation errors shown | | User reaches summary without legal acknowledgement | Checkbox not selected | Submit blocked | | User submits valid dispute | Complete valid dataset | Dispute created; confirmation page shown | ##### Wireframe(s) Figure 230 – Wireframes – Dispute Entry Page Figure 231 – Wireframes – Dispute Details Step Figure 232 – Wireframes – Add Additional Notice Modal Figure 233 – Wireframes – Personal Details Step Figure 234 – Wireframes – Summary Step Figure 235 – Wireframes – Dispute Confirmation Screen ## External Interfaces (APIs, Third-Party Integrations) The CTIO platform is designed to integrate seamlessly with a range of external systems and third-party services to support core functionality, enhance user experience, and enable operational efficiency across the tolling ecosystem. These integrations leverage secure APIs to enable real-time communication, data exchange, and interoperability between the website, backend tolling systems (e.g. CBOS), and external service providers. All integrations are implemented in accordance with industry standards for security, performance, and regulatory compliance. This section outlines the key external interfaces supported by the platform and their role within the overall system architecture. ### Chatbot and Web Chat The platform integrates with a third-party ChatBOT and WebChat solution (Amazon Connect) to provide real-time customer support and engagement capabilities. This is described in more detail in 3.4 Conversational AI BOT (Amazon Connect) This integration enables users to: Receive instant responses to frequently asked questions Navigate the platform more efficiently Escalate queries to live agents when required The ChatBOT service manages conversational flows, session handling, and interaction logging, while the WebChat interface ensures accessibility across desktop and mobile devices. **Integration Type:** Embedded frontend widget **Key Capabilities:** Real-time chat interaction Session persistence Context-aware responses Live agent escalation #### Business Rules ChatBOT must be accessible across all key pages Users must be able to escalate to live agent where available Integration must not impact page performance significantly #### Security and Compliance Secure API communication (HTTPS) Session handling aligned with platform authentication standards Data handling compliant with privacy regulations (GDPR / CCPA where applicable) ### Language and Browser Support **Description****: **The platform supports multilingual functionality and cross-browser compatibility to ensure accessibility for a diverse user base. **Language Support:** English (United States) Spanish (Mexico) Language selection is user-controlled via a language toggle, with all content dynamically loaded through Kontent.ai CMS. **Browser Support** Supported browsers include the latest stable version and two previous major versions of: Google Chrome Mozilla Firefox Microsoft Edge Apple Safari **Key Capabilities:** Dynamic content localization via CMS Persistent language selection (via cookies/session) Responsive UI across device types #### Business Rules Language selection must persist across sessions (where possible) All CMS-managed content must support localization Unsupported browsers must still provide degraded but usable experience Platform must be responsive across desktop, tablet, and mobile ### Payment Processing Integration The platform integrates with **Global Payments**, a secure third-party payment gateway, to enable financial transactions for toll payments, account top-ups, and invoice settlements. Payment card data is collected via **gateway-hosted secure input fields (Hosted Fields)** embedded within the app, ensuring a seamless user experience while maintaining compliance with **PCI DSS** standards. **Supported Payment Methods:** Credit cards Debit cards Digital wallets **Key Capabilities:** Real-time transaction processing Payment status updates Receipt generation Refund processing Fraud detection mechanisms Multi-currency support #### Business Rules All payment transactions will comply with PCI DSS standards Payment card data will never pass through the platform backend; only secure tokens are stored and processed. Payment status must be reflected in real-time in user accounts. Failed transactions will return clear and actionable error messages to users. Payment sessions will expire after a predefined period to prevent stale transactions. Frontend will implement HTTPS, Content Security Policy, Cross-Site Scripting (XSS) protection to maintain security of the hosted fields. #### Security and Compliance **Key Security Measures:** **PCI DSS Compliance:** All payment transactions will comply with PCI DSS standards **Tokenization:** Payment card data will never pass through the platform backend; only secure payment tokens provided by Global Payments will be stored and processed. **Secure Communication:** All API calls and data exchanges will use HTTPS to ensure end-to-end encryption. **Fraud Detection: **Integration with the gateway’s fraud detection mechanisms will help identify and prevent unauthorized or suspicious transactions. **Payment Session Management: **Payment sessions will expire after a predefined period to prevent stale or incomplete transactions. **Frontend Security Controls: **The frontend will enforce: - Content Security Policy (CSP) to restrict allowed script and frame sources to trusted domains. - Cross-Site Scripting (XSS) protection to prevent script injection attacks. - Secure script loading and monitoring to ensure integrity of gateway-hosted fields. **Real-Time Status Updates:** Payment status will be reflected in real-time in user accounts. **Error Handling: **Failed transactions will return clear, actionable error messages to users. ### Social Media **Description****:** The platform integrates with third-party social media services to support content sharing, audience engagement, and promotion of official CTIO social channels. These integrations enable: Social media content sharing Linking to official CTIO social media profiles Display of social media widgets or feeds (where applicable) Promotion of campaigns and announcements across social platforms **Integration Type:** API-based integrations Embedded scripts/widgets **Key Capabilities:** Share website content to supported social media platforms Link users to official CTIO social media channels Support social engagement through embedded social components #### Business Rules Social media integrations must only display approved CTIO social channels Social sharing functionality must be available on supported content types where configured User consent must be obtained before loading third-party social media tracking scripts Embedded social widgets must not negatively impact website performance #### Security and Compliance Cookie consent management required Compliance with privacy regulations Secure handling of user data ### CoTrip **Description:** The platform integrates with official transportation information services to provide users with access to real-time road conditions, safety alerts, and operational updates. These services are particularly relevant for toll road users, enabling them to assess driving conditions before or during travel. **Integrated Services****:** CoTrip (Colorado Department of Transportation) **Integration Type:** External URL redirection (no API integration) **Key Capabilities:** Road condition monitoring Weather and hazard alerts Road closures and incident reporting Snowplow tracking and winter driving conditions Chain law notifications #### Business Rules CoTrip links must open in a new browser tab Platform must clearly indicate that users are leaving the CTIO website No direct data exchange occurs between CTIO and CoTrip Information accuracy is owned by the Colorado DOT ### Google Maps & Waze/Carpool **Description**: The platform provides integration points to external transport and mobility services primarily via URL-based redirection rather than deep API integrations. These integrations enhance user journey planning and access to related services. **Integrated Services:** Google Maps (URL linking) Waze / Carpool (URL linking) **Integration Type:** External URL redirection (no API integration) **Key Capabilities:** Route planning and navigation Real-time traffic updates Carpool and ride-sharing support (Waze) #### Business Rules Navigation links must open in a new browser tab No user-sensitive data must be passed to external services CTIO does not control routing logic or data accuracy Links must be maintained and periodically validated ### Analytics and Logging The platform leverages **Google Analytics (GA4)** and **Firebase** to provide comprehensive analytics, conversion tracking, and real-time monitoring across **mobile apps (iOS/Android) and web**. GA4 is used to track user interactions, conversion rates, and engagement on all platforms, while Firebase provides real-time exception tracking, crash reporting, and performance monitoring for mobile apps. **Integration Type:** **Mobile Apps: **Firebase SDK integration for both analytics (GA4) and real-time monitoring. **Web App: **GA4 integration via Global Site Tag (gtag.js) or Google Tag Manager (GTM) for analytics and conversion tracking. #### Google Analytics (GA4) – Conversion & Usage Analytics **Purpose:** The website will support analytics measurement, collection, analysis, and reporting capabilities to enable monitoring of user engagement, website performance, and journey effectiveness. Analytics implementation shall be aligned with modern event-based tracking principles using Google Analytics 4 (GA4). The analytics solution shall provide visibility into how users interact with the website across both public-facing and authenticated areas of the platform. Tracked analytics data shall support operational reporting, business insights, usability optimization, and market research. The analytics implementation shall include measurement of: Number of screen or page views Number of user interactions captured as events New versus returning visitors Bounce rate Abandonment rates for defined user journeys **Analytics Terminology Alignment** For clarity and alignment with current analytics standards, the following terminology applies: **Events (formerly “Hits”)** Legacy analytics platforms referred to tracked interactions as “hits.” Within GA4, all user interactions are recorded as ‘events’. **Examples include:** Page view events Button click events Form submission events Authentication events Payment initiation events Payment completion events **Page Views / Screen Views** The analytics solution shall capture views across website pages and application screens to support navigation analysis and usage reporting. **New vs Returning Visitors** Analytics reporting shall distinguish between: First-time visitors Returning visitors This distinction shall support understanding of repeat engagement and audience retention. **Bounce Rate** Bounce Rate shall be measured using GA4 methodology. Within GA4, Bounce Rate represents the percentage of sessions that are not considered engaged sessions. An engaged session is defined as one that meets at least one of the following conditions: Session duration exceeds 10 seconds A conversion event occurs Two or more pages or screen views occur **Abandonment Rate** Abandonment Rate shall measure drop-off within defined user journeys. #### Firebase – Exception Tracking and Real-Time Monitoring (Mobile Apps Only) Provide real-time monitoring of application performance, exceptions, and crashes in **mobile apps**. **Key Capabilities:** Crash reporting and non-fatal exception logging via Crashlytics Real-time debugging with DebugView Performance monitoring: startup time, screen rendering, network requests Alerting and notifications for critical issues #### Business Rules All analytics and monitoring data must comply with privacy regulations (e.g., GDPR). Conversion metrics captured via GA4 must accurately reflect successful transactions in real time or near real time across all platforms. Exceptions and crash logs captured via Firebase must include context (app version, device, OS) for troubleshooting. Analytics and monitoring events must be instrumented consistently across mobile and web platforms for reliable reporting. GA4 property must unify mobile (Firebase) and web data to allow cross-platform KPIs and conversion analysis. ## Content Management **Purpose:** This section defines how the Kontent.ai CMS is used within the CTIO platform to manage, deliver, and govern public-facing content. The CMS serves as the primary source of truth for all publicly visible, non-transactional content, enabling Content Managers to create and maintain content independently of development teams, while ensuring a clear separation between content and application logic. **Scope****:**** **The CMS is used for managing publicly accessible content, including but not limited to: Homepage content Blog posts and articles News and announcements Marketing and informational pages Static labels, helper text, and informational UI content (where applicable) The CMS is not used for: Business logic User account functionality Transactions and payments Secure or authenticated portal areas (e.g. dashboards) ### Content Ownership & Responsibilities **Content Managers** Creating and updating content entries Managing media assets (images, videos, etc.) Controlling which content is displayed on specific pages Managing content lifecycle (draft, preview, publish) Maintaining localized content **Developers** Defining content models (schemas) within the CMS Implementing frontend rendering logic Mapping CMS data to UI components Defining validations and constraints ### System Boundaries The CMS is strictly limited to public-facing content. All application logic, secure data, and transactional functionality are handled outside of the CMS within the application and backend systems. **Key Principles** Clear separation of concerns Improved system security Better performance and maintainability Reduced risk of unintended changes to application behavior ### Content Modeling & Structure Content structure within the CMS is defined by developers using a modular and reusable approach. **Key Characteristics****:** Structured content types (e.g. pages, components, reusable blocks) Clearly defined fields with validation rules Field-level guidance for Content Managers Reusable content components to support flexible page composition Content Managers interact only with predefined structures and do not modify schemas. **Content Flexibility** The system is designed to provide flexibility while maintaining control. **Content Managers can****:** Populate structured content models Select and organize content (e.g. homepage featured items) Manage content visibility **Limitations:** CMS does not control application logic Layout behavior is defined by frontend implementation Only predefined content structures are supported ### Rendering & Delivery Content is retrieved from the CMS via API and rendered dynamically in the frontend application. **Key ****Behavior****:** Frontend determines presentation based on content type and structure Content is dynamically injected into predefined UI components Where CMS usage is not practical, content may be hardcoded in the application ### Content Lifecycle (Draft, Preview, Publish) The CMS supports a structured content lifecycle: **Draft** - Content is created and edited without affecting the live site **Preview** - Content can be previewed within the application context before publishing - Enables validation of layout, formatting, and accuracy **Published** - Content becomes publicly visible once approved **Benefits** Controlled content releases Reduced risk of publishing errors Improved collaboration between teams ### Localization Strategy The platform supports multi-language content delivery using CMS-native localization capabilities. **Supported Locales****:** English (United States) Spanish (Mexico) **Behavior****:** Content Managers create and maintain localized content versions Frontend resolves content based on user-selected or inferred language All localized content is centrally managed within the CMS ### Media Asset Management All multimedia assets are centrally managed within the CMS. **Capabilities****:** Storage of images, videos, and documents Reuse of assets across multiple content entries CDN-based delivery for optimized performance **Benefits****:** Reduced duplication Improved asset governance Faster global content delivery ### Caching & Content Freshness To ensure optimal performance, content may be cached at multiple levels: API level Server level CDN level **Behavior****:** CMS updates may be reflected immediately or with delay depending on cache policies Cache invalidation and revalidation strategies control content freshness **Trade-off****:** Balances performance with real-time content updates ### Content Classification The platform distinguishes between two types of content: CMS-Managed Content - Dynamic and editable - Managed by Content Managers - Delivered via CMS APIs Statically Defined Content - Embedded within application code - Managed by developers only - Used when CMS integration is not practical or required ### CMS Managed Content Updates The website shall support content management capabilities through a headless Content Management System (CMS), enabling authorized content editors to create, update, publish, and manage website content without requiring development intervention. This may include, but is not limited to: General informational pages Program or policy content Contact information FAQs News or announcement content Homepage promotional sections Banner messaging Supporting text and imagery The CMS will provide a structured authoring environment where content editors can manage website information through reusable content models and predefined page components. The following section provides an illustrative example of how static website content may be managed within the CMS. ***Note:** The screenshots included within this section are illustrative examples based on a comparable CMS implementation and are intended to demonstrate the expected content management workflow. #### Access Content Library Authorized users access the CMS Content area where all website pages and content items are displayed. The content library provides: Centralized access to all content items Filtering by content type, workflow status, contributor, or publication state Search functionality for locating existing content quickly Visibility into content lifecycle and publishing status This screen enables editors to locate existing pages or begin creation of new website content. Figure 236 – CMS Content Library View #### Create New Content Item Editors may create new website content by selecting Create New. A modal allows selection of a predefined content type. Content types define the structure and available fields presented to editors. Examples may include: General Page News Article FAQ Entry Hero Section Rich Text Content Promotional Banner Call-to-Action Component Figure 237 – Create Content Item Modal #### Configure Page Metadata After content creation, editors define metadata associated with the page. Metadata typically includes: Page URL slug Page title SEO metadata Internal content name Figure 238 – Metadata Configuration Screen #### Build Page Content Using Components Once metadata is configured, editors move to the Content tab to assemble page sections. Pages are built using reusable modular components. This modular approach allows editors to create pages without modifying code. Examples of reusable components include: Hero Section Rich Text Block Image + Text Section CTA Banner FAQ Component Card Grid Promotional Section Embedded Media Figure 239 – Content Component Builder # Customer Satisfaction Surveys ## Integration Architecture Proponisi serves as the survey platform for CTIO customer satisfaction measurement. The integration between Proponisi and the Emovis Touch application operates through four distinct mechanisms based on channel requirements: **Phone/IVR Surveys (Realtime ****–**** Proponisi ****Q****ueries Amazon Connect API): **At call completion, the customer is transferred via PSTN to a Proponisi survey DID. Amazon Connect generates a unique Survey ID and passes it to Proponisi upon connection. Proponisi then makes an API callback to Amazon Connect to retrieve the interaction metadata (Agent ID, Contact ID, call type, language) using the Survey ID. Customer begins taking survey while the metadata call is occurring. **Chat Surveys (Realtime ****–**** CBOS ****C****alls Proponisi API): **At chat session close, static chat URL is modified to include Chat Session ID and Bot/Agent ID. The survey link is displayed directly in the chat closing message for immediate customer access. **Batch CBOS Surveys (Email ****D****elivery): **For email, web logged-in activity, app logged-in activity, and case management interactions, CBOS records customer interactions in an audit log. A batch file process extracts interaction records and Proponisi sends survey invitations via email. **On Demand Surveys (Static ****L****inks and API ****L****inks): **Static survey links are available within the web portal and mobile app menu structures for general feedback. For payment completion scenarios, CBOS calls the Proponisi API to generate a unique survey link with transaction metadata, which displays on the confirmation screen. **Walk-In Center (WIC) Surveys (Multiple ****M****ethods)****:** WIC customers are surveyed through a combination of mechanisms tailored to the interaction type. Counter-served customers are surveyed via the Batch CBOS process, where the audit log captures the interaction and Proponisi sends an email invitation. Self-serve portal and kiosk users access surveys through static QR codes or on-screen links displayed at the kiosk, or through the Batch CBOS process for logged-in account activity. Pre-printed barcoded paper surveys are also available for customers who prefer this method; completed forms are deposited in a secure mailbox and manually entered into Proponisi by WIC staff. Proponisi returns survey response data to Emovis through a results feed, enabling integration with Power BI for business intelligence reporting. ## Survey Forms and Delivery Methods The following table summarizes all survey forms, their delivery mechanisms, and integration approach. Table 228 – Survey Form Summary | Survey Form | Mechanism | Realtime/Batch | Integration Type | | --- | --- | --- | --- | | Phone Bot Only | Post call - stay on line | Realtime | Proponisi queries Amazon API | | Phone Self Service | Post call - stay on line | Realtime | Proponisi queries Amazon API | | Phone CSR | Post call - stay on line | Realtime | Proponisi queries Amazon API | | Webchatbot Only | End of Chat Link | Realtime | CBOS calls Proponisi API | | Webchat CSR | End of Chat Link | Realtime | CBOS calls Proponisi API | | Email | Email Survey with link | Batch CBOS | Batch file to Proponisi | | Web Logged in | Web Activity - Email | Batch CBOS | Batch file to Proponisi | | App Logged in | App Activity - Email | Batch CBOS | Batch file to Proponisi | | Case Management | Email Survey with link | Batch CBOS | Batch file to Proponisi | | Web General | Generic Link | On Demand | Static link | | App General | Generic Link | On Demand | Static link | | Web Payment | End of Payment Journey | On Demand | CBOS calls Proponisi API | | App Payment | End of Payment Journey | On Demand | CBOS calls Proponisi API | | Walk-In Center – Counter Served | CBOS Audit Log trigger – Email Survey with Link | Batch CBOS | Batch file to Proponisi | | Walk-In Center – Self Serve Portal | QR Code / On-screen Link | On Demand | Static link | | Walk-In Center – Paper | Pre-printed paper survey – manual input | Batch (Manual) | Manual entry to Proponisi | | Kiosks | To be determined once Lightning WS determines final approach | On Demand/ Batch CBOS/ Realtime | Pending decision on final Kiosk Design | ## Channel-Specific Implementation The survey forms and questions provided in this section are for illustrative purposes only to demonstrate the features and functionality of the survey tool. The specific CTIO/COMBO questions and forms are provided and maintained in Appendix 5.7, Customer Satisfaction Survey Forms and Questions by Channel. ### Phone/IVR Surveys (Phone Bot-Only, Phone Self-Service, Phone CSR) At call completion, the customer is transferred to the survey via PSTN: Amazon Connect generates a unique Survey ID and stores the interaction metadata (Agent/Bot ID, Contact ID, call type, language) Call transfers via PSTN to a Proponisi Survey DID (dedicated DIDs per survey type: Bot, Self-Help IVR, Agent) Amazon Connect passes the Survey ID to Proponisi upon connection Proponisi makes an API callback to Amazon Connect to retrieve metadata by Survey ID Customer completes IVR survey; response is stored in Proponisi linked to the interaction metadata No enforced time limit on survey responses as per stated 7.22.10; inactivity prompts detect abandoned sessions without rushing active respondents **Phone Bot****-****Only Example Survey Questions** Q1: "How satisfied were you with the help provided by our virtual assistant today? On a scale of 1 to 5, where 1 is very dissatisfied and 5 is very satisfied." Q2: "Was our virtual assistant able to answer your question or complete your request? Press 1 for yes, 2 for no, or 3 for partially." Q3: "How easy was it to communicate with our virtual assistant and get the information you needed? On a scale of 1 to 5, where 1 is very difficult and 5 is very easy." Figure 244 – Phone Bot Only Survey Flow **Phone Self****-****Service Example ****Survey ****Questions** Q1: "How satisfied were you with your experience using our automated phone system today? On a scale of 1 to 5, where 1 is very dissatisfied and 5 is very satisfied." Q2: "Were you able to complete what you called in to do? Press 1 for yes, 2 for no, or 3 for partially." Q3: "How easy was it to find what you needed in our phone menu? On a scale of 1 to 5, where 1 is very difficult and 5 is very easy." Figure 245 – Phone Self Service Survey Flow **Phone CSR Example Survey Questions**** ** Q1: "How satisfied were you with the service you received from our representative today? On a scale of 1 to 5, where 1 is very dissatisfied and 5 is very satisfied." Q2: "Was the reason for your call fully resolved today? Press 1 for yes, 2 for no, or 3 for partially." Q3: "How easy did our representative make it for you to get the help you needed? On a scale of 1 to 5, where 1 is very difficult and 5 is very easy." Figure 246 – Phone CSR Survey Flow ### Web Chat Surveys (Web Chatbot-Only, Web Chat CSR) At chat session close, CBOS requests a unique survey link from Proponisi: Chat interaction completes (bot-only resolution or agent-assisted) CBOS takes static chat URL and modifies it to include Chat Session ID and Bot/Agent ID Survey link is displayed in the chat closing message Customer clicks link and completes web survey; response is stored in Proponisi linked to the interaction metadata Figure 247 – Web Chatbot-Only Example Survey UI Figure 248 – Web Chatbot Survey Flow Figure 249 – Web Chat CSR Example Survey UI Web Chat CSR Survey with Conditional Logic POC: https://survey.tpcdm.com/9FA0E3954D78CC2D Figure 250 – Web Chat CSR Survey Flow ### Email Surveys For customer interactions via the email channel, survey invitations are sent via batch process: Email interaction is recorded in CBOS audit log Batch file process extracts email interaction records from CBOS Proponisi sends survey invitation via email Customer completes survey; response is stored in Proponisi linked to the interaction metadata Figure 251 – Email Example Survey UI Figure 252 – Email Survey Flow ### Web Portal Surveys (Web General, Web Logged-In, Web Payment) **Web General: **A static survey link is available in the portal menu for general feedback independent of any specific transaction. **Web Logged****-I****n: **For logged-in web portal activity, survey invitations are sent via batch process: Activity is recorded in CBOS audit log with web portal identifier Batch file process extracts records from CBOS Proponisi sends survey invitation via email Customer completes survey; response is stored in Proponisi linked to the interaction metadata **Web Payment: **At payment completion, CBOS requests a unique survey link from Proponisi: Customer completes payment transaction (success or failure) CBOS calls Proponisi API with transaction metadata Proponisi returns a unique survey URL Survey link displays on payment confirmation screen Customer clicks link and completes web survey; response is stored in Proponisi linked to the transaction metadata Figure 253 – Web General Example Survey UI Figure 254 – Web General Survey Flow Figure 255 – Web Logged-In Example Survey UI Figure 256 – Web Logged-In Survey Flow Figure 257 – Web Payment Example Survey UI Figure 258 – Web Payment Survey Flow ### Mobile Application Surveys (App General, App Logged-In, App Payment) **App General: **A static survey link is available in the app menu for general feedback independent of any specific transaction. **App Logged****-I****n: **For logged-in mobile app activity, survey invitations are sent via batch process: Activity is recorded in CBOS audit log with app-specific identifier Batch file process extracts records from CBOS Proponisi sends survey invitation via email Customer completes survey; response is stored in Proponisi linked to the interaction metadata **App Payment: **At payment completion, CBOS requests a unique survey link from Proponisi: Customer completes payment transaction (success or failure) CBOS calls Proponisi API with transaction metadata Proponisi returns a unique survey URL Survey link displays on payment confirmation screen Customer clicks link and completes web survey; response is stored in Proponisi linked to the transaction metadata Figure 259 – Mobile App General Example Survey UI Figure 260 – Mobile App General Survey Flow Figure 261 – Mobile App Logged-In Example Survey UI Figure 262 – Mobile App Logged-In Survey Flow Figure 263 – Mobile App Payment Example Survey UI Figure 264 – Mobile App Payment Survey Flow ### Case Management Surveys When a case is closed in SAP, survey invitations are sent via batch process: Case closure is recorded in CBOS audit log with case identifier Batch file process extracts case closure records from CBOS Proponisi sends survey invitation via email Customer completes survey; response is stored in Proponisi linked to the case metadata Figure 265 – Case Management Example Survey UI Figure 266 – Case Management Survey Flow ### Walk-In Center Surveys **Walk****-****In Center Surveys (Counter****-****Served, Self****-****Serve Portal, Paper)** The Walk-In Center (WIC) uses a multi-layered approach to survey collection, ensuring coverage across all customer interaction types within the facility. **Counter Served (CBOS Audit Log Trigger): **For customers serviced by counter staff, the survey is triggered via the CBOS Audit Log and delivered by email invitation: Customer is served at the counter; staff follow an SOP to confirm customer opt-in at point of service. CBOS identifies the interaction as a WIC-serviced transaction using a WIC channel indicator, counter/terminal identifier, or agent workstation login associated with a WIC location (approach to be confirmed with the CBOS team). CBOS Audit Log entry is captured with WIC-specific identifiers. Batch file is extracted from CBOS and transmitted to Proponisi. Proponisi sends a survey invitation via email to the customer. Customer clicks the link and completes the survey; response is stored in Proponisi linked to the interaction metadata for closed-loop reporting. Figure 267 – Walk-In Center Example Survey UI Figure 268 – WIC Counter-Served Survey Flow **S****elf****-****Serve Portal: **For customers who access online portals available within the WIC facility: A QR code is displayed at each self-serve portal kiosk, and a survey link is accessible directly on the on-screen device. The customer scans the QR code or clicks the on-screen link and completes the survey directly via static link — no batch processing is required. If the customer accesses their online account through the portal, they automatically follow the standard Website or App survey process (batch CBOS file trigger or CBOS API call, depending on the activity type) **Generic QR Code (Facility-Wide):** A generic QR code is displayed throughout the WIC and is available to any customer at any time, independent of whether they are participating in a CBOS-triggered survey. Customers scan the code and complete the survey directly via static link. Figure 269 – WIC Self-Serve Portal Survey Flow **Paper Survey: **Pre-printed paper surveys are available within the WIC for customers who prefer or require this method: Completed surveys are placed by the customer into a secure mailbox within the WIC facility. WIC staff collect surveys from the mailbox per an agreed SOP and manually enter responses into Proponisi. Paper responses may be anonymous and may have limited traceability back to a specific interaction; however, all survey questions are consistent with the digital survey form. Manual entry into Proponisi ensures all survey data — regardless of collection method — is consolidated in a single location for reporting and trend analysis. Figure 270 – WIC Paper Survey Flow ## Survey Offer Strategy and Frequency Controls Surveys are offered to all customers at interaction completion. The 20% figure referenced in requirements represents the anticipated completion rate, not a limit on survey offers. **Digital Survey Frequency: **For surveys delivered via email invitation (Email, Web Logged in, App Logged in, Case Management), authorized users configure the minimum number of days before the same customer receives another survey invitation. Proponisi enforces this cool-off period across all email-delivered survey types. **IVR Survey Frequency: **No system-enforced frequency limit applies to IVR surveys. Customers receive a survey offer at the end of each call and decide in real-time whether to participate. **Opt-Out Handling:** For email-delivered surveys (Email, Web Logged-in, App Logged-in, Case Management), customers are opted-in by default. Each email invitation includes an opt-out option; when exercised, the preference is recorded in CBOS. Proponisi receives opt-out updates from CBOS through a daily synchronization process and maintains local opt-out records as a secondary enforcement layer. CBOS filters out opted-out customers before generating the batch file, ensuring no survey invitations are sent to customers who have declined. For IVR surveys, opt-in/out is handled per-instance — the customer chooses in real-time whether to remain on the line for the survey. Chat, WIC QR code, and paper surveys are inherently opt-in by participation; no pre-filtering is required as the customer initiates engagement voluntarily. ## Survey Configuration Surveys are created and managed within Proponisi. Authorized users with appropriate role-based permissions access the Proponisi survey builder to create survey instruments. The builder supports up to 20 questions per survey, branching logic based on response values, English and Spanish language versions with parallel question authoring, and spelling and grammar checking. Surveys require approval before publishing, and the system maintains version history. CTIO defines targeting criteria for survey deployment, including channel, account type, location, communication preference, and payment method. These criteria are configured as rules within Proponisi. ## Reporting and Data Access **Operational Reporting in Proponisi****:** CSRs and supervisors access survey results through the Proponisi interface. Agents view their individual survey scores and verbatim customer comments. Supervisors view results for their team members. Access to Proponisi is controlled through role-based permissions aligned to operational roles defined in the Operations Plan and SOPs. **Business Intelligence Reporting:** Proponisi sends a survey results data feed to Emovis. This feed integrates with Power BI for statistical analysis, trend reporting, and contractual reporting deliverables. The Data and Reporting design documents detail the specific data elements, feed schedule, and Power BI report specifications. ## Data Storage and Security Proponisi stores only minimal metadata: SurveyKey, Interaction ID, Agent ID, Reason Code, and optional custom fields. Customer PII (such as phone or email) is stored only when required for reporting. All survey data is hosted in Microsoft Azure, encrypted in transit (TLS 1.2+) and at rest, with configurable retention periods aligned to CTIO requirements. Complete audit logs track every change, ensuring transparency and accountability. Access is controlled through role-based permissions. Only authorized users can create surveys or retrieve results. Real-time redaction ensures that sensitive information (such as credit card numbers or PII inadvertently spoken in an IVR survey) is never exposed. Data retention periods are configurable within Proponisi and align to CTIO data retention policy requirements. Proponisi security and compliance controls are managed in accordance with applicable contractual, privacy, and security requirements, including any standards identified for the COMBO solution (PCI DSS, HIPAA, and NIST 800-53 standards). # Technologies Used The technologies used by Emovis Touch are described below. Table 229 – Descriptions of Technologies Used | Technologies | Document Reference | COMBO Use | | --- | --- | --- | | Amazon API Gateway | [Amazon API Gateway](https://aws.amazon.com/api-gateway/) is a fully managed service that helps developers create, secure, and manage APIs at scale, handling tasks like traffic management, Cross-Origin Resource Sharing (CORS), authorization, and monitoring. | To access APIs in flows – sections 3.5.3, 3.6.1, 3.6.3, 3.8, 3.10 | | Amazon Connect | The [Amazon Connect Product Sheet](https://aws.amazon.com/connect/) provides an overview of Amazon Web Services’ (AWS’) cloud-based contact center service, outlining key features, benefits, pricing, and use cases for customer service, sales, and support. | All Contact Center Functions – IVR, Chat, Social Media, Integrations, Reporting. | | Amazon Connect Chat | [Amazon Connect Chat](https://aws.amazon.com/connect/messaging/) is a feature of AWS's Amazon Connect that provides real-time, text-based support via web chat on websites or apps. | Section 3.6.1 | | Amazon Contact Lens | [Amazon Contact Lens](https://aws.amazon.com/connect/contact-lens/) is a feature of Amazon Connect that uses machine learning and natural language processing (NLP) to analyze and extract insights from customer-agent interactions in real-time, improving customer service. | Section 3.8 | | AWS Lambda | [AWS Lambda](https://aws.amazon.com/lambda/?p=pm&c=la&z=4) is a compute service that runs your code in response to events and automatically manages the compute resources, supporting modern, production-ready serverless applications. | Sections 3.5.5, 3.6.1, 3.6.3, 3.8, 3.10 | | Amazon Lex | [Amazon Lex](https://docs.aws.amazon.com/lex) is a service that enables developers to build conversational interfaces with voice and text, using NLP and speech recognition to power chatbots and virtual assistants. | Contact Center Sections – 3.5.3, 3.6.1, 3.6.3 | # Non-Functional Requirements (NFRs) This section describes the application of solution-wide non-functional requirements within the scope of the Omnichannel design. These requirements define the quality attributes and constraints under which customer-facing interactions and supporting platform components operate. To remain consistent with the structure of the Detailed Design Document, this section focuses on design-level application rather than contractual enforcement. Service levels, performance metrics, operational thresholds, and compliance obligations are defined in separate deliverables, including the Operations SLA & KPI Guidebook (CDRL23), Quality Management Plan (CDRL16), Operations Plan (CDRL20), and other applicable DDD volumes. ## Accessibility and Usability Accessibility and usability are treated as core design considerations for all Omnichannel customer interactions. The solution is designed to support a broad range of users and interaction scenarios across web, mobile, voice, and digital channels. Key accessibility considerations embedded in the design include: Conformance of web and mobile interfaces to WCAG 2.2 Level AA and applicable ADA requirements Structured page layouts and navigation models that support assistive technologies Consistent treatment of form controls, validation feedback, and error messaging Content presentation that supports readability and interaction across devices Usability is addressed through consistent interaction patterns across channels. Customers experience predictable navigation, shared terminology, and uniform feedback regardless of whether they are interacting through self-service interfaces, conversational bots, IVR flows, or live agents. Designs also preserve interaction context when a customer transitions between automated and agent assisted channels, reducing repetition and improving overall experience. Accessibility and usability conformance is validated through design reviews and quality assurance activities aligned with documented use cases and test scenarios. ## Security, Privacy, and Data Protection Security and data protection requirements are incorporated into the Omnichannel design to align with enterprise and public sector expectations. From a design standpoint, the solution incorporates: Federated authentication and role-based authorization for administrative, agent, and system access Segregation of privileges to limit access to authorized functions and data Data protection measures are applied consistently across the solution, including: Encryption of data in transit between system components Use of managed encryption mechanisms for stored data Reliance on PCI compliant third party providers for all payment processing activities Sensitive payment credentials are not stored or exposed within Emovis systems. Personal and account data is processed only to support defined business functions, with design controls such as masking, logging, and retention management applied to support privacy and audit requirements. Operational security monitoring and incident response procedures are defined in the quality and operations documentation. ## Performance, Availability, and Scalability The Omnichannel solution is architected on AWS managed services, including Amazon Connect, to support scalable, resilient, and highly available operations without reliance on fixed infrastructure sizing. Key design characteristics include: Elastic scaling to accommodate fluctuations in interaction volume Built-in redundancy across availability zones Serverless execution models that reduce dependency on manual capacity planning To support continuity of service, Omnichannel workflows incorporate resilience patterns such as controlled degradation, alternate routing paths, and fallback handling when downstream dependencies experience latency or temporary failure. Specific performance targets, availability commitments, and recovery objectives are defined in contractual and operational documents. This section confirms that the Omnichannel design supports those requirements but does not define measurable service levels. ## Logging, Monitoring, and Audit Support Operational transparency is supported through logging and monitoring capabilities built into Amazon Connect, associated AWS services, and integrated customer experience analytics platforms provided by Proponisi. From a design perspective, the Omnichannel platform provides: Visibility into interaction volumes, routing behavior, and agent activity Logging of system and integration events to support troubleshooting and analysis Capture of security relevant actions to support audit and traceability needs Access to logs, metrics, and reports is restricted by role to support appropriate separation of duties. Detailed reporting structures, alerting practices, and audit workflows are documented in the Reporting and Analytics design and related operational deliverables. ## Design Scope Statement The non-functional requirements described in this section reflect design intent and architectural alignment within the Omnichannel scope only. This section does not: Define or modify contractual SLAs, KPIs, or penalties Establish operational procedures or monitoring thresholds Supersede the documented characteristics of AWS managed services Where non-functional requirements require formal measurement, enforcement, or operational governance, the authoritative definitions reside in the applicable CDRLs and referenced design documents. CDRL06_Detailed Design Document_Vol 5_M03_Final Draft_V.02_2026/MM/DD 2 of 47 CDRL06_Detailed Design Document_Vol 5_M03_Final Draft_V.02_2026/MM/DD 2 of 186 CDRL06_Detailed Design Document_Vol 5_M03_Final Draft_V.02_2026/MM/DD 2 of 89 This document includes trade secrets or other confidential, proprietary information that is exempt under § 24-72-204(3)(a)(IV), C.R.S., from disclosure as a public record. CDRL06_Detailed Design Document_Vol 5_M03_Final Draft_V.02_2026/MM/DD CDRL06_Detailed Design Document_Vol 5_M03_Final Draft_V.02_2026/MM/DD 2 of 247 CDRL06_Detailed Design Document_Vol 5_M03_Final Draft_V.02_2026/MM/DD 2 of 449 CDRL06_Detailed Design Document_Vol 5_M03_Final Draft_V.02_2026/MM/DD 2 of 449 CDRL06_Detailed Design Document_Vol 5_M03_Final Draft_V.02_2026/MM/DD 2 of 90 CDRL06_Detailed Design Document_Vol 5_M03_Final Draft_V.02_2026/MM/DD 2 of 248 Confidential: Use or disclosure of information contained on this sheet is subject to CDRL06_Detailed Design Document_Vol 5_M03_Final Draft_V.02_2026/MM/DD 2 of 44 CDRL06_Detailed Design Document_Vol 5_M03_Final Draft_V.02_2026/MM/DD 2 of 168 CDRL06_Detailed Design Document_Vol 5_M03_Final Draft_V.02_2026/MM/DD 2 of 45 CDRL06_Detailed Design Document_Vol 5_M03_Final Draft_V.02_2026/MM/DD 2 of 185 CDRL06_Detailed Design Document_Vol 5_M03_Final Draft_V.02_2026/MM/DD 2 of 169