Designing a Payment Middle Platform from Scratch – Core Challenges (Interview Answer)

What Is a Middle Platform?

A middle platform is the capability hub in a company's digital transformation, providing reusable building blocks that enable rapid business innovation while maintaining system stability and data consistency.

Three Classic Middle Platforms

Business Middle Platform

Core positioning: encapsulate reusable business capabilities (e.g., user management, order processing, payment settlement) as standardized components.

Benefits: avoid duplicate development across multiple front‑ends; new businesses can assemble existing components quickly.

Example: Alibaba’s shared business department provides unified product, transaction, and member services for Taobao, Tmall, etc.

Data Middle Platform

Core positioning: break data silos, provide unified data governance, cleaning, modeling, and asset creation (e.g., user tags, product portraits).

Benefits: enable cross‑department data sharing, support precise marketing, inventory alerts, etc.

Example: ByteDance’s data middle platform consolidates user data from Douyin and Toutiao for personalized recommendations.

Technology Middle Platform

Core positioning: standardize underlying technical capabilities (servers, databases, security, messaging, container orchestration) to reduce duplication and lower entry barriers for business teams.

Benefits: ensure system stability, allow developers to focus on business logic.

Example: Tencent’s technology middle platform provides unified cloud services, security components, and development tools for WeChat, games, finance, etc.

Payment Middle Platform Overview

The payment middle platform belongs to the business middle platform category. It aggregates internal and external payment resources, standardizes payment capabilities, and aims to eliminate fragmentation in the payment link, improving efficiency, reducing integration cost, and ensuring transaction security.

Core Positioning

Unified access, centralized control, flexible adaptation for front‑end services.

Core Functions

Multi‑channel unified integration and management (e.g., bank cards, WeChat Pay, Alipay, Apple Pay, PayPal, digital RMB).

Standardized and automated payment flow (e.g., request → channel processing → callback → order update).

Risk control and security (real‑time rule engine, PCI‑DSS compliance, encryption of sensitive data).

Reconciliation and fund management (automatic reconciliation, fund settlement, clear reports).

Flexible adaptation and scaling (customizable limits, fees, refund rules; high concurrency via load balancing and async processing).

Core Value

Cost reduction by avoiding duplicate channel integrations.

Efficiency boost: new business can go from “month‑level” to “day‑level” integration.

Enhanced control through unified monitoring of success rates, failure reasons, and cash flow.

Security reinforcement via centralized risk‑control mechanisms.

Typical Cases

JD.com’s payment middle platform consolidates hundreds of channels for JD Mall, JD Daojia, JD International, achieving “one‑time integration, all‑scenario reuse”.

Lakala provides standardized payment APIs for SMEs and handles fraud detection centrally.

Payment Middle Platform Modeling

Modeling focuses on three dimensions:

Business domain split: separate payment business layer (user‑facing) from accounting layer (internal finance).

Scenario‑driven design: decompose the full payment process (initiation, channel interaction, result sync) into modules such as cashier, channel gateway, etc.

Technical characteristics: partition components based on performance and scalability needs (high‑concurrency core vs. strong‑consistency accounting).

Layered Architecture

Cashier: provides configurable payment entry templates for PC, APP, H5.

Transaction Core: validates requests, creates payment orders, and forwards to the payment core.

Payment Core: selects payment tools, creates orders, and invokes channel gateways.

Channel Gateway: abstracts external channel protocols, handles signing, retries, and routing.

Accounting System: records fund changes, supports freeze/unfreeze, and generates accounting entries.

Compliance System: integrates anti‑money‑laundering and anti‑fraud engines.

Core Payment Flow

Business side initiates payment via cashier or API.

Transaction core validates order status, amount, and user state.

Payment core selects the optimal payment tool (balance → credit card → third‑party) and creates a payment order.

Channel gateway calls the external channel and receives the result.

Result is synchronized back to payment core, which updates order status and triggers downstream systems (data center, clearing, compliance).

Final callback is sent to the business side.

Key Implementation Details

// Business side pseudocode
public class BusinessService {
    public void initiatePayment() {
        PaymentRequest request = new PaymentRequest(
            "order_123",      // order ID
            "user_456",       // user ID
            new BigDecimal("100.00"), // amount
            "ALIPAY",        // payment tool
            "https://merchant.com/callback" // callback URL
        );
        PaymentClient.submitPayment(request);
    }
}

