Payment Gateway Integration System: Multi-Channel Cashier API Development and Sandbox Testing

Disclaimer: This article is for technical education and demonstration only. It is not professional or financial advice. Any real-world deployment must comply with applicable laws and regulations.

Recently took on a project where the client needed their own cashier system, requiring support for multiple payment channel switching and customizable cashier interface templates. Having used several open-source solutions before, this time I chose a front-end/back-end separation architecture: PHP backend + Vue frontend. The deployment went quite smoothly. Here I’ll share the entire setup process and actual test results.

System Architecture and Core Feature Testing

This system uses ThinkPHP6 for the backend API layer, with the frontend cashier interface rebuilt using Vue3. After actual deployment, I found it supports multiple template switching, allowing merchants to choose different UI styles based on their business scenarios. This design is quite flexible.

Payment Channel Integration Practice

The backend configured WeChat official API, Alipay face-to-face payment, UnionPay QuickPass and other channels. Each channel requires filling in merchant ID, secret key, callback URL and other parameters. During testing, I first ran through the process using the sandbox environment. For WeChat, pay attention to certificate path permissions; Alipay’s public key format often causes errors, so I recommend using the official tool to generate it.

Channels can be set with priority and rates, and the system automatically selects routing based on amount. In actual testing, small orders go through WeChat, large amounts through UnionPay direct connection, and the split accounting logic is written fairly clearly.

Order Management and Reconciliation Features

The backend has complete order transaction queries, supporting filtering by time, merchant, and channel. The reconciliation module can export CSV files with fields including order number, payment time, handling fee, and actual credited amount. I ran a week of test data with zero reconciliation errors, and asynchronous callback handling is quite stable.

Highlight tip: This system’s callback mechanism implements queue retry. If the merchant’s server goes down, it will automatically delay and resend, with a maximum of 5 retry attempts. This design can reduce order loss rate in high-concurrency scenarios.

Deployment Environment Configuration Points

The server uses a 2-core 4GB cloud host, with environment built using BT-Panel. PHP version needs to be 7.4 or above, with fileinfo and redis extensions installed. Database uses MySQL 5.7. After importing the SQL file, remember to modify the database connection parameters in the config.

Nginx URL Rewrite Rules

ThinkPHP6 routing requires URL rewrite configuration. Add this section to the Nginx configuration file:

location / { try_files $uri $uri/ /index.php?$query_string; }

After frontend build, place it in the public directory and modify the API interface address in the .env file. During testing, I encountered CORS errors, which were only resolved after adding CORS middleware to the backend.

Scheduled Tasks and Log Monitoring

The system has a scheduled script for syncing channel balance and checking timeout orders. Add this to BT-Panel’s scheduled tasks:

php think order:check execute every 5 minutes

Log files are in the runtime/log directory. Exception information records request parameters and response content, making troubleshooting very convenient. Recommend regularly cleaning logs, otherwise disk will fill up.

Secondary Development and Extension Space

The code structure is fairly standardized, with controllers, models, and service layers clearly separated. If you need to add a new payment channel, just create a new class in the app/service/pay directory and implement the unified interface. I added a bank card collection channel for the client, and the amount of changes wasn’t large.

Frontend componentization is also well done. The cashier interface can be extracted separately and embedded into other systems. The template engine supports custom variables, allowing merchants to modify color schemes, logos, and payment instruction text.

Suitable Use Cases and User Groups

This system is more suitable for teams with certain development capabilities, or e-commerce platforms that need to build their own payment gateway. If you’re just working on a small personal project, using third-party aggregated payment directly is more convenient. But if business volume picks up and you want to control costs and data, building your own set is still worthwhile.

In actual testing, a single machine can handle 200 transactions per second concurrency. Going higher requires Redis cache optimization and database read-write separation. The client now processes around 5000 orders daily and it runs very stably.

Common Questions

Q: What if payment callbacks frequently timeout?
A: Check whether the merchant callback address is accessible from the public network. Recommend using intranet penetration tools for testing. The backend can manually trigger supplementary orders, or adjust queue retry interval parameters.

Q: Can foreign payment channels be integrated?
A: The code level supports extension, but pay attention to compliance issues. Foreign channels generally require corporate qualifications and foreign exchange filing. Not recommended for individual attempts.

Q: How much can the frontend cashier interface be customized?
A: The template system supports modifying HTML and CSS. Logo, color scheme, and payment method icons can all be customized. If you want to change interaction logic, you need to modify Vue component source code and rebuild.

Q: How is system security?
A: APIs implement signature verification and IP whitelist restrictions. Sensitive parameters use RSA encryption for transmission. Recommend changing the default admin password promptly after deployment, and enabling HTTPS and firewall policies.

Overall deployment took about half a day, mainly because configuring channel parameters and testing callback processes was time-consuming. Code quality is decent, didn’t encounter major bugs. If you’re also looking for a similar solution, this system can serve as a reference foundation for secondary development. Remember to run through the complete process in a test environment first, and do data backups and monitoring contingency plans before production launch.

This article is for technical education only. Please comply with laws and regulations, and any illegal use is prohibited.

Disclaimer: This article is for technical education and demonstration only. It is not professional or financial advice. Any real-world deployment must comply with applicable laws and regulations.

#Payment System #Cashier API #Gateway Development #Sandbox Testing #PHP Development