Abstract: A phone-on-file opt-in method is described. A phone-on-file opt-in request is received at the billing server including a msisdn and a merchant supplied unique consumer identifier. The billing server confirms the phone-on-file opt-in with a consumer device and records a phone-on-file opt-in status as active if the first phone-on-file is confirmed. A charge method includes receiving, at the billing server, a charge API call from a merchant server including at least one identifier and an amount, determining a phone-on-file opt-in status corresponding to the identifier at the billing server and transmitting a request to charge a user account to a carrier server if the phone-on-file opt-in status is active, but not if the phone-on-file opt-in status is inactive, the request including an amount corresponding to the amount received in the charge API call.

Abstract: A phone-on-file opt-in method is described. A phone-on-file opt-in request is received at the billing server including a msisdn and a merchant supplied unique consumer identifier. The billing server confirms the phone-on-file opt-in with a consumer device and records a phone-on-file opt-in status as active if the first phone-on-file is confirmed. A charge method includes receiving, at the billing server, a charge API call from a merchant server including at least one identifier and an amount, determining a phone-on-file opt-in status corresponding to the identifier at the billing server and transmitting a request to charge a user account to a carrier server if the phone-on-file opt-in status is active, but not if the phone-on-file opt-in status is inactive, the request including an amount corresponding to the amount received in the charge API call.

Abstract: 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.

Abstract: A phone-on-file opt-in method is described. A phone-on-file opt-in request is received at the billing server including a msisdn and a merchant supplied unique consumer identifier. The billing server confirms the phone-on-file opt-in with a consumer device and records a phone-on-file opt-in status as active if the first phone-on-file is confirmed. A charge method includes receiving, at the billing server, a charge API call from a merchant server including at least one identifier and an amount, determining a phone-on-file opt-in status corresponding to the identifier at the billing server and transmitting a request to charge a user account to a carrier server if the phone-on-file opt-in status is active, but not if the phone-on-file opt-in status is inactive, the request including an amount corresponding to the amount received in the charge API call.

Abstract: A phone-on-file opt-in method is described. A phone-on-file opt-in request is received at the billing server including a msisdn and a merchant supplied unique consumer identifier. The billing server confirms the phone-on-file opt-in with a consumer device and records a phone-on-file opt-in status as active if the first phone-on-file is confirmed. A charge method includes receiving, at the billing server, a charge API call from a merchant server including at least one identifier and an amount, determining a phone-on-file opt-in status corresponding to the identifier at the billing server and transmitting a request to charge a user account to a carrier server if the phone-on-file opt-in status is active, but not if the phone-on-file opt-in status is inactive, the request including an amount corresponding to the amount received in the charge API call.

Abstract: A phone-on-file opt-in method is described. A phone-on-file opt-in request is received at the billing server including a msisdn and a merchant supplied unique consumer identifier. The billing server confirms the phone-on-file opt-in with a consumer device and records a phone-on-file opt-in status as active if the first phone-on-file is confirmed. A charge method includes receiving, at the billing server, a charge API call from a merchant server including at least one identifier and an amount, determining a phone-on-file opt-in status corresponding to the identifier at the billing server and transmitting a request to charge a user account to a carrier server if the phone-on-file opt-in status is active, but not if the phone-on-file opt-in status is inactive, the request including an amount corresponding to the amount received in the charge API call.

Abstract: A phone-on-file opt-in method is described. A phone-on-file opt-in request is received at the billing server including a msisdn and a merchant supplied unique consumer identifier. The billing server confirms the phone-on-file opt-in with a consumer device and records a phone-on-file opt-in status as active if the first phone-on-file is confirmed. A charge method includes receiving, at the billing server, a charge API call from a merchant server including at least one identifier and an amount, determining a phone-on-file opt-in status corresponding to the identifier at the billing server and transmitting a request to charge a user account to a carrier server if the phone-on-file opt-in status is active, but not if the phone-on-file opt-in status is inactive, the request including an amount corresponding to the amount received in the charge API call.

Abstract: A phone-on-file opt-in method is described. A phone-on-file opt-in request is received at the billing server including a msisdn and a merchant supplied unique consumer identifier. The billing server confirms the phone-on-file opt-in with a consumer device and records a phone-on-file opt-in status as active if the first phone-on-file is confirmed. A charge method includes receiving, at the billing server, a charge API call from a merchant server including at least one identifier and an amount, determining a phone-on-file opt-in status corresponding to the identifier at the billing server and transmitting a request to charge a user account to a carrier server if the phone-on-file opt-in status is active, but not if the phone-on-file opt-in status is inactive, the request including an amount corresponding to the amount received in the charge API call.

Abstract: 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.

Abstract: A transaction is authorized by receiving an authorize API call from a merchant server, detecting a select carrier server, and transmitting an authorize request to the select carrier server. The carrier server will then reserve an amount of funds based on the authorization request. The authorized transaction is then recorded based on the authorize request. The consumer may then request to cancel the transaction. If a capture request is received, a determination is made whether the cancel request has been received and whether the authorized transaction has been cancelled. If the transaction has not been cancelled, a billing request is transmitted to the carrier server so that the carrier server charges for the transaction.