Billing Gateway Charge Processing via Carrier Billing Module
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current systems for processing charges through mobile phone bills require unique merchant-specific code for each merchant server, leading to inefficiencies in communication and increased complexity when handling charges, failures, opt-in processes, and refunds across multiple carrier servers.
Innovation Solution
A billing server system that receives a charge API call, determines a select carrier server, transmits a charge request, and returns a result notification, including an indication of acceptance or failure, using a carrier billing module to streamline charge processing across multiple carriers with a unified API approach.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If unique merchant-specific code is created for each merchant server, then communication requirements of each merchant server are met, but device complexity and code maintenance burden increase significantly
Solution Approach 1:
The patent implements a universal billing server system that handles communications with multiple merchant servers using a single codebase. The billing server is designed to process charge requests from any merchant server through standardized interfaces, eliminating the need for unique merchant-specific code while maintaining the ability to adapt to different merchant requirements through configuration rather than code changes.
Solution Approach 2:
The billing server acts as an intermediary layer between merchant servers and carrier servers. It receives standardized charge requests from any merchant server, processes them according to carrier-specific requirements, and forwards appropriate requests to the correct carrier server. This mediator approach allows the system to handle diverse merchant and carrier requirements without requiring direct custom integration between each merchant and carrier pair.
2Adaptability or versatility
If additional merchant-specific code is added for each new merchant server, then new merchants can be accommodated, but productivity and implementation time decrease due to repeated code uploads
Solution Approach 1:
The billing server implements a universal interface that accepts standardized charge requests from any merchant server. When a new merchant is added, they simply need to connect to the existing standardized interface without requiring any code changes or uploads to the billing server. This universal approach enables immediate onboarding of new merchants, dramatically improving productivity and reducing implementation time.
3Adaptability or versatility
If merchant-specific code is used to handle charges, failures, opt-in, and refunds, then specific merchant requirements are met, but ease of operation and system maintenance deteriorate
Solution Approach 1:
The billing server serves as an intermediary that absorbs all merchant-specific and carrier-specific logic. It receives simplified standardized requests from merchant servers and handles the complexity of different carriers' requirements, failure scenarios, opt-in processes, and refund procedures internally. This shields merchants from complexity while maintaining the ability to handle diverse requirements, significantly improving ease of operation.
Solution Approach 2:
The billing server is designed to autonomously handle complex processes such as determining which carrier server to contact, processing opt-in requirements, managing failures, and handling refunds without requiring merchant-specific code or manual intervention. The system self-adapts to different scenarios through its internal logic and configuration, making operation simpler while maintaining versatility.
Data Source
AI summary
The billing gateway charge method and system are disclosed. A charge is processed by receiving a charge API call from a merchant server, detecting a select carrier server from a plurality of servers, transmitting a charge request to the select carrier server, and returning a charge result callback notification to the merchant server. If the charge request fails, the merchant server can submit a new request and an indication of acceptance and failure of the charge request is returned to the merchant server based on the new requests provided that the new request has a new request-id. A continue method allows for managing consumer opt-in in order to complete a transaction. Once the transaction is completed, a refund request from the merchant server can be processed by transmission to the carrier server.