JP6409052B2 - Billing gateway - Google Patents

Description

(Cross-reference to related applications)
This application claims priority from US patent application Ser. No. 13 / 873,068 filed Apr. 29, 2013 and U.S. Patent Application No. 13 / 873,099 filed Apr. 29, 2013. The entire disclosure is hereby incorporated by reference in its entirety.

(Technical field)
The present invention relates to systems and methods for processing claims.

  Consumers who purchase goods or services online to use payment source choices such as credit card, debit card payments, settlement from institution-owned accounts, or carry purchases during checkout Often an option can be given to charge the phone bill. When the consumer selects billing for his telephone bill, the member store server instructs the billing server associated with the carrier server to perform the billing. The billing server typically communicates with the consumer mobile phone to confirm the bill before billing the phone bill at the carrier server.

  The billing server may need to communicate with a plurality of member store servers and a plurality of carrier servers. Because of the unique communication requirements of each individual merchant server, additional merchant-specific codes in the billing server to allow such unique communication each time another merchant server is added Needs to be created and uploaded. This code needs to be added only to process the billing, but it is more specific to the new merchant server for billing failure handling, consumer opt-in control, carrier identification, refund handling, etc. It is necessary to add a lot of code.

  The present invention includes a step of receiving a billing API call including an MSISDN and an amount from a merchant server by a billing server, a step of determining a selected carrier server from a plurality of carrier servers by the billing server, a MSISDN and a billing server Processing the billing comprising: sending a billing request including the amount to the selected carrier server; and returning a billing result callback notification including an indication of approval or failure of the billing request to the merchant server by the billing server. Provide a method.

  The present invention also provides a non-transitory computer readable medium having stored thereon an instruction set that performs a method of processing a claim when executed by a computer processor, the method comprising: Receiving the billing API call including the MSISDN and the amount from the member store server; determining the selected carrier server from the plurality of carrier servers by the billing server; and selecting the billing request including the MSISDN and the amount by the billing server Transmitting to the server, and returning to the member store server a billing result callback notification including a billing request approval or failure indication by the billing server.

  The present invention further provides a billing computer system that includes a processor, a computer readable medium coupled to the processor, and an instruction set on the computer readable medium. The instruction set receives a billing API call including the MSISDN and the amount from the member store server, determines a selected carrier server from a plurality of carrier servers, sends a billing request including the MSISDN and the amount to the selected carrier server, and A carrier billing module executable by the processor is included to return a billing result callback notification including an approval or failure indication to the merchant server.

  The present invention also includes receiving an authorization API call including an MSISDN and an authorization request including an amount from the member store server by the charging server, determining a selected carrier server from a plurality of carrier servers by the charging server, The server sends an authorization request to the selected carrier server based on the amount of money, the billing server records the transaction authorized based on the authorization request, and the billing server sends the authorization request to the selected carrier server. After that, the capture API call including the capture request is received, and the billing server responds to the capture request, receives a cancel request from the member store server after the authorization request and before the capture request, and the capture transaction is canceled. Determining whether or not the transaction was captured and the captured transaction If not, the billing server sends a billing request to the selected carrier server in response to the capture request, but does not send if the captured transaction is cancelled. Provide a method of processing.

  The present invention further provides a non-transitory computer readable medium having stored thereon an instruction set for performing a method for processing a claim when executed by a computer processor, the method comprising: Receiving an authorization API call including an MSISDN and an authorization request including an amount from a member store server; determining a selected carrier server from a plurality of carrier servers by an accounting server; and an authorization request based on the amount by the accounting server A capture API call including a capture request after transmitting the authorization request to the selected carrier server by the billing server, recording the transaction authorized by the billing server based on the authorization request In response to the capture request by the charging server and the charging server. After the request and before the capture request, the cancel request has been received from the merchant server and it is determined whether or not the capture transaction has been canceled, and if the captured transaction has not been canceled, Responsive to the request, transmitting a billing request to the selected carrier server, but not transmitting if the captured transaction is canceled.

  The present invention also provides a billing computer system that includes a processor, a computer readable medium coupled to the processor, and an instruction set on the computer readable medium. The instruction set includes an authorization management module that stores consumer authorization, and a carrier billing module that is connected to the authorization management module and that can be executed by the processor, and includes an authorization API call that includes an authorization request that includes the MSISDN and the amount. Receive from server, determine selected carrier server from multiple carrier servers, send authorization request to selected carrier server based on amount, record authorized transaction based on authorization request, select authorization request carrier server Whether or not the capture transaction has been canceled because a capture API call including a capture request has been received, a cancel request has been received from the merchant server after the authorization request and before the capture request in response to the capture request If the captured transaction is not canceled , In response to the capture request, but transmits a charging request to a selected carrier server does not transmit if the captured transaction is canceled.

  The present invention will now be described by way of example with reference to the accompanying drawings.

