MOP Architecture

This chapter provides an architectural overview of MOP, including the major software components, system interactions, configuration ownership, and transaction flow.

Understanding the architecture assists implementation consultants and customer administrators when planning deployments, troubleshooting issues, and determining where to make configuration changes.

Overview

MOP is a web-based ordering platform that extends Oracle Simphony Point-of-Sale (POS).

Customers use their own mobile device to browse menus, place orders, and pay electronically without installing a native mobile application.

The ordering experience operates independently of the POS while continuing to use Simphony as the primary source for menu information, pricing, taxes, operational settings, and transaction processing.

The architecture is based on the following core principles:

• Simphony serves as the system of record for menu, pricing, and transaction data.
• Customer-facing ordering operates independently of POS operations.
• Configuration is managed through Simphony administration tools whenever possible.
• Operational controls remain within Simphony.
• Payments are processed through enterprise payment providers.
• Menu data is synchronized automatically.
• Customers can place orders without requiring direct access to the POS network.

High-Level Architecture

                    +---------------------------+
                    |       Customer Device     |
                    |  Mobile Browser/QR Code |
                    +-------------+-------------+
                                  |
                                  |
                                  ↓
                    +---------------------------+
                    | Mobile Order & Pay Widget |
                    |  Customer Ordering UI     |
                    +-------------+-------------+
                                  |
                Menu Synchronization/Ordering API
                                  |
                                  ↓
                 +-------------------------------+
                 |     MOP Backend Services      |
                 +---------------+---------------+
                                 |
             +-------------------+-------------------+
             |                                       |
             ↓                                       ↓
   Simphony Transaction Services            Oracle Payments
   (Check Creation & Validation)          (Card Authorization)
             |                                       |
             +-------------------+-------------------+
                                 |
                                 ↓
                          Oracle Simphony POS

Major Components

Customer Ordering Widget

The customer ordering widget provides the online ordering experience. The widget’s responsibilities include:

• Displaying menus
• Displaying menu item images
• Basket management
• Modifier selection
• Capturing customer information
• Payment selection
• Order confirmation

The ordering widget does not maintain menu data independently.

All operational information originates from Simphony.

MOP Backend

The backend coordinates communication between the following components:

• Ordering widget
• Simphony
• Payment provider
• Configuration services

The MOP backend is responsible for::

• Menu synchronization
• Pricing validation
• Basket validation
• Payment orchestration
• Order submission
• Customer notifications

Oracle Simphony

Simphony serves as the authoritative source for the following:

• Revenue Centers
• Menus
• Categories
• Menu Items
• Prices
• Taxes
• Employees
• Order Types
• Service Charges
• Discounts

The ordering widget retrieves this information through supported Simphony interfaces.

Simphony Transaction Services (STS)

STS provides the transactional interface between MOP and Simphony. STS responsibilities include:

• Basket validation
• Check creation
• Price calculation
• Tax calculation
• Service charge calculation
• Order submission

STS is required for every MOP deployment. If STS is unavailable, customers cannot place orders.

Oracle Payments

Oracle Payments provides secure online payment processing.

The supported payment methods include:

• Credit Cards
• Debit Cards
• Apple Pay
• Google Pay

Payment providers are configured independently from menu configuration.

Configuration Ownership

The following table describes where configuration is maintained. Oracle recommends maintaining configuration within Simphony whenever possible to avoid duplicate administration.

Configuration	System of Record
Revenue Centers	Simphony
Menus	Simphony
Menu Items	Simphony
Prices	Simphony
Taxes	Simphony
Employees	Simphony
Order Types	Simphony
Service Charges	Simphony
Discounts	Simphony
Branding	MOP/FLM
Opening Hours	Simphony
Alcohol Controls	Simphony
Operational Availability	Simphony

Configuration Synchronization

Configuration changes are synchronized from Simphony to MOP. Examples include:

• Menu changes
• Price changes
• Category changes
• Consumer Item Name
• Consumer Item Description
• Images
• Revenue center availability

The frequency of synchronization depends on the deployed configuration.

Administrators should allow sufficient time for synchronization before validating changes.

Customer Ordering Flow

The following sequence describes a typical customer ordering experience.

1. Customer scans a QR code or opens the venue ordering website.
2. MOP determines the appropriate revenue center.
3. Menu information is presented.
4. Customer selects menu items.
5. Basket is validated through STS.
6. Taxes, discounts, and service charges are calculated.
7. Customer enters contact information.
8. Customer selects payment method.
9. Oracle Payments authorizes the payment.
10. STS creates the check.
11. Order is submitted to Simphony.
12. Customer receives confirmation.
13. Kitchen preparation begins.

Menu Synchronization

Menu synchronization retrieves the following information from Simphony.

Revenue Center

• Name
• Address
• Opening Hours
• Branding Reference

Categories

• Display Order
• Visibility

Menu Items

• Consumer Item Name
• Consumer Item Description
• Images
• Prices
• Modifier Groups
• Taxes
• Alcohol indicator
• MOP Tag

Pricing Architecture

Simphony determines all pricing. MOP does not calculate prices independently. Before payment, the ordering widget retrieves pricing information from STS.

Simphony calculates the following values:

• Menu Prices
• Discounts
• Taxes
• Service Charges
• Basket Total

This ensures consistent pricing and calculations across POS Operations, Reporting, and Mobile Ordering.

Payment Architecture

Payments are processed before the order is submitted. The payment process follows these steps:

Customer
↓
Select Payment Method
↓
Oracle Payments
↓
Payment Authorization
↓
Simphony Check Creation
↓
Order Confirmation
↓
Kitchen Fulfillment

Operational Controls

Operational controls are managed within Simphony and include:

• Revenue center availability
• Opening hours
• Alcohol availability
• Suspend Ordering
• Match day operations

Changes to these controls affect the customer ordering experience without requiring the menu to be republished.

Security Architecture

• Simphony does not directly process customer payment information.
• Sensitive payment information is securely handled by the configured payment provider.
• Simphony stores only transaction references needed for operational reporting.
• Customers can place guest orders without signing in or creating an account.
• Depending on the payment provider’s capabilities, payment tokens may be stored to support returning customers.

Administration Architecture

MOP administration is integrated with FLM and provides a separate administration interface hosted alongside FLM within Simphony Home.

This architecture provides the following benefits:

• Independent deployment
• Shared authentication
• Simplified provisioning

Initial account registration is performed outside the embedded administration interface. After registration, all ongoing configuration is managed through the MOP administration interface.

Scalability

The architecture a wide range of hospitality environments, including:

• Single revenue center deployments
• Venues with multiple revenue centers
• Stadiums
• Resorts
• Hotels
• Enterprise hospitality groups

Each revenue center operates independently while sharing common platform services.

Best Practices

Oracle recommends the following best practices:

• Use Simphony as the single source of truth for menu, pricing, and operational configuration.
• Avoid duplicating configuration settings outside Simphony.
• Verify menu synchronization after making significant menu changes.
• Configure and test one revenue center before enabling additional revenue centers.
• Continuously monitor STS availability.
• Verify payment processing before beginning customer testing.
• Document customer-specific architectural decisions to support troubleshooting and ongoing maintenance.