US20220156710A1

Movatterモバイル変換

Info

Publication number: US20220156710A1
Application number: US17/526,113
Authority: US
Inventors: Jack Shauh
Original assignee: Individual
Current assignee: Individual
Priority date: 2020-11-15
Filing date: 2021-11-15
Publication date: 2022-05-19

Abstract

An electronic mobile recurring billing and mobile event triggered billing method using a payment processing server programmed to effectuate the operations of receiving from a network device a registration order as the basis for automatically establishing a payment configuration including a subscription ID with associated payment information, and a mobile identity to a mobile payment device. The payment process server determines a payment requirement for the subscription ID, retrieves payment information from a database using the subscription ID and sends a payment request message to the mobile payment device for payment. A Payment request message can be sent in SMS/MMS or email and can include an URL with embedded payment information.

Description

CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit of U.S. Provisional Application No. 63/113,916, filed 15 Nov. 2020.

FIELD OF THE INVENTION

This invention relates to mobile payment systems.

More particularly, the present invention relates to remote mobile payment for recurring and event triggered payments and the like.

BACKGROUND OF THE INVENTION

In the payments industry, mobile payments systems are becoming more widely used. Mobile payment applications as a virtual credit/debit card are starting to be provided to mobile devices such as smart phones, tablets, watches and other wearable devices, and the like. Mobile payment methods currently include Apple Pay, Android Pay, Samsung Pay etc. Mobile payment can provide strong security to prevent fraud by implementing EMV (Europay, MasterCard and Visa) Integrated Circuit Card Specifications for Payment Systems. Furthermore, mobile payment can provide strong security by implementing EMV Payment Tokenization Specifications, or a vendor specific payment token scheme.

In today's payment environment, the customer can make a subscription order for products or services of a recurring or an event triggered nature. For example, the customer can place a subscription order for vitamin supplements of a recurring nature, which requires payment at each recurring period. Or the customer can purchase a new refrigerator water filter to replace the old one when the old water filter's filtration capability reaches the 10% threshold, which causes the filter-replacement event to be triggered. To pay for the purchase in today's payment environment, the customer provides payment information such as credit or debit card number, card holder name, expiry date, etc. to the merchant's website through his/her web browser of the customer device and the merchant server stores customer's card information in the database for future charge. For example, the customer device can be a PC or smart phone. When the scheduled recurring payment is due or the event to replace a part is triggered, e.g. ordered by the customer, the merchant can send an authorization request with payment information, and the amount to pay to the payment network. After the card issuing bank approves the transaction, the merchant will then ship the merchandise to the customer. This purchase process can be used to acquire physical merchandise. Alternatively, recurring payment can also be for recurring bill payment such as mortgage payments or utilities bill payments and the like.

While effective, this method is not secure. Card information must be given to the merchants. This card information is then stored by the merchant for future payments. Moreover, the customers may not receive a charge reminder from the merchant prior to each recurring payment or event triggered payment. Therefore, a more secure solution is needed. Additionally, because the customer's card is automatically charged at each recurring period (or at each event triggered event), and the customer does not authorize each individual payment charge, the payment process is prone to future dispute with regards to if customer actually gives consent to each payment charge.

It would be highly advantageous, therefore, to remedy the foregoing and other deficiencies inherent in the prior art.

It is an object of the present invention to provide a secure recurring and event triggered payment method and system.

Another object of the present invention is to provide a secure recurring and event triggered payment method allowing payer to approve each payment.

SUMMARY OF THE INVENTION

Also provided is an electronic billing system including the steps of a payment processing server serving a networked device over an internet, a non-transitory computer readable storage medium that is not a signal, storing computer executable instructions that when executed by the payment processing server cause the processor to effectuate operations comprising receiving from the networked device a registration order subscribing to one of a recurring payment configuration and an event trigger payment configuration; and automatically establishing a payment configuration based on the registration order, the payment configuration comprising a subscription ID, payment information associated with the subscription ID, and a mobile identity of a mobile payment device having mobile payment capability and associated with the subscription ID; storing the payment configuration in a database; determining a payment requirement for the subscription ID; retrieving payment information from the database using the subscription ID; and sending a payment request message to the mobile payment device using the mobile identity associated with the subscription ID.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and further and more specific objects and advantages of the instant invention will become readily apparent to those skilled in the art from the following detailed description of a preferred embodiment thereof taken in conjunction with the drawings, in which:

FIG. 1 is simplified block diagram of a recurring and/or event triggered payment system according to the present invention;

FIG. 2 is a schematic of a recurring payment procedure according to the present invention;