1 is a block diagram illustrating a dual mode charging system according to an embodiment of the present invention. 3 is a flowchart showing two modes in which the system can operate. FIG. 5 is an interaction diagram illustrating an authorization method for an embodiment where authorization is canceled before becoming a captured transaction. FIG. 7 is an interaction diagram illustrating an authorization method for an embodiment where authorization is not canceled before it is captured and becomes a captured transaction. FIG. 11 is an interaction diagram illustrating a billing method when a mobile phone opt-in is performed by a consumer in a consumer mobile phone. FIG. 6 is an interaction diagram illustrating a billing method when a consumer opt-in is performed on a consumer mobile phone. FIG. 6 is an interaction diagram illustrating how a refund is processed after a capture method. It is a block diagram which shows the smart phone function of a consumer mobile phone. It is a block diagram of the machine of the form of the computer system which comprises a part of joining system of member store management.

  FIG. 1 of the accompanying drawings shows a dual-mode billing system 10 according to an embodiment of the present invention that includes a consumer mobile phone 12, a merchant server 14, a billing server 16, and a carrier server 18.

  The member store server 14 includes a user interface 20 and a charge management module 22. The user interface 20 allows consumers using the consumer mobile phone 12 or other consumer devices to purchase through an online store on the merchant server 14. During such a purchase, the consumer can purchase content at 24. In the billing and continuation mode of the system 10, the consumer may be asked to enter a personal identification number (PIN) at 26 for purchase. In the authorization and capture mode of the system 10, the consumer can cancel the purchase at 28 before the purchase is authorized and captured. The consumer can also request a refund for a previous purchase that has been completed at 30.

  The billing server 16 includes an authorization management module 32, an opt-in management module 34, a carrier billing module 36, and an SMS messaging module 38. Communication between the member store server 14 and the billing server 16 is mainly performed by the billing management module 22 of the member store server 14, the authorization management module 32 of the billing server 14, and the opt-in management module 34.

  The opt-in management module 34 is used in a billing and continuation method to determine if opt-in from the consumer is required. The SMS messaging module 38 is connected to the opt-in management module 34 and, at 40, includes an opt-in for purchase authorization that includes a PIN for the consumer to enter on the user interface 20 while using the consumer mobile phone 12. A short message service (SMS) text message containing the message is sent to the consumer mobile phone 12. The opt-in management module 34 is typically responsive to a signal requesting content billing received at the billing management modules 22-42. After the consumer enters the PIN code, billing management module 22 presents the PIN code to opt-in management module 34 at 44. The opt-in management module 34 then communicates with the carrier billing module 36 and the carrier billing module transmits the bill to the carrier server 18. Once the charge is confirmed by the carrier server 18 to the billing server 16, the SMS messaging module 38 sends a text message to the consumer mobile phone 12 at 46 with a purchase confirmation.

  In the authorization and capture mode of the system 10, the merchant server 14 sends an authorization request to the authorization management module 32 at 50. Next, the authorization management module 32 transmits an authorization request to the carrier server 18. The effect of the authorization request is that the carrier server 18 prepares funds for the purchase, but the purchase is not completed until it is captured.

  The transaction can also be canceled at the carrier server 18 after being authorized and before being captured. When the consumer requests to cancel the purchase at 28, the billing management module 22 sends a cancellation request to the authorization management module 32 at 52. Next, the authorization management module 32 transmits a cancel request to the carrier server 18 to release the funds reserved for purchase.

  If the consumer does not cancel the purchase, the merchant is authorized by referring to the previous authorization using the authorization-id (authorization ID) returned by the billing server and sending a capture request to the billing server. Capture funds (charge consumers). Next, the authorization management module 32 communicates with the carrier billing module 36, and the carrier billing module transmits the charge to the carrier server 18. Once the charge is confirmed by the carrier server 18, the billing server 16 is returned to and the SMS messaging module 38 sends a text message with a purchase confirmation to the consumer mobile phone 12 at 46.

  The billing server 16 further includes a carrier refund module 54. When the consumer requests a refund for a previous purchase through the merchant server at 30, the billing management module 22 sends a refund request to the carrier refund module 54 at 56. Next, the carrier refund module 54 communicates with the carrier server 18 for refund, and effectively adds funds to the account corresponding to the telephone number of the consumer mobile phone 12 on the carrier server 18 with respect to the carrier server 18. Let The carrier refund module 54 communicates with the billing server and sends a notification to the member store server to indicate success or failure of the refund.

  The billing server 16 includes a number of dedicated URLs that are all different. Each unified resource location specifier (URL) allows a separate application programmable interface (API) call from the merchant server 14 to the billing server 16. All of the requests at 42, 44, 50, 52, and 56 that are made from the merchant server 14 to the billing server 16 are separate API calls to the billing server 16's separate dedicated URL. Although not shown, the charging server 16 replies to the member store server 14 after each request to the charging server 16 by the member store server 14. When the billing server 16 communicates with the member store server 14, this is done via the URL specified in the member store server 14 for this purpose. The billing server 16 has a portal (not shown), which sets a callback URL that the carrier of the member store server 14 needs to use for the billing server 16 to communicate with the member store server 14. Can be used to

  FIG. 2 shows two modes of operation of the system 10. At 60, the system 10 operates in an authorization mode by executing an authorization method. In the authorization mode, the system 10 authorizes the transaction and prepares funds for the transaction without actually charging for the transaction. During the authorization mode, there remains a possibility that the transaction will be canceled. At 62, the system 10 activates the capture method to capture the authorized transaction as a charge if the transaction has not yet been cancelled.

  At 64, the system 10 operates in a billing mode by executing a billing method. The billing method 64 can result in a transaction billing as a result. If the opt-in management module 34 determines that opt-in is requested by the consumer, the billing server 16 sends a response indicating that the opt-in needs to be collected from the consumer before the billing request is processed. Return to server 14. The response from billing server 16 indicates the type of opt-in required for the consumer's country and carrier. If the opt-in asks the consumer to enter a PIN code received by the consumer from the SMS messaging module 38 of the billing server 16, the merchant server 14 collects the PIN code from the consumer at the consumer mobile phone 12. The PIN code needs to be returned to the billing server 16 using the continuation method. The billing server 16 checks the validity of the PIN code and then proceeds to complete the billing request by sending a billing request to the carrier server 18.

  Both the authorization and capture methods shown at 60 and 62 and the billing and continuation methods shown at 64 and 66 result in billing completion. The charge can be disabled if the system 10 performs a refund method at 68. The refund method 68 allows a full or partial refund of the transaction amount.

  The authorization method authorizes payment from the consumer. If possible, the authorization call should result in provision of funds from the user's account at the carrier server 18 rather than the actual billing. The request may also include an external-id (external ID) to associate with the merchant server 14 transaction.

  The authorization request is a synchronization request. While a request is made to the carrier server 18 to complete authorization, the request blocks. This is done to support the use case where merchant server 14 uses authorization as a means to authorize consumer access to content or services. If the authorization is successful, the member store server 14 provides the content or service. In this use case, the merchant server 14 typically allows the consumer to cancel the service within a specified period of time, in which case the merchant server 14 does not capture authorization. In other cases, if the consumer does not cancel, the member store server 14 captures the authorization and charges the consumer.

  Authorization includes limit checks (payments and velocities) by both billing server 14 and carrier server 18. The ability to prepare funds and the duration of preparation will vary from carrier server 18 to carrier server 18.

  FIG. 3 illustrates an example authorization method in which authorization is captured and canceled before becoming a captured transaction. At 100, the consumer selects content with the consumer mobile phone 12 and purchases it from the member store server 14. The consumer also chooses to pay by phone. In 102, the member store server 14 transmits an authorization API call including an authorization request to the dedicated authorization URL of the accounting server 16. At 104, the billing server 16 transmits an authorization request to the carrier server 18, and at 106, returns the authorization result to the member store server 14. If the authorization is successful, the merchant server 14 permits access to the content at 108. At 110, for example, assume that the consumer cancels the transaction before the end of the trial period. Thereafter, if the member store server 14 does not capture the authorization, the member store server 14 transmits a cancel request to the billing server 16 at 112 to cancel the unsettled authorization. In 114, the accounting server 16 notifies the carrier server 18 of cancellation of authorization. In 116, the accounting server 16 responds to the cancellation request in 112 with a cancellation confirmation.

  The accounting server 16 updates the data structure together with the accounting server 16 after all operations in FIG. Transactions are recorded as authorized, uncancelled and uncaptured after 102. After 112, the transaction is updated to reflect that it has been canceled. The data structure allows or disallows subsequent capture.

  It is necessary to input a request-id (request ID). The request-id (request ID) identifies a unique transaction event from the calling system. If the merchant server 14 sends two requests with the same request-id (request ID), both requests need to return the same response to the merchant server (assuming that the data in both requests are the same) Then). If a previously used request-id (request ID) is entered and the request data is different from the previous request, the billing server 16 will return an error for the latter request. Accordingly, when the calling system transmits a plurality of capture requests with the same data to the charging server 16 using the same request-id (request ID), the charging server 16 responds with “capture success” to each request. However, the funds are captured only once.

  Tables 1 and 2 show the request and response parameters for 102 authorization requests and 106 authorizations, respectively.

