Management Portal
The user experience: dashboards, workspaces, configuration screens and operational actions.
PLATFORM ARCHITECTURE
One platform.
Clear responsibilities.
The Portal, Management API and Acquirer are separate applications. Their interfaces connect day-to-day management with payment processing, while keeping each application responsible for its own work.
THE MERCHANTPAISA PLATFORM
01Management Portal
Visibility. Configuration. Operations.
Authorized management actions
02Management API
Identity. Permissions. Workflows.
Service-to-service integration
03Acquirer Solution
Processing. Routing. Financial control.
BanksProcessorsPayment networks
Public architecture · connectivity subject to agreed scope and approvals
CONNECTED BY DESIGN
Every layer has a job.
No layer does everything.
Management API
The management authority: authentication, authorization, tenant scope, validation and workflow coordination.
Acquirer Solution
The processing authority: payment lifecycle, provider routing, execution and financial state.
TWO FLOWS. DISTINCT PURPOSES.
Manage the business.
Process the payment.
MANAGEMENT FLOW
Management PortalManagement APIAcquirer
Management actions are authorized and coordinated before reaching processing services.
PAYMENT FLOW
Payment channelAcquirer / payment ingressConfigured provider
Payment ingress is defined by the solution. Payments do not have to pass through the Management API.
The diagrams show public responsibility boundaries, not private deployment topology. No internal hosts, credentials or privileged endpoints are disclosed.
A SEPARATE INTELLIGENCE LAYER
Private AI beside the platform.
Not in the payment path.
Authenticated user → Management API authorization and scope → separate private Copilot → approved, permission-filtered data tools → grounded answer with evidence.
Designed as a standalone, white-label product, Copilot can use MerchantPaisa or scoped integrations with approved internal sources from existing systems. The flow shown is a MerchantPaisa integration example, not a mandatory host. Independent deployment is not yet validated. No OpenAI and no external APIs across the intended Copilot runtime, processing and tools. In this example, Management owns identity and authorization; the Acquirer retains financial execution.
Explore Private AI CopilotMERCHANTPAISA INTEGRATION EXAMPLE
Authenticated userManagement API scopePrivate Copilot
Approved, permission-filtered tools provide evidence for an answer. This is not an unrestricted database connection or a live website integration.
ADAPT THE BUSINESS. KEEP THE BOUNDARIES.
Plan the deployment
around your business.
Agree which applications, providers and integrations your business needs, then define the responsibilities and tests for each.
01
Independent applicationsSeparate build and deployment boundaries let the management experience and processing core evolve deliberately.
02
One financial authorityPortal views and API responses reflect authoritative processing outcomes; they do not invent success.
03
Explicit tenant controlsResource ownership and permissions belong in the management service, not only in browser filters.
04
A separate public websiteThis marketing site has no payment execution, database or internal service dependency.
TALK WITH OUR TEAM
Let’s discuss your
payment requirements.
Tell us which markets you serve, how you process payments and what your team needs to manage.