FIGS. 3aand 3billustrate examples of a web portal to subscribe for recurring purchase/payment according to the present invention;

FIG. 4 is a schematic of an event triggered payment procedure according to the present invention;

FIG. 5 is a flow chart a recurring payment procedure according to the present invention;

FIG. 6 is a flow chart an event trigger payment procedure according to the present invention; and

FIG. 7 is a simplified block diagram of functional modules in the payment processing server according to the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Turning now to the drawings in which like reference characters indicate corresponding elements throughout the several views, attention is first directed toFIG. 1 which illustrates a recurring and/or event triggeredpayment system110 according to the present invention.System110 includes aninternet112, such as the World Wide Web commonly used globally, to facilitate communication between various elements as will be described presently. Amerchant device114 is a server or other device capable of communicating with other devices or a server throughinternet112.Merchant device114 is used by the seller of merchandise or services (merchant) to provide a portal throughinternet112, thereby providing access for the customer to subscribe to a recurring purchase configuration and/or an event triggered purchase configuration. Amobile payment device115, used by the customer, is capable of making mobile payments using platforms such as Apple Pay, Google Pay and the like.Mobile payment device115 can connect tointernet112 to receive payment requests and send payment tokens (payment token is the surrogate card number or the device PAN (Primary Account Number) as defined in EMVCO tokenization spec, Apple Pay, Google Pay, etc.) to request transaction authorization. For example,mobile payment device115 can be a smart phone, a wearable device, a tablet, a car dashboard and the like. Internet112 can be accessed through 2G/3G/4G/5G cellular network, WiFi, LAN, etc., and the like. Commonly, smart phone vendors include mobile wallets (also referred to as platforms) in the smart phones, such as Apple Pay in iPhones, Google Pay in Android phones, which can store a payment token (this is the surrogate card number as defined in EMVCO tokenization spec, Apple Pay, Google Pay, etc.) in a secure element of the platform to prevent the real card number from being stolen. The Internet of things (IoT) are physical objects (or groups of such objects) that are embedded with sensors, processing ability, software, and other technologies, and that connect and exchange data with other devices and systems over the Internet or other communications networks. An IoTDevice116, used in the present system, is a device that can send UUID (a unique identifier to identify an instance of the merchandise) to initiate event triggered purchases throughinternet112. Again,internet112 can be accessed by 2G/3G/4G/5G cellular network, WiFi, LAN, etc., and the like.

Referring now toFIG. 2, an example of a recurring payment procedure is shown for making payments when using the recurring payment configuration. A dashed box circlingmerchant device114 andpayment processing server118 illustrates thatpayment processing server118 can be part ofmerchant device114. Alternatively,payment processing server118 can belong to a 3rd party company that provides payment service to the merchant.

The process begins withmerchant device114 receiving a subscription to a payment configuration. In this case, a recurring purchase subscription order is submitted by a customer, designatedstep120 to subscribe to the recurring purchase configuration. The recurring purchase subscription order includes information provided by the customer such as a recurring payment schedule, mobile identity (e.g. mobile phone number) formobile payment device115, email address, shipping address, etc., and the like. For example, the customer can usemobile payment device115 to connect to themerchant device114 in doing so.Merchant device114 assigns a subscription Id to represent the subscription order the customer just placed.Merchant device114 sends a registration message, in this case, a recurring payment registration message, topayment processing server118 asstep122. The recurring payment registration message contains the subscription Id, merchandise product Id, recurring payment setting, shipping address, payment amount, mobile device identity and email address. Non-transitory computerreadable storage medium121, that is not a signal, stores computer executable instructions that when executed bypayment processing server118 cause the payment processing server to effectuate operations as will be disclosed below. The description of the following operation ofpayment process server118 should be taken as being directed by executable instructions by non-transitorycomputer storage medium121 even though, for simplicity, the specific language is not used in each instance.Payment processing server118, stores all the information for the corresponding subscription Id indatabase117. The subscription Id is assigned bymerchant device114 as the identity of the recurring purchase and payment. In this manner, a subscription for a recurring payment configuration has been established with thepayment processing server118.

Anoptional step123 includes the customer registeringmobile payment device115 withpayment processing server118. For example,mobile payment device115 can download a mobile application to process payments withpayment processing server118, such as receiving push notification of payment requests.Payment processing server118 can verifymobile payment device115 with the mobile identity or email address received instep120.

Payment processing server