Table 1

Table 2

  In a normal authorization flow, the consumer selects a service product at the member store server 14. The member store server 14 obtains the telephone number and optionally the MNC and MCC of the carrier server 18. The member store server 14 makes an authorization API call to the dedicated URL of the billing server 16. The authorization API call presents an authorization request, including customer identification and purchase details, to the billing server 16. The billing server 16 confirms the validity of the request. If the request validation fails, the billing server 16 returns an appropriate error message and does not return an authorization-id (authorization ID). The billing server 16 performs payment limit and speed checks. If the payment or rate check fails or the MSISDN is blacklisted, the authorization fails and an appropriate error message is returned. The billing server 16 determines the selected carrier server 18 (using the provided MNC / MCC or performing an internal search from a plurality of carrier servers in the data store of the billing server 16) and uses these direct APIs. Use to present the authorization request to the carrier server 18.

  If the carrier server 18 only supports billing at the time of authorization, the authorization request will be treated as authorization and capture. The billing server 16 returns an authorization response including an authorization-id (authorization ID) used in a subsequent capture or cancellation request to the member store server 14. When the member store server 14 sends an external-id (external ID), the external-id (external ID) is stored together with the authorization-id (authorization ID).

  When the authorization returns an error that can be retried, the member store server 14 retries the authorization request after a specific retry-delay (retry delay) returned in the authorization response.

  If the response from the carrier server 18 indicates that the authorization is unsuccessful, the billing server 16 returns an instruction that the authorization fails and the request is terminated. The billing server 16 transmits the final transaction result as a callback.

  If the transaction is authorized, within the billing server 16, the transaction is authorized but recorded as uncaptured. The cancel API call includes a cancel request to cancel a transaction from a previously authorized customer and release any funds available at the carrier server 18. For merchant servers with billing systems that do not support individual authorization and capture, this request should result in a full refund as specified in the referenced authorization call.

  Tables 3 and 4 show the request and response parameters for the cancel signals 112 and 116 of FIG. 3, respectively.

Table 3

Table 4

  In a normal cancellation flow, the member store server 14 presents a cancellation request to cancel the previously acquired authorization, and sends an authorization authorization-id (authorization ID). The billing server 16 confirms the validity of the authorization-id (authorization ID) and activates a cancel API for the appropriate carrier server 18. Next, the billing server 16 returns the result code and message to the carrier server 18, and then transmits a final result callback to the carrier server 18 indicating that the transaction has been terminated due to cancellation of authorization.

  FIG. 4 illustrates an authorization method for an embodiment where a transaction is captured without being canceled before it is captured and becomes a captured transaction. The capture API call includes a capture request that confirms a previously authorized payment from the customer. The capture API call indicates that the customer order has been fulfilled and should result in the actual capture of funds from the customer account at the carrier server 18. This call is advisory if the carrier server 18 does not support individual authorization and capture operations. The billing server 16 records the capture event as a fulfillment instruction.

  The default action is to capture the full amount authorized. Regardless of whether the capture is full or partial, a successful capture will terminate the transaction (authorization). Capture needs to occur within the time limit for authorization.

  At 130, the consumer selects content on the consumer mobile phone 12 and purchases it from the member store server 14. The consumer also chooses to pay by phone. In 132, the member store server 14 transmits an authorization API call including an authorization request to the dedicated authorization URL of the accounting server 16. In 134, the billing server 16 transmits an authorization request to the carrier server 18, and returns the authorization result to the member store server 14 in 136 and includes an authorization-id (authorization ID). If authorization is successful, at 138, the member store server 14 permits access to the content.

  In 140, the member store server 14 transmits a capture request referring to the authorization-id (authorization ID) to the accounting server 16. At 142, billing server 16 determines whether the authorized transaction has been canceled. If the transaction has not been cancelled, the billing server 16 proceeds to the transaction and only sends a billing request to the carrier server 18. Therefore, if authorization is canceled, capture will be rejected. At 144, billing server 16 sends a billing request to carrier server 18 to complete the transaction and charge the consumer's account on carrier server 18. At 146, billing server 16 sends a confirmation text message to consumer mobile phone 12. In 148, the billing server 16 transmits a billing result notification to the member store server 14. If the billing is successful at 150, the merchant server 14 fulfills the consumer purchase.

  Tables 5 and 6 show the request and response parameters for the capture signal at 140 and 148 in FIG. 4, respectively.

