Skip to main content
This section explains how Mini Apps are architected within the Rebell ecosystem, where code is executed, how security boundaries are enforced, and how Mini Apps interact with merchant backend systems and payments.
Understanding these concepts is essential before starting development.

​
Execution Model

Mini Apps run inside the Rebell SuperApp and are executed by a sandboxed runtime environment provided by Rebell. Key characteristics:
  • Mini App code is downloaded and executed at runtime
  • Execution happens inside the SuperApp, not on the merchant’s infrastructure
  • The runtime is isolated from the underlying mobile operating system
  • Mini Apps cannot access device resources directly unless explicitly exposed by the platform
From a technical perspective, a Mini App behaves like a managed frontend application, not like a native app or a backend service.

​
Separation of Responsibilities

A Mini App architecture always involves three distinct layers, each with a clear responsibility.
Responsible for:
  • User interface and navigation
  • Capturing user input
  • Calling merchant backend APIs
  • Triggering platform capabilities (e.g., payments, navigation)
NOT responsible for:
  • Business logic
  • Data persistence
  • Secrets or credentials
  • Payment authorization logic

​
Responsibility Matrix

ResponsibilityMini AppMerchant BackendRebell Platform
User interface✅
Business logic✅
Data persistence✅
Payment creation✅
Payment execution✅
Identity & session✅
Security enforcement✅

​
Mini App Types: Native and H5

Rebell supports two types of Mini Apps, depending on how the user interface and user interactions are implemented. Both types run inside the Rebell SuperApp and follow the same architectural and security principles.
Native Mini Apps are built using the Rebell Mini App framework and platform-provided UI components.Characteristics:
  • User interface rendered using platform-native components
  • Deep integration with SuperApp navigation and capabilities
  • Best performance and responsiveness
  • Full access to Mini App APIs (JSAPI)
  • Recommended for most production use cases
Typical use cases:
  • Interactive service flows
  • Payment-centric experiences
  • User journeys requiring native look and feel
  • Long-lived Mini Apps with frequent user interaction

​
Choosing the Right Type

CriteriaNative Mini AppH5 Mini App
PerformanceExcellentGood
Native featuresFull accessLimited
Development effortHigherLower
Existing web assetsN/ACan reuse
Recommended forNew integrationsMigration path
Native Mini Apps are the recommended default for new integrations. H5 Mini Apps should be considered when rapid reuse of existing web assets is required.
Both Native and H5 Mini Apps rely on a merchant backend for business logic and payment execution, and both integrate with Rebell’s payment platform using the same underlying principles.

​
Security Boundaries

Mini Apps operate within strict security boundaries.
Key security principles:
  • Mini Apps cannot store secrets
  • Mini Apps cannot directly call third-party services without merchant backend mediation
  • Mini Apps cannot initiate payments independently without platform involvement
  • Network access is restricted and controlled
This model ensures:

User Data Protection

Sensitive user information is isolated and controlled

Credential Protection

Merchant credentials never touch client-side code

Regulatory Compliance

Financial regulations are enforced at the platform level

Reduced Attack Surface

Limited capabilities reduce potential vulnerabilities
Any sensitive operation must be delegated to the merchant backend.

​
Communication Model

Mini Apps communicate with merchant systems using HTTPS requests to merchant-controlled endpoints. Important aspects:
  • Mini App requests are authenticated using platform-provided context
  • Merchant backend validates requests and enforces authorization
  • Merchant backend may call Rebell Payment APIs using server credentials
  • Responses are returned to the Mini App for UI rendering
Mini Apps never hold API keys or signing material.

​
Identity & User Context

When a Mini App is launched, Rebell provides a user context associated with the active SuperApp session. This context allows the Mini App to:
  • Identify the current user
  • Personalize the experience
  • Associate actions with a specific user account
However:
  • Session context token
  • Authorization code for backend exchange
  • Platform-provided user identifier (after consent)
  • Raw user credentials
  • Long-lived tokens
  • Direct database access
User identity is mediated by the platform. Long-term user data must be stored by the merchant backend.
The exact APIs used to access identity information are described in the Mini App APIs section.

​
Payments in the Mini App Context

Payments inside Mini Apps follow the same principles as standalone payments, with an important distinction:
  • The payment experience is embedded in the Mini App flow
  • Payment execution is still handled by the Rebell Payments Platform
  • Final payment confirmation is delivered via backend webhooks
Mini Apps never bypass backend validation or webhook confirmation.

​
Architecture Summary

LayerRuns OnResponsibilities
Mini AppSuperApp runtimeUI, navigation, user input
Merchant BackendYour serversBusiness logic, data, payments
Rebell PlatformRebell infrastructureExecution, identity, security

​
Next Steps

With the architecture and concepts clarified, proceed to set up your development environment:

Development Environment

Set up Mini Program Studio and configure your workspace

Mini App Lifecycle

Understand the full lifecycle from creation to publishing