118 then determines, using a if and when a specific payment is required. In the recurring payment configuration this includespayment process server118 determining the recurring payment amount due and calculating the next due date in astep124 for the registered recurring payment.Payment processing server118 then retrieves payment information such as the merchandise product Id, mobile identity, email address, etc. fromdatabase117 for the specific recurring payment using the subscription ID, in astep126.Payment processing server118 can querymerchant device114 to get the price of merchandise, product Id and associated shipping cost to determine the payment amount; it is possible that the payment amount may vary in each payment, which is not shown in the figure. Alternatively,payment processing server118 can get the payment amount fromdatabase117 as payment information.

Payment processing server

118 sends a payment request message in SMS/MMS (Short Message Service/Multimedia Messaging Service), email or push notification tomobile payment device115 in astep128. For example, the message sent in push notification can include payment amount, currency code, description of payment, merchant name and identity, merchant's supported brand network (e.g. any of Visa, MasterCard, and/or American Express), etc. Alternatively the message sent in SMS/MMS or email can include a URL address topayment processing server118, with embedded payment information including payment amount, currency code, merchant name or identity, merchant's supported brand network (e.g. Visa, MasterCard, and/or American Express), etc., or the message sent in SMS/MMS or email only includes a URL address topayment processing server118 and the URL address includes a transaction Id for this specific transaction or subscription Id, which can be used to retrieve the payment information. Using a push notification does not need a URL because a push notification is received by the mobile application which already knows the payment processing server's URL address.

Mobile payment device

115 receives the payment request message, and in the case of SMS/MMS or email, the URL is displayed to the customer by themobile payment device115. Usingmobile payment device115, the customer can then select the displayed URL link in SMS/MMS or email in astep130.

In the case of SMS/MMS or email,mobile payment device115 sets up an HTTPS session withpayment processing server118 pointed to by the URL address provided in the received SMS/MMS or email in astep132 in response to the customer selecting the URL link. In the case of a push notification message received by the mobile application onmobile payment device115, a HTTPS session can be a long-lasting session and does not need to set up for each transaction.

Once an HTTP session is established, in the case of SMS/MMS or email,payment processing server118 downloads a program script and a validation token tomobile payment device115 in astep134 referred to as a payment authorization request. The program script can include specific payment information, including payment amount, currency code, merchant name or identity, merchant's supported brand network (e.g. Visa, MasterCard, and/or American Express), etc. which is retrieved fromdatabase117 using the transaction Id or the subscription Id. The program script can also include a brief product description, product quantity, merchant name, etc. If the SMS/MMS or email includes a URL address with embedded payment information, the payment information is stored in the URL which can be retrieved by the program script. The program script can run atmobile payment device115 to interact with the API of the mobile wallet (platform) to retrieve encrypted payment data by providing some or all of payment information as input, e.g. payment amount, currency code, merchant identity, merchant's supported brand network (e.g. Visa, MasterCard, and/or American Express), etc. The validation token is used to identify a valid merchant website or a valid payment processing server and be able to interact with the mobile wallet inmobile payment device115. In the case of a push notification message received by the mobile application, the push notification does not require a validation token because the mobile application can authenticate itself to the mobile wallet in the mobile payment device and program script is already in the mobile application.

Upon receiving the payment authorization request frompayment processing server118,mobile payment device115 can display some payment information, e.g. payment amount, brief product description, product quantity, merchant name. Astep136 includesmobile payment device115 displaying information and prompting the customer to authorize using biometric input, PIN code or the like. Duringstep136,mobile payment device115 will invoke the mobile wallet API to process the payment information and retrieve encrypted payment data for this payment transaction. The procedure is executed by program script downloaded instep134 or by the mobile application pre-installed inoptional step123.

Upon authorization of the payment by the customer,mobile payment device115 sends encrypted payment data (payment data can include payment token, payment amount, currency code, cryptogram, etc.) to thepayment processing server118 in astep138.

Upon receiving the encrypted payment data,payment processing server118 sends the encrypted payment data topayment network119 to approve the transaction and receives a payment notice, either declining the transaction or approving the transaction in astep140.

Upon receiving the payment notice frompayment network119 instep140,payment processing server118 sends an authorization indication tomerchant device114 with authorization status, merchandise product Id, shipping address, mobile identity, and email address in astep142. Whenmerchant device114 receives the authorization indication frompayment process server118,merchant device114 can initiate product shipment to the customer at the shipping address if the payment notice included approval of the transaction or cancel shipment if the transaction was declined in astep144.

Alternatively, instep136, the customer can reject this payment, which can signal topayment processing server118 and/ormerchant device114 to cancel this particular transaction, terminate this subscription or update the subscription (not shown in the figure).