Table 5

Table 6

  The capture request returns a capture-id (capture ID) different from the authorization-id (authorization ID). This authorization-id (authorization ID) allows multiple captures for a single authorization. Subsequent refunds can refer to a specific capture-id (capture ID) to be refunded.

  If the capture fails due to authorization timeout or consumer opt-in expiration, the billing server 16 returns a result code and message indicating the expiration. If the capture fails because the capture amount exceeds the authorized amount, the billing server 16 returns a result code and message indicating failure due to the excess amount, and does not return capture-id (capture ID). The capture can be retried with the correct amount. When the capture request returns a retry error, the billing server 16 can return a capture-id (capture ID) without returning a capture-id (capture ID) without returning a capture-id (capture ID).

  FIG. 5 illustrates a billing method that can be used in place of the two-step authorization and capture transaction method when the authorization and billing method is not appropriate. Billing performs the same risk checks as the authorization method. The billing method will also perform consumer authentication (opt-in) if necessary. In the billing server 16, if the request is approved for processing, that is, the request passes validation (field validation, security validation), passes risk check, Therefore, when presented to the carrier server 18, the billing method request returns a charge-id (billing ID). When billing is completed, the billing server 16 sends a callback notification to the member store server 14 along with the final status of the transaction. The billing server 16 can manage consumer opt-in as part of the billing request process. The billing server 16 will perform any suitable consumer opt-in flow based on the specific market and carrier server 18 requirements.

  The billing method of FIG. 5 shows a case where the mobile mobile phone 12 opts in for mobile transmission by the consumer. At 200, the consumer selects content with the consumer mobile phone 12 and purchases it from the member store server 14. The consumer also chooses to pay by phone. In 202, the member store server 14 makes a billing API call to the dedicated URL of the billing server 16. The billing API call sends a billing request to the billing server 16.

  In the case of a market or carrier server 18 where opt-in is required, at 204, billing server 16 sends a billing request to carrier server 18. If billing server 16 determines that opt-in is required for billing, billing server 16 sends a notification that opt-in is requested at 206 to merchant server 14 and responds “Y” at 208. A text message is transmitted to the consumer mobile phone 12 together with an instruction for. The member store server 14 transmits an SMS message to the consumer via the user interface 20, and displays that it is necessary to respond with a specific keyword. At 210, the consumer sends a reply text message containing the requested keyword to the billing server 16. The billing server 16 checks the validity of the keyword and sends a confirmation text message to the consumer mobile phone 12 at 212. At 214, the billing server 16 transmits a billing request to the carrier server 18, and at 216, a billing result notification is transmitted to the member store server 14. At 218, the merchant server 14 displays via the user interface 20 to the consumer confirmation that the billing has been successful and the purchase will be fulfilled.

  The notification transmitted at 206 includes the keyword displayed by the member store server 14. The keyword is a unique keyword generated by the billing server 16. The keyword received at 210 is validated against the keyword sent at 206 and the transaction continues if a comparison is preferred.

  FIG. 6 shows a billing method in the case where PIN code opt-in is executed by the consumer in the consumer mobile phone 12. 5 and 6, similar reference numerals are used for similar transactions. At 200, the consumer selects content and purchases it from the member store server 14. The consumer also chooses to pay by phone. In 202, the member store server 14 transmits a billing request to the billing server 16.

  If opt-in is not requested by the consumer, the billing server sends a billing request to the carrier server 18 at 204. If the billing server 16 determines that opt-in is required for billing, the billing server 16 sends a confirmation to the merchant server 14 that the opt-in is requested at 206 and a text message with a PIN code at 226. It transmits to the consumer mobile phone 12. At 228, the consumer uses the consumer mobile phone 12 to enter a PIN code into the user interface 20 provided by the merchant server 14. At 230, the member store server 14 sends a continuation request to the billing server 16 along with the PIN code entered by the consumer. Billing server 16 validates the PIN code and sends a confirmation text message to consumer mobile phone 12 at 212. At 214, the billing server 16 transmits a billing request to the carrier server 18, and at 216, a billing result notification is transmitted to the member store server 14. At 218, the merchant server 14 displays to the consumer confirmation that the billing is successful and that the purchase is fulfilled.

  The text message transmitted at 226 includes a unique PIN code generated by the billing server 16. The transaction continues only if the PIN code received at 230 is validated against the PIN code transmitted at 226 and a comparison is preferred.

  Table 7 shows the request parameters of the billing request in 202 of FIGS. 5 and 6, and Table 8 shows the response parameters of the notification in 216 of FIGS.

Table 7

Table 8

  In a normal authorization flow, the consumer selects a service product at the member store server 14. The member store server 14 obtains the telephone number and optionally the MNC and MCC of the carrier server 18. The member store server 14 makes an authorization API call to the dedicated URL of the billing server 16. The authorization API call presents an authorization request, including customer identification and purchase details, to the billing server 16. The billing server 16 confirms the validity of the request. If the request validation fails, the billing server 16 returns an appropriate error message and does not return an authorization-id (authorization ID). The billing server 16 performs payment limit and speed checks. If the payment or rate check fails or the MSISDN is blacklisted, the authorization fails and an appropriate error message is returned. The billing server 16 determines the selected carrier server 18 (using the transmitted MNC / MCC or performing an internal search from a plurality of carrier servers in the data store of the billing server 16), and uses these direct APIs. Use to present the authorization request to the carrier server 18.

  As can be seen from FIGS. 5 and 6, the continue operation continues the billing request waiting for the consumer to opt-in. Claims can be made through either the mobile opt-in of FIG. 5 (keyword response) or an additional opt-in via a PIN code (sent to the phone and entered by the customer at the merchant interface) as in FIG. A continuation call is used to indicate that it needs to be obtained from the customer.

  In the case of PIN code entry, the user interface 20 of FIG. 1 needs to instruct the consumer to enter the PIN code sent to his phone. The input PIN code is transmitted to the billing server 16 by a continuous call. Due to the successful return from this call to the member store server 14, the billing request can be continued. In either type of opt-in, when the transaction is completed, the billing server 16 sends a callback notification to the member store server 14 for each normal billing request process.

  The merchant server 14 can choose to use a polling approach for consumer opt-ins that require a keyword response. In this case, the merchant server 14 sends a continuation request (polling) on a recurring basis to determine whether the consumer response is successful.

  A claim requesting consumer opt-in is placed in a Consumer Configuration Pending state indicating that the claim has not been completed. If the consumer does not opt in within a predetermined time, the transaction will time out and be placed in a final failure state. The billing server 16 transmits a callback that conveys the final state of the transaction to the member store server 14.

  Tables 9 and 10 show request and response parameters for a continuation request between the member store server 14 and the billing server 16.