// Transaction core validation
public class TransactionCore {
    public boolean validateRequest(PaymentRequest request) {
        Order order = orderDAO.getOrder(request.getOrderId());
        if (order == null) throw new Exception("订单不存在");
        if (!order.getAmount().equals(request.getAmount())) throw new Exception("金额不匹配");
        if (order.getStatus() != OrderStatus.UNPAID) throw new Exception("订单状态异常");
        if (RiskControlService.isSuspicious(request)) throw new Exception("风控拦截");
        return true;
    }
}

// Payment core with strategy pattern
public class PaymentCore {
    public PaymentResponse process(PaymentRequest request) {
        PaymentStrategy strategy = PaymentStrategyFactory.getStrategy(request);
        PaymentTool tool = strategy.selectPaymentTool();
        if (tool == null) throw new Exception("无可用支付工具");
        PaymentOrder paymentOrder = new PaymentOrder(
            UUID.randomUUID().toString(),
            request.getOrderId(),
            tool.getToolType(),
            PaymentStatus.PROCESSING
        );
        paymentOrderDAO.save(paymentOrder);
        ChannelRequest channelReq = strategy.buildChannelRequest(request, paymentOrder, tool);
        ChannelGateway.submit(channelReq);
        return new PaymentResponse("PAYING", paymentOrder.getPaymentNo(), "处理中");
    }
}

// Channel gateway with retry
public class ChannelGateway {
    public static ChannelResponse submit(ChannelRequest request) {
        PaymentChannel channel = ChannelFactory.getChannel(request.getChannelType());
        Map<String, String> params = channel.wrapParams(request);
        for (int i = 0; i < 3; i++) {
            try {
                String response = HttpUtil.post(channel.getUrl(), params);
                return channel.parseResponse(response);
            } catch (TimeoutException e) {
                // log and retry
            }
        }
        throw new ChannelException("渠道调用失败");
    }
}

Idempotency and Reliability

Payment orders use globally unique IDs; database unique indexes and state machines guarantee idempotent processing. Asynchronous result handling uses @Async with retry logic (exponential back‑off) to ensure eventual consistency.

Fault Tolerance

Client‑side exponential retry (1s/4s/9s) with UUID to prevent duplicate payments.

Gateway layer: Redis token‑bucket rate limiting, Hystrix‑style circuit breaker (error rate >50% within 10 s triggers open), request caching for read‑only calls.

Service layer: async retry via Kafka/RabbitMQ (max 5 attempts), two‑phase commit for critical fund operations.

Data layer: master‑slave hot standby across data centers, sharding by user ID, periodic reconciliation SQL to detect missing bank transactions.

Security Guarantees

Network defense: firewalls, IDS/IPS, VPN for admin access.

Transport encryption: TLS with mutual authentication.

Data encryption: AES‑256 for stored card numbers, bcrypt for passwords, KMS‑managed keys with rotation ≤90 days.

Identity & access: MFA for high‑value payments, RBAC‑based ACL, SSO integration.

Audit & monitoring: full‑link logging (operation, IP, result) retained ≥6 months, SIEM alerts on abnormal payment frequency.

Distributed Transaction Strategies

TCC (Try‑Confirm‑Cancel)

Three‑phase protocol: Try reserves resources (e.g., freeze funds), Confirm commits actual deduction, Cancel rolls back on failure. Suitable for core fund flows but requires business‑level code intrusion.

Transactional Message (e.g., RocketMQ)

Local transaction sends a half‑message; upon success the message is committed to the broker, otherwise rolled back. Consumers process the message idempotently. Ideal for non‑core notifications such as order updates or loyalty points.

Saga (Compensating Transactions)

Breaks a long transaction into a series of short steps, each with a compensating action. Guarantees eventual consistency for complex, long‑running processes like cross‑border payments.

Local Message Table

Insert a message record in the same DB transaction as the business update; a background job publishes pending messages to a queue. Simple to implement but couples business and messaging tables.

Overall Recommendations

Combine strong‑consistency TCC for critical fund operations with eventual‑consistency mechanisms (transactional messages, Saga, or local message tables) for auxiliary services. Complement with idempotency, retry, reconciliation, circuit‑breaker, and robust monitoring to ensure payment data accuracy and system resilience.