Turning now toFIGS. 3aand 3b, an example of web portal pages for establishing a subscription order withmerchant device114 is shown. The subscription order enablespayment processing server118 to store recurring period, mobile identity and email address (along with subscription Id, merchandise product Id, shipping address, etc.) and process recurring purchases/payments. On afirst page150 illustrated inFIG. 3a, the web portal can allow the customer to enterstart date152,end date154 andrecurring period156 after clicking button of recurringpayment158 with XYZ mobile payment. For example, XYZ can be Apple Pay, Google Pay, etc. At the end, the customer clicks “Next”button160. On asecond page162, as shown inFIG. 3b, in order for the customer to receive a payment request frompayment processing server118, 2 options are provided to the customer. Thefirst option164 is to download a mobile application to customer's mobile phone, e.g. iPhone, Android Phone. Thesecond option166, is to receive SMS or email without requiring a mobile application installed for this service. To download and install a mobile application, the mobile payment device is required to register with the payment processing server as described inStep123 described inFIG. 2.

If the customer selectsoption164 of installing mobile application, the web portal can redirect the web page to the app store of the corresponding mobile OS (Operating System) vendor, e.g. iOS or Android, to download the mobile application. If the customer selectsoption166 of receiving SMS or email without a mobile application, the customer must fill inmobile phone number168 andemail address169 to a receive payment request.

Referring now toFIG. 4, the process steps in an example of an event triggered payment procedure is shown for making payments when using the event triggered payment configuration. A dashed box circlingmerchant device114 andpayment processing server118 illustrates thatpayment processing server118 can be operated by the operator ofmerchant device114. Alternatively,payment processing server118 can belong to a 3rd party company that provides payment service separate from the operator ofmerchant device114.

The process begins withmerchant device114 receiving a subscription to a payment configuration. In this case, an event trigger purchase subscription order is submitted by a customer, designatedstep220. The event trigger purchase subscription order includes information provided by the customer such as a UUID, shipping address, mobile identity (e.g. mobile phone number), email address, etc. For example, the customer can usemobile payment device115 to connect tomerchant device114 through a web portal as previously described. The customer can also use a smartphone camera to capture the UUID encoded in a bar code or a QR (Quick Response) code format from a product's (such as a refrigerator's water filter) label.Merchant device114 assigns a subscription Id to represent the event triggered subscription order that the customer just placed.

Merchant device

114 sends a registration message, in this case, an event trigger payment registration message, topayment processing server118 asstep222. The event trigger payment registration message includes subscription Id, Universal Unique Identifier (UUID), merchandise product Id, shipping address, payment amount, mobile device identity and email address. The UUID can indicate a unique instance of the merchandise. For example, UUID=x can relate to the merchandise product Id=w and serial number.Payment processing server118 can store all the information for the corresponding subscription Id indatabase117. The subscription Id is assigned bymerchant device114 as the identity of the event trigger purchase and payment. In this manner, a subscription for an event trigger payment configuration has been established with thepayment processing server118.

Anoptional step223 includes the customer registeringmobile payment device115 withpayment processing server118. For example,mobile payment device115 can download a mobile application to process payments withpayment processing server118, such as receiving push notification of payment requests.Payment processing server118 can verifymobile payment device115 with the mobile identity or email address received instep220.

Payment processing server

118 then determines if and when a specific payment is required. In the event trigger payment configuration this includesIoT device116 detecting a need to replace a part of or the entire device in astep224. For example,IOT device116 can be a refrigerator and a part to be replaced can be the water filter of the drinking water dispenser at the refrigerator front panel. For example, some sensor can detect the deterioration of water quality with water filter; or some processor can count total time when the dispenser of drinking water has been turned on exceeding a threshold; or some processor can record the time that has elapsed since the filter was installed exceeding a threshold.IoT device116 then sends an event trigger indication message topayment processing server118 asstep226. The event trigger indication message includes the UUID of the part or the entire device to be replaced. In order forIoT device116 to send the event trigger indication message topayment processing server118,IoT device116 needs to be configured to accessinternet112, e.g. WiFi SSID and password is provided using a provisional interface toIoT device116.IoT device116 needs to be configured with the URL address ofpayment processing server118. Furthermore,IoT device116 needs to be registered withpayment processing server118 to set up secured communication session, e.g. installing a security key betweenIoT device116 andpayment processing server118.

Payment processing server

118 receives the UUID contained in the event trigger indication message and retrieves the merchandise product Id=w, mobile identity, email address, etc. fromdatabase117 asstep227. If the payment amount varies in each payment event,payment processing server118 can querymerchant device114 to get the price of the merchandise product Id (=w) and its associated shipping cost to determine the payment amount; otherwise,payment processing server118 can get payment the amount fromdatabase117.