Table 9

Table 10

  The refund can be processed either after the captured payment described with reference to FIG. 3 or after the billing method described with reference to FIGS. FIG. 7 shows how a refund is processed after the capture method of FIG.

  At 300, the consumer requests a refund from the merchant server 14 via the user interface 20 of FIG. At 302, the merchant server 14 sends a refund request to the billing server 16 that references a specific charge by including a capture-id (capture ID) that functions as a transaction identifier. Billing server 16 determines the same selected carrier server 18 from the refund call and sends a refund request to carrier server 18 at 304. The refund request includes the amount of the original transaction to be refunded, or a lower amount in the case of a partial refund. In 306, the accounting server 16 transmits a chargeback notification indicating the result and amount of chargeback to the member store server 14. At 308, the member store server 14 invalidates the purchase and updates the user's account on the member store server 14 to reflect the refund.

  Tables 11 and 12 show the 302 refund request and chargeback 306 request and response parameters, respectively. If the refund is in response to a billing method, it will be a charge-id (billing ID) instead of a capture-id (capture ID).

Table 11

Table 12

  The refund request received at 302 includes a reason code. The billing server 16 determines whether the reason code is a valid reason code and processes a refund only when there is a valid reason code. Next, the billing server 16 uses the capture-id (capture ID) to determine the original billing and the specific carrier server 18 that has processed the original billing.

  If the refund fails because an invalid reason code is provided or no reason code is provided, the billing server 16 does not return a refund-id (refund ID), but only returns a result code and a result message. Similarly, if the refund fails because the refund amount exceeds the amount of the referenced transaction, the billing server 16 does not return a refund-id (refund ID), but only returns a result code and a result message. When a partial refund is requested by the member store server 14, the billing server 16 obtains a partial refund and returns a refund-id (refund ID), but this capture-id (capture ID) is returned. You can't get any more refunds.

  As described above, the billing server 16 performs consumer authentication (opt-in) as required by the specific market and carrier server 18 requirements. The consumer opt-in managed by the billing server 16 is provided only for billing requests. If the billing server 16 manages opt-in, the billing server 16 will provide a response to the billing request from the merchant server 14 indicating that a consumer opt-in for payment is required. There are two forms of consumer opt-in: PIN-based and keyword response. Based on market and carrier server 18, billing server 16 will provide the type of opt-in required. In the case of PIN code-based opt-in, when a consumer enters a PIN in the PIN input form provided by the member store server 14, the member store server 14 will continue using the continuation request (send the PIN code). By).

  The billing server 16 can also support automatic authentication if the merchant server 14 sends the consumer's unique identifier along with these phone numbers. In this case, the billing server 16 will check whether consumer authentication has been previously processed for the consumer during the configurable period. If so, the billing server 16 can accept the previous authentication and does not need to authenticate the consumer again.

  The following methods support idempotency: authorization, capture, cancellation, billing, and refund. If the idempotent method is called, the action is performed only once, even if multiple calls are made. If two billing requests are made for the same request-id (request ID), the account is billed only once and both requests get the same response. If successful, all calls will return the expected success response, but the actual charge will be made only once. All calls to the idempotent method must include a unique value in the request-id (request ID) parameter.

  The accounting server 16 API includes both synchronous requests and asynchronous requests. The authorization request is a synchronization request. While a request is made to the carrier server 18 to complete authorization, the request blocks. Synchronous authorization supports many use cases that share the need to provide a response while a user is waiting for access to an application or content.

  Capture and billing are asynchronous requests. These requests are received and processed by the billing server 16, which provides an immediate response indicating whether the request has been approved. The approved request will return a response to indicate that the request has been successfully processed, and the response code and message will indicate that the transaction is in progress. Regardless of success or failure, when the transaction processing ends, the billing server 16 transmits a callback notification to the member store server 14 together with the transaction processing details.

  The billing server 16 transmits a hypertext transfer protocol (HTTP) POST request to the designated issuer URL (“callback URL”) to convey the transaction status information. Callback notification is asynchronous. The member store server 14 can set its own callback URL using the issuer portal of the accounting server 16. Callback notifications are specific use cases, such as asynchronous transactions with billing and capture request completion (success or failure), and carrier-based refunds that receive notifications for each refunded transaction received from the carrier server 18. May be required regarding.

  FIG. 8 is a block diagram illustrating the consumer mobile phone 12 and shows a touch-sensitive display 1120 or “touch screen” for convenience. The consumer mobile phone 12 includes a memory 1020 (which may include one or more computer readable storage media), a memory controller 1220, one or more processing units (CPUs) 1200, a peripheral interface 1180, RF circuit configuration 1080, audio circuit configuration 1100, speaker 1110, microphone 1130, input / output (I / O) subsystem 1060, other input or control device 1160, and external port 1240. These components communicate on one or more communication buses or signal lines 1030.

  The various components shown in FIG. 8 can be implemented in hardware, software, or a combination of hardware and software including one or more signal processing and / or application specific integrated circuits.

  The memory 1020 can include high-speed random access memory, and can also include non-volatile memory such as one or more magnetic disk storage devices, flash memory devices, or other non-volatile solid state memory devices. Access to the memory 1020 by other components of the consumer mobile phone 12, such as the CPU 1200 and the peripheral interface 1180, is controlled by the memory controller 1220.

  The peripheral interface 1180 connects input / output peripheral devices of the device to the CPU 1200 and the memory 1020. One or more processors 1200 execute or implement various software programs and / or instruction sets stored in memory 1020 to perform various functions of consumer mobile phone 12 and process data. .

  The RF (radio frequency) circuit configuration 1080 transmits and receives RF signals, also called electromagnetic signals. The RF circuitry 1080 converts between electrical and electromagnetic signals and communicates with communication networks and other communication devices via the electromagnetic signals. RF circuitry 1080 includes an antenna system, an RF transceiver, one or more amplifiers, a tuner, one or more oscillators, a digital signal processor, a CODEC chipset, a subscriber identity module (SIM) card, memory, and others. Including known circuit configurations for performing these functions. The RF circuitry 1080 may be a network such as the Internet, also called the World Wide Web (WWW), a network such as an intranet, and / or a cellular telephone network, a wireless local area network (LAN) and / or a metropolitan area network (MAN). It can communicate with wireless networks and other devices by wireless communication. The wireless communication can use any of a plurality of communication standards, protocols, and technologies known in the art.

  Audio circuitry 1100, speaker 1110, and microphone 1130 provide an audio interface between the user and consumer mobile phone 12. The audio circuitry 1100 receives audio data from the peripheral interface 1180, converts the audio data into an electrical signal, and sends the electrical signal to the speaker 1110. The speaker 1110 converts electrical signals into human audible sound waves. Audio circuitry 1100 also receives electrical signals converted by the microphone 1130 from sound waves. Audio circuitry 1100 converts electrical signals to audio data and transmits the audio data to peripheral interface 1180 for processing. Also, the audio circuitry 1100 may be detachable from the audio circuitry 1100, such as an audio input / output peripheral device, such as an output-only headphone, or an output (eg, one or both ear headphones) and an input (eg, a microphone). It also includes a headphone jack that functions as an interface with a headset equipped with both.

  The I / O subsystem 1060 connects input / output peripherals on the consumer mobile phone 12, such as the touch screen 1120 and other input / control devices 1160, to the peripheral interface 1180. The I / O subsystem 1060 includes a display controller 1560 and one or more input controllers 1600 for other inputs or control devices. One or more input controllers 1600 send and receive electrical signals to and from other inputs or control devices 1160. Other input / control devices 1160 include physical buttons (eg, push buttons, rocker buttons), dials, slider switches, joysticks, click wheels, and everything else that functions as part of the interface. Can do. The input controller 1600 can be connected to any of a keyboard, an infrared port, a USB port, and a pointer device such as a mouse. One or more buttons may include up / down buttons for volume control of speaker 1110 and / or microphone 1130. The one or more buttons can include a push button. By quickly pressing the push button, the touch screen can be unlocked, or a process using a gesture on the touch screen to unlock the device can be initiated. The consumer mobile phone 12 can be turned on or off by long-pressing the push button. The touch screen 1120 is used to implement virtual buttons or soft buttons and one or more soft keyboards.

  The touch sensitive touch screen 1120 provides an input interface and an output interface between the device and the user. The display controller 1560 transmits and receives electrical signals to and from the touch screen 1120. Touch screen 1120 displays visual output to the user. The visual output can include graphics, text, icons, video, and any combination thereof (collectively referred to as “graphics”). In some embodiments, some or all of the visual output can correspond to user interface objects, further details of which are described below.

  Touch screen 1120 includes a touch-sensitive surface, sensor, or series of sensors that receives input from a user based on tactile and / or tactile contact. Touch screen 1120 and display controller 1560 (along with any associated modules and / or instruction set in memory 1020) detect touches (and any movement or breaks in touch) on touch screen 1120, and The detected contact is converted into an interaction with a user interface object (eg, one or more soft keys, icons, web pages, or images) displayed on the touch screen. In the exemplary embodiment, the point of contact between touch screen 1120 and the user corresponds to the user's finger.

  The touch screen 1120 can use LCD (Liquid Crystal Display) technology or LPD (Published Polymer Display) technology, but in other embodiments, other display technologies can be used. Touch screen 1120 and display controller 1560 can detect touch and any movement or interruption of movement using any of a plurality of touch sensing techniques now known or later developed, and the techniques are limited. It includes, but is not limited to, capacitive, resistive, infrared, and surface acoustic wave technologies, and other elements for determining one or more contact points with other proximity sensor arrays or touch screen 1120.

  A user can make contact with touch screen 1120 using any suitable object or accessory, such as a stylus, fingers, and the like. In some embodiments, the user interface is designed to work primarily with finger-based touches and gestures, which is due to the greater range of finger touches on the touch screen, so stylus-based input The accuracy is greatly reduced. In some embodiments, the device converts the rough finger-based input into a precise pointer / cursor position or command to perform the action desired by the user.

  The consumer mobile phone 12 also includes a power system 1620 for powering various components. The power system 1620 includes a power management system, one or more power sources (eg, battery, alternating current (AC)), charging system, power failure detection circuit, power converter or inverter, power status indicator (eg, light emitting diode (LED)). ), And any other components related to power generation, management, and distribution in portable devices.

  Software components stored in the memory 1020 include an operating system 1260, a communication module (or instruction set) 1280, a touch / motion module (or instruction set) 1300, a graphics module (or instruction set) 1320, a text input module (or An instruction set) 1340 and an application (or instruction set) 1360.

  An operating system 1260 (eg, an embedded operating system such as Darwin, RTXC, LINUX®, UNIX®, OS X, WINDOWS®, or VxWorks) is a common system task ( For example, it includes software components and / or drivers for controlling and managing memory management, storage device control, power management, etc., to facilitate communication between various hardware and software components.

  The communication module 1280 facilitates communication with other devices on one or more external ports 1240 and various software for processing data received by the RF circuitry 1080 and / or the external port 1240. Also includes components. An external port 1240 (eg, Universal Serial Bus (USB), FIREWIRE, etc.) is configured to connect directly to other devices or indirectly over a network (eg, Internet, wireless LAN, etc.). The

  Contact / motion module 1300 may detect contact with touch screen 1120 (in conjunction with display controller 1560) and other touch-sensitive devices (eg, a touchpad or physical click wheel). The contact / motion module 1300 determines whether a contact has occurred, determines whether there has been a contact motion, tracks the movement across the touch screen 1120, and whether the contact has been interrupted (ie, the contact has stopped). Including various software components for performing various operations associated with contact detection, such as determining whether or not. Determining the movement of the contact point may include determining the speed (magnitude), speed (magnitude and direction), and / or acceleration (change in magnitude and / or direction) of the contact point. it can. These actions can be applied to a single contact (eg, contact with one finger) or to multiple simultaneous contacts (eg, “multi-touch” / contact with multiple fingers). Touch / motion module 1300 and display controller 1560 also detect touch on the touchpad.

  Graphics module 1320 includes various known software components for rendering and displaying graphics on touch screen 1120, and includes components for changing the brightness of the displayed graphics. As used herein, the term “graphics” includes any object that can be displayed to the user, including text, web pages, icons (such as user interface objects including softkeys), digital images, videos, animations, And the like.

  Text input module 1340, which can be a component of graphics module 1320, can be used in various applications (eg, contacts, email, IM, blogs, browsers, and any other application that requires text input). Provide a soft keyboard for entering Application 1360 can include a mobile application 208.

  FIG. 9 illustrates a schematic diagram of a machine in an exemplary form of a computer system 900 in which an instruction set can be executed in order to cause the machine to execute any one or more of the methodologies disclosed herein. ing. In alternative embodiments, the machine can operate as a stand-alone device or can be connected to other machines (eg, a network connection). In a network deployment, a machine can operate as a server or client machine in a server-client network environment or as a peer machine in a peer-to-peer (or distributed) network environment. A machine specifies a personal computer (PC), tablet PC, set-top box (STB), personal digital assistant (PDA), mobile phone, web appliance, network router, switch or bridge, or an action to be performed by the machine It can be any machine capable of executing an instruction set (sequential or otherwise). Further, although only one machine is illustrated, the term “machine” individually refers to an instruction set (or sets) for performing any one or more of the methodologies described herein. Or it should be taken to include any set of machines that run together.

  An exemplary computer system 900 includes a processor 930 (eg, a central processing unit (CPU)), a graphics processing unit (GPU), or both, and a main memory 932 (eg, read only memory (ROM), flash memory, etc. Dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), etc., and static memory 934 (eg, flash memory, static random access memory (SRAM, etc.)), These are configured to communicate with each other via a bus 936.

  Computer system 900 can further include a video display 938 (eg, a liquid crystal display (LCD) or a cathode ray tube (CRT)). Computer system 900 also includes an alphanumeric input device 940 (eg, a keyboard), a cursor control device 942 (eg, a mouse), a disk drive unit 944, a signal generator 946 (eg, a speaker), and a network interface device 948. Can also be included.

  The disk drive unit 944 includes a machine-readable medium 950 that stores one or more instruction sets 952 (eg, software) that embody any one or more of the methodologies or functions described herein. Including. The software may also reside, in whole or at least in part, in the main memory 932 and / or in the processor 930 during execution of this instruction by the computer system 900, with the memory 932 and processor 930 being machine-readable media. Can also be configured. The software can further be sent and received over the network 954 via the network interface device 948.

  In the exemplary embodiment, instructions 952 are shown as being on a single medium, but the term “machine-readable medium” may refer to a single medium or multiple media that store one or more instruction sets (eg, Centralized or distributed database or data store, and / or associated cache and server). The term “machine-readable medium” also has the ability to store, encode, or retain a set of instructions for execution by a machine, which causes a machine to execute any one or more of the methodologies herein. Should be construed to include such media. Thus, the term “machine-readable medium” should be construed to include, but is not limited to, solid state memory, optical and magnetic media.

  While specific exemplary embodiments have been described and illustrated in the accompanying drawings, such embodiments are merely illustrative and are not intended to limit the invention, and those skilled in the art will appreciate modifications. It should be understood that the present invention is not limited to the specific configuration and arrangement shown and described.

12 Consumer mobile phone 14 Merchant server 16 Billing server 18 Carrier server 200 Consumer selects content 202 Billing (MSISDN, country, amount)
204 Billing request 206 Billing response (opt-in required)
208 Consumer opt-in SMS (Respond “Y” to purchase)
210 Consumer responds with “Y” 212 Billing confirmation SMS
214 Billing request 216 Billing server sends billing result notification to member store 218 Member store fulfills consumer purchase

Claims (20)

A method of processing a claim,
Receiving from the merchant server a billing API call including the MSISDN and the amount by the billing server;
Determining a selected carrier server from a plurality of carrier servers by the billing server;
In response to the billing API call, the billing server returns a response to the merchant server indicating that consumer opt-in is requested;
The billing server transmits a text message indicating that authorization is requested to the consumer telephone by the MSISDN, and one of the response to the member store server and the text message is a PIN code or a keyword A stage containing data elements of the form
Receiving a data element in the form of a PIN code or keyword by the billing server;
Validating the received data element with respect to the transmitted data element by the billing server;
Sending a billing request including the MSISDN and amount to the selected carrier server by the billing server, wherein the billing request to the carrier server is sent only after successful validation of the data element; Stages,
Returning a billing result callback notification including an indication of approval or failure of the billing request to the merchant server by the billing server. The method of claim 1, wherein the billing API call is received at a URL of the billing server. The claim API call includes a request-id (request ID) sent by the member store server, and the charge result callback notification includes the request-id (request ID). The method described in 1. The billing API call includes merchant-id (member store ID assigned by the billing server), consumer-ip-address (caller's consumer IP address), service-id (ID provided by the member store server), country (country name code). ), Currency (currency code), item-description (description of the purchased product), and request-id (request ID assigned by the merchant server, which must be unique). The method described in 1. The selected carrier server is detected from the billing API call including at least one of a carrier name, mcc (mobile country code) and mnc (mobile network code). the method of. 2. The billing result callback notification includes a charge-id (billing ID assigned by a billing server), a result-code (result of the billing request), and a result-message (description of the result). The method described in 1. The method of claim 1, wherein the billing result callback notification is sent to a URL of the member store server. The billing request includes a request-id (request ID), and if the billing request fails, the method includes:
A billing API call with a new request-id (request ID) is received from the merchant server by the billing server so that the billing server does not return the same indication of the billing request failure, MSISDN, and amount Stages,
Sending a billing request including the MSISDN and amount received in the billing API call with the new request-id (request ID) to the selected carrier server by the billing server;
Returning a billing result callback notification including an indication of approval or failure of the billing request based on the new request-id (request ID) to the member store server by the billing server. The method according to claim 1. The method further includes receiving a continuation request including a PIN code from the member store server at the charging server, wherein the validation is performed by the charging server transmitting the PIN code received in the continuation request as the text message. The validity check is performed on the PIN code, and the billing request to the carrier server is transmitted only after the validity check of the PIN code of the continuation request is successful. The method of claim 1. The text message indicates that a response in the form of a keyword is required;
The method further comprises receiving a text message including a keyword from the consumer telephone at the billing server, wherein the validation includes the keyword received in the text message as the keyword of the response to the merchant server. The method according to claim 1, further comprising: performing validation on the carrier server and sending the billing request to the carrier server only after successful validation of the keyword in the text message. the method of. Receiving a refund call from the member store server by the billing server;
Determining the selected carrier server in response to the refund call by the billing server;
In response to the refund call from the member store server, the billing server sends a refund request including an amount to the selected carrier server;
The method of claim 1, further comprising: sending a chargeback notification to the merchant server by the billing server in response to the refund call from the merchant server. 12. The claim result callback notification has a charge-id (billing ID), and the refund call has the charge-id (billing ID) of the billing result callback notification. The method described. The billing server further includes determining whether the refund call includes a valid reason code, wherein the refund request is transmitted when the refund call includes a valid reason code. The method of claim 11, wherein The refund call includes a merchant-id (merchant ID assigned by the billing server), a charge-id (billing ID of the payment for refund), a reason-code (reason code of the billing server) and a request-id 12. The method of claim 11 including a request ID assigned by the store server, which must be unique. The chargeback notification includes a refund-id (ID of a refund transaction created by a billing server), a result-code (result of the refund request), and a result-message (description of the result). Item 12. The method according to Item 11. A non-transitory computer readable medium having stored thereon an instruction set that performs a method of processing a claim when executed by a processor of a computer, the method comprising:
Receiving from the merchant server a billing API call including the MSISDN and the amount by the billing server;
Determining a selected carrier server from a plurality of carrier servers by the billing server;
In response to the billing API call, the billing server returns a response to the merchant server indicating that consumer opt-in is requested;
The billing server transmits a text message indicating that authorization is requested to the consumer telephone by the MSISDN, and one of the response to the member store server and the text message is a PIN code or a keyword A stage containing data elements of the form
Receiving a data element in the form of a PIN code or keyword by the billing server;
Validating the received data element with respect to the transmitted data element by the billing server;
Sending a billing request including the MSISDN and amount to the selected carrier server by the billing server, wherein the billing request to the carrier server is sent only after successful validation of the data element; Stages,
Returning a billing result callback notification including an indication of approval or failure of the billing request to the merchant server by the billing server. A billing computer system,
A processor;
A computer readable medium connected to the processor;
An instruction set on the computer-readable medium,
Receiving a billing API call including the MSISDN and the amount from the merchant server, determining a selected carrier server from a plurality of carrier servers, and responding to the billing API call with a response indicating that consumer opt-in is required Return to the merchant server and send a text message indicating that authorization is required for the consumer phone in the MSISDN, and one of the response to the merchant server and the text message is in the form of a PIN code or keyword Including a data element, receiving a data element in the form of a PIN code or keyword, validating the received data element against the transmitted data element, and only after successful validation of the data element A billing request including the MSISDN and the amount is sent to the selected carrier server; To return the claimed results callback notification including an indication of the request for approval or failure to the merchant server, the billing computer system which comprises a carrier billing module executable by the processor. The instruction set is
An opt-in management module for storing consumer opt-ins;
An SMS messaging module connected to the opt-in management module;
Further including
In response to the billing API call, the carrier billing module returns a response to the merchant server indicating that a consumer opt-in in the form of a PIN code is required, and the SMS messaging module is a consumer of the MSISDN The carrier billing module receives a continuation request including a PIN code from the member store server, and the PIN code received in the continuation request is transmitted as the PIN code. The billing request according to claim 17, wherein the billing request is transmitted to the carrier server only after the validity of the PIN code of the continuation request is successfully verified. Computer system. The instruction set is
An opt-in management module,
An SMS messaging module connected to the opt-in management module;
Further including
In response to the billing API call, the carrier billing module indicates that a consumer opt-in in the form of a keyword is required and returns a response including the keyword to the merchant server, the SMS messaging module Sending a text message indicating that a response in the form of a keyword is required to the MSISDN consumer phone, receiving a message containing the text message from the consumer phone, and the carrier billing module The charge to the carrier server is performed only after the validity of the keyword in the text message has been validated with respect to the keyword of the response to the member store server after the keyword received at Characterized by a request being sent Billing computer system according to Motomeko 17. Receiving a refund call from the merchant server, determining the selected carrier server in response to the refund call, and responding to the refund call from the merchant server in response to a refund request including an amount 18. The carrier refund module of claim 17, further comprising a carrier refund module that transmits to a selected carrier server and transmits a chargeback notification to the member store server in response to the refund call from the member store server. Billing computer system.

Images