Design and Architecture of a Payment Operation Platform

This article explains the purpose, evolution, business logic, design principles, system architecture, permission model, and technical implementation of a payment operation platform that serves internal staff such as developers, testers, product managers, finance, and customer service within a payment company.

Top Architect
Top Architect
Top Architect
Design and Architecture of a Payment Operation Platform

The payment operation platform is an internal service tool for payment company staff—including developers, testers, product personnel, settlement staff, finance, and customer service—to query transaction, merchant, and rate information, handle on‑call issues, monitor services, and perform reconciliation and adjustments.

Initially, when transaction volume was low, all payment functions were bundled into a single system with a simple Spring MVC‑based management interface directly accessing the database. As business grew, the monolithic system became a bottleneck due to tight coupling and performance limits, prompting a modular split into subsystems (acquisition, settlement, accounting, merchant management) and corresponding database partitioning.

After the split, the operation platform faced challenges such as cross‑data‑source queries and security compliance, requiring a redesign for higher availability.

Business logic analysis identifies distinct user groups and their needs, guiding the platform’s functional architecture to support data aggregation, modification, and real‑time queries across multiple backend systems.

Design principles emphasize usability, learnability, security, and efficiency: the UI should be simple for internal users, require minimal training, protect sensitive data (e.g., merchant licenses, transaction details), and provide fast response times for customer‑facing queries.

The system adopts a front‑end/back‑end separation. The back‑end acts as a business router, invoking appropriate subsystem APIs, consolidating responses, and returning data to the front‑end. Direct database access is avoided for security and compliance.

Permission management is central; a dedicated RBAC‑based permission service is recommended, exposing an SDK for internal services to enforce fine‑grained access control.

Technical architecture incorporates audit logging, watermarking, unified approval workflows, and integration with a security center. The overall diagram (shown in the original images) illustrates the layered components, data flow, and interaction points.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

BackendSystem DesignSecuritypaymentRBAC
Top Architect
Written by

Top Architect

Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.