Payment processing server

118 sends a payment request message in SMS/MMS (Short Message Service/Multimedia Messaging Service), email or push notification tomobile payment device115 in astep228. For example, the message sent in push notification can include payment amount, currency code, description of payment, merchant name and identity, merchant's supported brand network (e.g. any of Visa, MasterCard, and/or American Express), etc. Alternatively the message sent in SMS/MMS or email can include a URL address topayment processing server118, with embedded payment information including payment amount, currency code, merchant name or identity, merchant's supported brand network (e.g. Visa, MasterCard, and/or American Express), etc., or the message sent in SMS/MMS or email only includes a URL address topayment processing server118 and the URL address includes a transaction Id for this specific transaction or subscription Id, which can be used to retrieve the payment information. Using a push notification does not need a URL because a push notification is received by the mobile application which already knows the payment processing server's URL address.

Mobile payment device

115 receives the payment request message, and in the case of SMS/MMS or email, the URL is displayed to the customer by themobile payment device115. Usingmobile payment device115, the customer can then select the displayed URL link in SMS/MMS or email in astep230.

In the case of SMS/MMS or email,mobile payment device115 sets up an HTTPS session withpayment processing server118 pointed to by the URL address provided in the received SMS/MMS or email in astep232 in response to the customer selecting the URL link. In the case of a push notification message received by the mobile application onmobile payment device115, a HTTPS session can be a long-lasting session and does not need to set up for each transaction.

Once an HTTP session is achieved, in the case of SMS/MMS or email,payment processing server118 downloads a program script and a validation token tomobile payment device115 in astep234 referred to as a payment authorization request. The program script can include specific payment information, including payment amount, currency code, merchant name or identity, merchant's supported brand network (e.g. Visa, MasterCard, and/or American Express), etc. which is retrieved fromdatabase117 using the transaction Id or the subscription Id. The program script can also include a brief product description, product quantity, merchant name, etc. If the SMS/MMS or email includes a URL address with embedded payment information, the payment information is stored in the URL which can be retrieved by the program script. The program script can run atmobile payment device115 to interact with the API of the mobile wallet (platform) to retrieve encrypted payment data by providing some or all of payment information as input, e.g. payment amount, currency code, merchant identity, merchant's supported brand network (e.g. Visa, MasterCard, and/or American Express), etc. The validation token is used to identify a valid merchant website or a valid payment processing server and be able to interact with the mobile wallet inmobile payment device115. In the case of a push notification message received by the mobile application, the push notification does not require a validation token because the mobile application can authenticate itself to the mobile wallet in the mobile payment device and program script is already in the mobile application.

Upon receiving the authorization request frompayment processing server118,mobile payment device115 can display some payment information, e.g. payment amount, brief product description, product quantity, merchant name. Astep236 includesmobile payment device115 displaying information and prompting the customer to authorize using biometric input, PIN code or the like. Duringstep236,mobile payment device115 will invoke the mobile wallet API to process the payment information and retrieve encrypted payment data for this payment transaction. The procedure is executed by program script downloaded instep234 or by the mobile application pre-installed inoptional step223.

Upon authorization of the payment by the customer,mobile payment device115 sends encrypted payment data (payment data can include payment token, payment amount, currency code, cryptogram, etc.) to thepayment processing server118 in astep238.

Upon receiving the encrypted payment data,payment processing server118 sends the encrypted payment data topayment network119 to approve the transaction and receives a payment notice, either declining the transaction or approving the transaction in astep240.

Upon receiving the payment notice frompayment network119 instep240,payment processing server118 sends an authorization indication tomerchant device114 with authorization status, merchandise product Id, shipping address, mobile identity, and email address in astep242. Whenmerchant device114 receives the authorization indication frompayment process server118,merchant device114 can initiate product shipment to the customer at the shipping address if the payment notice included approval of the transaction or cancel shipment if the transaction was declined in astep244.

Alternatively, instep236, the customer can reject this payment, which can signal topayment processing server118 and/ormerchant device114 to cancel this particular transaction, terminate this event or update the event (not shown in the figure).

Aftermerchant device114 initiates shipment of the merchandise,merchant device114 sends an event trigger payment reregistration message topayment processing server118 asstep246. The event trigger payment reregistration message contains subscription Id, new Universal Unique Identifier (UUID=y), merchandise product Id=w, shipping address, mobile device identity and email address. The information of shipping address, mobile device identity and email address can be known from the subscription Id.Merchant device114 can acquire the new UUID by scanning a bar code which is used to identify the unique instance of this merchandise. Afterpayment processing server118 receives the event trigger payment reregistration message, it adds the new UUID and its corresponding payment amount to the database entry of the associated subscription Id.

