The campus network billing system, which is connected to third party payments, is considered a project in many cases."Last thing."The idea is to take an interface. When you really start moving forward, you find that the dimensions involved are more complex than expected: technical aspects, compliance levels, approval processes within schools, and attribution of funds settlements, each could become a card point. This article sums up these practical details, especially where they can be ignored but affect project delivery.
Logical choice of channels for payment
The most common third-party payment channels in the campus landscape are micromail payments and payment treasures, which cover almost all users’ daily habits. Silver cloud flashes will also be found in some of the banked campus projects, especially those linked to joint bank cards.
In choosing the channel for payment, two questions must be considered:
First, is the money going directly into the school account or to the platform service provider account?"Direct business lines"Or..."Service provider"The direct-account households mean that the school itself applies for a micro-credit payment or payment of a treasure account, and the funds are directly settled in the public accounts of the school; the provider's collection means that the service providers of the billing system have the qualifications to pay and then transfer them to the school. Both models differ with respect to compliance requirements, the time limit, and the rate of processing, and the financial acceptance of both methods varies.
Second, the funding requirements of schools. Many higher and public primary and secondary schools are institutions with strict regulatory requirements for collecting funds and may need to go to the network."Non-tax revenue"Channel or..."Substitute fees"If the school’s financial requirements are to be funded into a designated public account, and no other account of the third-party payment platform is available for clearing businesses, the access path must be redesigned.
Wed payment account application: more pits than I thought
If the school itself applied for the micro-payment account, it would have problems with the process itself.
The school, as a business unit, requires the establishment’s certificate of legal entity, organizational code, identity card, information on public accounts, etc.
One of the problems that will be encountered during the application process is that we're paying for it."Campus WiFi Charger"If you fill in a different category, you may find limits or functional limitations after running the connection and then re-route the application process. It is recommended that you pay micro-letters to identify suitable categories for technical support before applying, avoiding subsequent work.
Once the business application is completed, it will also be necessary to develop an API account, configure the API key, bind the IP white list, and configure the return address. These technical configuration steps are not inherently complicated, but operators need both management privileges for the backroom of the business and configuration rights for servers, which often do not belong to the same person in the school setting, and time-consuming confirmations take time.
Technical Details of Interface Interfacing
The official documentation of the micro-mail payments and payment treasures is complete, and access to technology is not a major obstacle per se, but several points deserve special attention in the school landscape.
The first is the choice to pay for the scene. The main entrances to campus charging are usually Portal pages (web end) and small programs. Portal pages recommend that JPPI or H5 be paid by micromail, with minor scenarios being paid by small programs. These three scenarios have different ways of accessing and development vary widely, and need to be defined in terms of which scenario to use instead of having them developed half as they are set up.
The campus billing system usually has multiple servers or sets of examples, and must be the only thing that makes a payment order number unique throughout the world. Repeating orders will lead to payment failures or reconciliation anomalies.
Third is the accessibility of the caller address. The payment/payment treasures are sent to the service provider after the user has completed the payment (reflection). If the school billing server is not accessible directly on the Intranet, it requires in-line penetration or a reception service in the DMZ area. Many school network administrators are cautious about inside-net penetration, an issue that needs to be communicated early and cannot wait until the call is reached.
Four are passive search mechanisms for payment results. It is common to rely on active feedback from payment platforms, but the return is likely to fail (web time-overtime, service-upplier). Robust realization requires a proactive query mechanism as a cover: when the checkback exceeds time, you ask the pay platform for order status and make sure it is fully charged."Active Query"The logic is missing in many projects, resulting in occasional charging delays and increased complaints.
Treatment of refund logic
The school network is a convenient but real event.
Return route: The balance is returned to the original payment channel through the payment platform ' s refund interface. This is the most concise way, but with a time limit (the return of micro-mail payments usually lasts for one year) and requires a system-wide process for applying for and approving refunds.
The system is heavy and costly, but many institutions of higher learning only recognize it because of financial compliance requirements.
If the school explicitly requests a refund on the support line, it is necessary to confirm who is responsible for the refund approval process at the contract stage, which approval node of the system ' s refund application has entered, and how the balance in the account of the fee-back system can be synchronized after the refund has been successful.
Reconciliations and financial verification: the part that really reassures school finances
Many school finance departments ' concerns about third-party payments focus on reconciliation: how do they collect the money, when they arrive and whether it is consistent with the system's charging records?
The reconciliation functions required for the billing system include a daily/monthly charge summary (classified by channel), detailed recording of each charge (time, amount, payment channels, user account numbers) and matching reports to pay platform bills.
The payment treasure and the micromail payments provide a reconciliation of the files for download in the format CSV, which can be used to make automatic matching with internal bills. If there is no accounting tool on the side of the system, school finance requires manual monthly downloads of platform bills and system export data matching, this workload is not insignificant and easy to miss.
It is recommended that the basic reconciliation function be built into the billing system: automatically pulls payment platform bills, matches with the system ' s chargeable records, and tag discrepancies. The difference may be due to technical reasons such as network delay, repeated retries, etc., which require manual verification and manual marking of differences.
Multiple packages, multichannels, consistency of billing.
In real-life projects, schools may have multiple charging channels: micromail/paying treasures via Portal or small programs on the line, cash or card charges in fee windows under the line and automatic deduction of a school cartoon (if there is a campus card system).
When multiple channels are parallel, consistency of billing is a matter that needs to be carefully designed. All channels will have to be filled in the same account balance and balances will need to be recorded uniformly in flow, not because different channels will be treated separately by different modules for technology purposes, and final bills will not match.
If a school has a cartoon, the relationship between a school card and a network account also needs to be clarified: it is either directly charged by a cartoon account or charged from a cartoon to a network account, which varies greatly in structure and user experience, and needs to be clearly identified with the school information services before accessing a cartoon system.
The contract subject and the rate are to be confirmed before the project starts.
Another thing is that many projects come to mind at a mid-to-late stage: micro-credit payments and payment of treasures are transaction fees, usually charged as a percentage of the amount traded. Who pays for school network charging?
This should be clear at the contract negotiation stage, and it is disputed that the money received is a few percentage points less than the book when waiting for the post-line financial reconciliation. The rates themselves are not high, but prior agreement is much cheaper than ex post facto interpretation.