Similarly toFIG. 2, the Merchant's web portal associated withmerchant device114 can allow a customer to subscribe for event trigger purchase/payment to enablemerchant device114 andpayment processing server118 to store mobile identity, email address, subscription Id, merchandise product Id, UUID, etc. and process event trigger purchase/payment. For example, Recurring Period being “On the need for replacement basis” can be chosen inFIG. 3a. In order to receive a payment request, in the web portal page, the customer can select the option of installing mobile application to the mobile payment device, e.g. iPhone, Android Phone; or select the option of receiving SMS or email without a mobile application. To download and install a mobile application, the mobile payment device is required to register with the Payment Processing Server as described inStep223 ofFIG. 4.

Referring now toFIG. 5, an example of a recurring payment process corresponding to procedures described in conjunction withFIG. 2, is illustrated as a flow chart.

Block300: The customer subscribes to a subscription order by providing recurring payment schedule (i.e. subscription duration and recurring period), mobile identity, shipping address and email address.

Block310: The system stores the subscription Id with associated recurring payment schedule, merchandise product Id, shipping address, payment amount, mobile identity, and email address.

Block320: The system determines recurring payment amount due.

Block330: The system sends SMS/MMS, email or push notification with payment information to the mobile payment device.

Block340: The mobile payment device retrieves mobile wallet encrypted payment data after user authorization.

Block350: The system sends payment data to request for authorization.

Block360: The system receives authorization response and ship the merchandise of the correct product Id to the shipping address.

FIG. 6 shows the example of the flow chart of an event triggered payment process corresponding to procedures inFIG. 4.

Block400: The customer subscribes to an event triggered subscription order by providing UUID, mobile identity, shipping address and email address.

Block410: The system stores the subscription Id with associated UUID, merchandise product Id, shipping address, payment amount, mobile identity, and email address.

Block420: The system detects the event to replace a part of or the entire IOT device.

Block430: The IOT device sends event trigger indication message with UUID.

Block440: The system sends SMS/MMS, email or push notification with payment information to the mobile payment device.

Block450: The mobile payment device retrieves mobile wallet encrypted payment data after user authorization.

Block460: The system sends payment data to request for authorization.

Block470: The system receives authorization response and ships the merchandise of the product Id to the shipping address.

Block480: The system adds the new UUID and its corresponding payment amount to the database entry associated with the subscription Id.

Turning now toFIG. 7, an example of detailed modules ofpayment processing server118 is illustrated.Payment processing server118 includes a recurringpayment processing module510. Recurringpayment processing module510 is coupled in communication withmerchant device114 throughinternet112 to receive the recurring payment registration frommerchant device114 described instep122. Ifpayment processing server118 is provided by the operator ofmerchant device114,module510 can also provide a web portal for customer to place a subscription order with a recurring payment configuration and mobile payment configuration as described in association withFIG. 3. Recurringpayment processing module510 provisions the recurring payment configuration using a subscription database module520 (previously described as database117) coupled thereto. Recurringpayment processing module510 sends a mobile identity or an email address to a mobiledevice messaging module530 by retrieving associated information fromdatabase module520 in order to send a payment request upon receiving a signal from a recurringpayment scheduler module540 that a recurring payment scheduled for a subscription Id is due or will be due. Recurringpayment processing module510 notifiesmerchant device114 of the authorization status in order to ship merchandise.

Payment processing server

118 preferably further includes an event triggerpayment processing module550. Event triggerpayment processing module550 is coupled in communication withmerchant device114 throughinternet112 to receive the event trigger payment registration frommerchant devices114. Ifpayment processing server118 is operated by the operator ofmerchant device114,module550 can also provide a web portal for a customer to register for the event trigger payment with a mobile setting. Event triggerpayment processing module550 provisions the event trigger payment configuration using subscription database module520 (previously described as database117) coupled thereto. Event triggerpayment processing module550 receives an event trigger indication from an IoTdevice messaging module560. Event triggerpayment processing module550 forwards a mobile identity or email address to mobiledevice messaging module530 by database lookup (database520) upon receiving event trigger indication from IoTdevice messaging module560. Event triggerpayment processing module550 notifiesmerchant device114 of the authorization status to ship merchandise.

Recurringpayment scheduler module540 receives the recurring payment setting from recurringpayment processing module510 for a specific subscription Id and determines the recurring payment due date or predicts the recurring payment due date associated with each subscription Id of recurring payments. Recurringpayment scheduler module540 sends signals to recurringpayment processing module510 with regards to the recurring payment due date associated with a subscription id.

Mobiledevice messaging module530 receives the mobile identity and email address from recurringpayment processing module510 or event triggerpayment processing module550 and sends a payment request message tomobile payment device115 using SMS/MMS, or email or push notification. Depending on the selected process, mobiledevice messaging module530 downloads program scripts tomobile payment device115 and sends a validation token tomobile payment device115. Mobiledevice messaging module530 requests the mobile wallet service provider for a session validation token such thatmobile payment device115 is able to retrieve the encrypted payment data. It can also create a URL with embedded payment information and send the URL in SMS/MMS or email. The payment token frommobile payment device115 is received by mobiledevice messaging module530 which forwards it to apayment authorization module570. Mobiledevice messaging module530 handles the registration from the mobile application installed on themobile payment device115.

Payment authorization module

570 sends the authorization request topayment network119 and receives authorization status back.Payment authorization module570 interacts with recurringpayment processing module510 or event triggerpayment processing module550 to process the payment transaction authorization.

IoTdevice messaging module560 receives the event trigger indication message fromIoT device116 and forwards the payment request message to event triggerpayment processing module550. IoTdevice messaging module560 supportsIoT device116 to register to set up a secured communication session.

Subscription database module

520 provides storage for the payment configuration, e.g. subscription Id, transaction Id, UUID, merchandise product Id, shipping address, payment amount, mobile device identity and email address. It provides the stored configuration upon request by recurringpayment processing module510 or event triggerpayment processing module550 by using subscription Id, transaction Id or UUID.

It will be understood by those of ordinary skill in the art that recurringpayment processing module510 and event triggerpayment processing module550 include processors whose function is directed by a non-transitory computerreadable storage medium580 that is not a signal, storing computer executable instructions that when executed by recurringpayment processing module510 and event triggerpayment processing module550 cause recurringpayment processing module510 and event triggerpayment processing module550 to effectuate operations for processing recurring or event triggered payments as described throughout the specification. It will also be understood that a single processor directed by a non-transitory computer readable storage medium can perform the functions described. The module description is solely intended to provide clarity of the various functions.

The above recurring and event triggered payment methods present advantages over the old payment method. First, mobile payment is used, in which the credit/debit card number is not stored at the merchant, neither is the real card number sent to the merchant at each times of payment. Security is greatly improved. Second, at each of the times of recurring and event triggered payment, the customer can receive payment notification, and the customer needs to clearly authorize using biometric input or PIN code, and therefore customer has awareness and full control on the payment.

Various changes and modifications to the embodiments herein chosen for purposes of illustration will readily occur to those skilled in the art. To the extent that such modifications and variations do not depart from the spirit of the invention, they are intended to be included within the scope thereof, which is assessed only by a fair interpretation of the following claims.

Having fully described the invention in such clear and concise terms as to enable those skilled in the art to understand and practice the same, the invention claimed is:

Claims

1. An electronic mobile recurring payment and mobile event triggered payment method, comprising the steps of:

registering with a payment processing server, the payment processing server programmed to effectuate the operations of automatically establishing a payment configuration, the payment configuration including a subscription ID, payment information associated with the subscription ID and a mobile identity to a mobile payment device having mobile payment capability and associated with the subscription ID;

the payment processing server storing the payment configuration in a database by the payment processing server;

the payment processing server determining a payment requirement is due for the subscription ID;

the payment processing server retrieving payment information from the database using the subscription ID upon determining the payment requirement is due;

the payment processing server sending a payment request message to the mobile payment device using the mobile identity associated with the subscription ID;

establishing communication between the mobile payment device and the payment processing server;

the payment processing server sending a payment authorization request to the mobile payment device;

authorizing payment on the mobile payment device by a customer;

the mobile payment device creating encrypted payment data using a payment platform carried thereby upon authorizing payment by the customer;

the mobile payment device sending encrypted payment data to the payment processing server;

the payment processing server sending encrypted payment data to a payment network for payment processing;

the payment processing server receiving a payment notice from the payment network, the payment notice indicating either a declined transaction or an approved transaction;

the processing server sending an authorization indication to the merchant device indicating either a declined transaction or an approved transaction; and

the merchant device initiating product shipment upon receiving the authorization indication indicating an approved transaction.

2. A mobile payment method as claimed inclaim 1 wherein the step of registering with a payment processing server comprises the steps of:

accessing a web portal from the merchant device and subscribing to one of a recurring payment configuration and an event trigger payment configuration;

entering the mobile identity to the mobile payment device; and

the merchant device sending a registration of the subscribed one of the recurring payment configuration and the event trigger payment configuration to the payment processing server.

3. A mobile payment method as claimed inclaim 2 wherein the step of registering with a payment processing server further comprises the steps of:

registering the mobile payment device directly with the payment processing server to subscribe to one of a recurring payment configuration and an event trigger payment configuration; and

the payment processing server downloading a mobile application to the mobile payment device to enable processing payments.

4. A mobile payment method as claimed inclaim 1 wherein the step of determining a payment requirement comprises the steps of:

the payment processing server programmed to effectuate the operation of automatically calculating, the next due date associated with the subscription ID; and

determining a recurring payment amount due for the next due date associated with the subscription ID;

5. A mobile payment method as claimed inclaim 1 wherein the step of determining a payment requirement comprises the steps of:

an IoT device detecting a need for a replacement; and

the IoT device sending an event trigger indication message to the payment processing server, the event trigger indication message including the UUID of the replacement.

6. A mobile payment method as claimed inclaim 1 wherein the step of sending a payment authorization request to the mobile payment device further includes the step of downloading a program script and a validation token to the mobile payment device.

7. An electronic mobile recurring billing and mobile event triggered billing method, comprising the steps of:

a payment processing server programmed to effectuate the operations of:

a) receiving from a network device a registration order; based on the registration order, automatically

b) establishing a payment configuration, the payment configuration comprising a subscription ID, payment information associated with the subscription ID and a mobile identity to a mobile payment device having mobile payment capability and associated with the subscription ID;

c) storing the payment configuration in a database;

d) determining a payment requirement for the subscription ID;

e) retrieving payment information from the database using the subscription ID;

f) sending a payment request message in SMS/MMS or email to the mobile payment device using the mobile identity associated with the subscription ID, wherein the payment request message can include an URL with embedded payment information.

8. The electronic mobile recurring billing and mobile event triggered billing method as claimed inclaim 7, further comprising the steps of:

the payment processing server programmed to effectuate the operation of:

a) automatically sending a payment authorization request to the mobile payment device upon establishment of communication with the mobile payment device;

b) receiving encrypted payment data generated by the mobile payment device using a payment platform carried thereby upon authorizing payment by the customer;

c) sending the encrypted payment data to a payment network for payment processing;

d) receiving a payment notice from the payment network, the payment notice indicating either a declined transaction or an approved transaction; and

e) sending an authorization indication to the network device indicating either a declined transaction or an approved transaction.

9. The electronic mobile recurring billing and mobile event triggered billing method as claimed inclaim 7, wherein the step of receiving from a network device a registration order, further comprising the step of subscribing to one of a recurring payment configuration and an event trigger payment configuration.

10. The electronic mobile recurring billing and mobile event triggered billing method as claimed inclaim 7, wherein the step of determining a payment requirement for the subscription ID, further comprising the step:

determining a recurring payment amount due for the next due date associated with the subscription ID.

11. The electronic mobile recurring billing and mobile event triggered billing method as claimed inclaim 7, wherein the step of determining a payment requirement for the subscription ID, further comprising the step the payment processing server receiving an event trigger indication message from an IoT device which has detected a need for a replacement, the event trigger indication message including the UUID of the replacement.

12. An electronic billing system, comprising the steps of:

a payment processing server serving a networked device over an internet;

a non-transitory computer readable storage medium that is not a signal, storing computer executable instructions that when executed by the payment processing server cause the processor to effectuate operations comprising:

a) receiving from the networked device a registration order subscribing to one of a recurring payment configuration and an event trigger payment configuration; and automatically

b) establishing a payment configuration based on the registration order, the payment configuration comprising a subscription ID, payment information associated with the subscription ID, and a mobile identity of a mobile payment device having mobile payment capability and associated with the subscription ID;

c) storing the payment configuration in a database;

d) determining a payment requirement for the subscription ID;

e) retrieving payment information from the database using the subscription ID; and

13. The electronic billing system, comprising the steps of:

the payment processing server programmed to effectuate the operation of:

b) receiving encrypted payment data generated by a payment platform carried by the mobile payment device upon authorizing payment by the customer;

14. The electronic billing system as claim inclaim 12, wherein the step of determining a payment requirement for the subscription ID, further comprising the step:

the payment processing server programmed to effectuate the operation of automatically determining a recurring payment amount due for the next due date associated with the subscription ID.