Method for cross-service provider online payments

Abstract

The present invention relates to a method for online checkout between an issuer system of a selected issuer and an acquirer system of an acquirer using mobile payments. An online merchant of the acquirer may provide a URL to request payment from a payer of an issuer different from the acquirer. The URL is configured to instruct the payer's user device to receive an issuer list including multiple mobile payment service providers, so that the payer can select one from the list as the issuer to pay with. The URL may then instruct the selected issuer to automatically process the following steps to pass payment from the issuer to the acquirer:

Description

[Technical Field]

[0001] (Related Applications) This application claims the benefit of U.S. Provisional Application No. 63 / 385,946, entitled "A METHOD FOR IMPROVING ONLINE QR CODE PAYMENT," filed December 2, 2022, which is incorporated herein by reference in its entirety.

[0002] The present invention relates to a method for facilitating cross-service provider online payments, and more particularly to a method for facilitating online payments for two Mobile Payment Service Providers (MPSPs) having different transaction QR Code formats. [Background technology]

[0003] In recent years, mobile payments have become a popular payment method because they are easy to use and only require the payer to have a mobile device. Of all mobile payment methods, QR code scanning is perhaps the most widely used payment method for consumers to purchase goods in stores.

[0004] In addition to traditional merchant stores, more and more merchants are allowing their products to be purchased online with the development of e-commerce. Therefore, the need for mobile payments in e-commerce is increasing. To request and receive payments, online merchant webpages may display a QR code on the checkout page or redirect consumers to log in to their mobile payment accounts to proceed with the payment. Consumers can then transfer to their merchant accounts if both the consumer account and the merchant account belong to the same mobile payment service provider (MPSP).

[0005] In both of the above cases, online merchants can only accept payments from a limited number of mobile payment service providers (MPSPs). If a consumer does not install the app of an acceptable MPSP, the consumer may not be able to purchase goods or services from the online merchant using mobile payments. This is especially true when a consumer purchases goods or services on a foreign website, as many MPSPs only provide services domestically and do not operate overseas. To address this issue, some mobile payment service providers may approve cross-MPSP transactions (also known as bridging transactions) by having bilateral agreements with other service providers and may modify their systems accordingly, thereby accepting payments from other service providers.

[0006] However, even with the above improvements, some problems may still arise. First, having bilateral agreements with many MPSPs and modifying the system accordingly is cumbersome and time-consuming. Service providers must modify their systems every time a new collaborative partner joins their payment network. Another problem occurs when consumers use a portable device (e.g., a smartphone) to browse and check out an online store's webpage. The portable device cannot physically scan the QR code on the web checkout page displayed on the portable device's screen. It is very inconvenient for consumers to first take a screenshot and then use another app to "scan" the QR code and proceed with payment by uploading the screenshot to the app. If the transaction is a cross-MPSP transaction (bridging transaction), the situation may become even more complicated. Even if a cross-MPSP agreement is applied, it is still difficult to execute a cross-MPSP transaction online because the QR code or link on the checkout page may not lead the consumer to the payment confirmation page of the MPSP they selected.

[0007] Therefore, there remains a need to develop new methods for facilitating cross-MPSP online payments. Summary of the Invention

[0008] Provided herein is a method for online checkout between a selected issuer's issuer system and an acquirer's acquirer system using mobile payment. The method of the present application applies when a consumer (payer) wants to purchase goods or services at an online merchant with mobile payment. There may be multiple mobile payment service providers (MPSPs) available in a payment network, and different MPSPs in the network are linked to each other by a bridging service provider. A payer may select an MPSP in the network as the issuer to pass the payment on, and an online merchant may select another MPSP in the network as the acquirer to receive the payment.

[0009] After the payer decides to check out, the online merchant may provide a checkout URL (which may be embedded in the merchant QR code) for the payer to pay. Because there may be many MPSPs available as issuers, before processing the payment, the payer's user device may request an issuer list including one or more available issuers for the payer to select from. Because a bridging service provider is not required for two members of the same MPSP, the selected issuer should be different from the acquirer. The checkout URL may be configured to instruct the user device to generate a delivery request for the payment. Thus, the delivery request may be generated based on the checkout URL and may request a delivery transaction from the acquirer's acquirer system. In some embodiments, the user device is a portable device, and the checkout URL is configured to open issuer apps of one or more available issuers installed on the portable device.

[0010] From the perspective of a bridging system of a bridging service provider, a method for online checkout includes the steps of (1) providing an issuer list including one or more available issuers to a payer's user device, and (2) receiving a delivery request from an issuer system of a selected issuer selected from the one or more available issuers.

[0011] Before providing the issuer list including one or more available issuers, the method may further include receiving a list request from a payer user device. The list request may be received from the payer user device or may be redirected from an acquirer system. If the list request is received directly from the payer user device, the checkout URL may be configured to direct the user device to the bridging system, and the checkout URL may be embedded in a QR code of the bridging service provider. In another case where the list request is redirected from the acquirer system, the checkout URL may be configured to direct the user device to the acquirer system, and the checkout URL may be embedded in a QR code of the acquirer.

[0012] After receiving the delivery request from the issuer system, the method for online checkout may further include the steps of: (1) providing the delivery request to the acquirer system; (2) receiving a payment request from the acquirer system; (3) providing the payment request to the issuer system; (4) receiving a payment confirmation from the issuer system confirming the payment request; and (5) providing the payment confirmation to the acquirer system to complete the transaction.

[0013] From the perspective of a payer's user device, a method for online checkout includes: (1) receiving an issuer list including one or more available issuers for selection by the payer; and (2) providing a delivery request to an issuer system of a selected issuer selected from the one or more available issuers. The method may further include providing the list request by the user device before providing the issuer list including the one or more available issuers.

[0014] There are at least three different embodiments for providing and receiving the issuer list: In a first embodiment, the list request is provided to a Bridging System of a Bridging Service Provider, and the issuer list is also received from the Bridging System; In a second embodiment, the list request is provided to an Acquirer System of an Acquirer, and the issuer list is also received from the Acquirer System; In a third embodiment, the list request is provided to the Acquirer System, but the issuer list is received from the Bridging System, as the list request is redirected from the Acquirer System to the Bridging System.

[0015] In the case where the list request is provided to a bridging system, the checkout URL may be configured to direct the user device to the bridging system, and the checkout URL may be embedded in the QR code of the bridging service provider. In the case where the list request is provided by an acquirer system, the checkout URL may be configured to direct the user device to the acquirer system, and the checkout URL may be embedded in the QR code of the acquirer.

[0016] After providing the delivery request to the issuer system, the method for online checkout may further include the steps of: (1) receiving a payment request from the issuer system; and (2) providing a payment confirmation to the issuer system confirming the payment request, to complete the transaction.

[0017] From the perspective of an issuer system of a selected issuer, a method for online checkout includes the steps of: (1) receiving a delivery request from a payer's user device; and (2) providing the delivery request to a bridging system of a bridging service provider. Because the checkout URL can be resolved by the bridging system or the acquirer system, the issuer system does not have to resolve the payment request embedded in the checkout URL.

[0018] After providing a delivery request to the bridging system, the method for online checkout may further include the steps of: (1) receiving a payment request from the bridging system; (2) providing the payment request to the user device; (3) receiving a payment confirmation from the user device confirming the payment request; and (4) providing the payment confirmation to the bridging system to complete the transaction.

[0019] From the perspective of the acquirer's acquirer system, the method for online checkout may include returning the issuer list directly to the user device after the acquirer system receives the list request, or may include redirecting the user device to a bridging system after the acquirer system receives the list request. In the first case, the method includes (1) receiving a list request from the payer's user device, (2) providing the payer's user device with an issuer list including one or more available issuers, and (3) receiving a delivery request from the issuer system of a selected issuer via the bridging system, where the selected issuer is selected from the one or more available issuers. In the second case, the method includes the steps of (1) receiving a list request from a payer's user device, (2) redirecting the user device to a bridging system of a bridging service provider, whereby the bridging system provides the user device with an issuer list including one or more available issuers, and (3) receiving a delivery request via the bridging system from the issuer system of a selected issuer, where the selected issuer is selected from the one or more available issuers. In both cases, a checkout URL may be configured to direct the user device to the acquirer system, and the checkout URL may be embedded in the acquirer's QR code.

[0020] After receiving the delivery request from the issuer system, the method for online checkout may further include the steps of (1) providing a payment request to a bridging system and (2) receiving a payment confirmation from the bridging system confirming the payment request to complete the transaction.

[0021] Other objects, advantages and novel features of the present invention will become more apparent from the following detailed description when considered in conjunction with the accompanying drawings. [Brief explanation of the drawings]

[0022] [Figure 1] Shown is a network of six MPSPs that have cross-MPSP bilateral agreements with each other. [Figure 2] 1 shows a network of six MPSPs with cross-MPSP bilateral agreements, independent of the bridging service provider. [Figure 3] 1 shows a flowchart of a first embodiment enabling seamless online checkout with cross-MPSP mobile payments, in which a bridging system of a bridging service provider receives a list request from a payer's user device and returns an issuer list to the user device. [Figure 4] 1 shows a flowchart of a second embodiment enabling seamless online checkout with cross-MPSP mobile payments, in which an acquirer system of an acquirer receives a list request from a payer's user device and returns an issuer list to the user device. [Figure 5] 1 shows a flowchart of a third embodiment enabling seamless online checkout with cross-MPSP mobile payments. In this embodiment, an acquirer system of an acquirer receives a list request from a payer's user device. The acquirer system then redirects the user device to a Bridging System so that the Bridging System can provide the issuer list to the user device. [Figure 6] 1 is a flowchart of the present invention implemented in iOS, which allows a portable device (e.g., a smartphone) to "scan" a QR code on its screen and pop up a list of issuer mobile apps installed on the portable device. [Figure 7A] Here is an example of domain matching in iOS, showing how to bind an app to a Bridging Service Provider URL by adding an Associated Domains Entitlement to the app configuration. [Figure 7B] Here is an example of domain matching in iOS, showing binding a bridging service provider URL to an app by uploading a json file to the bridging service provider's website. [Figure 7C] This section provides an example of domain matching in iOS. It also provides sample code for invoking an issuer's mobile app that is contracted with a bridging service provider (i.e., is in the bridging service provider's bridging network). [Figure 8A] 10 illustrates the content on a phone screen during cross-MPSP mobile payment for online shopping. 11 illustrates an exemplary QR code for a Bridging Service Provider (HIVEX). [Figure 8B] Showing phone screen content in action with cross-MPSP mobile payment for online shopping, showing three wallet apps installed on the portable device. [Figure 8C] 1 shows the content on a phone screen during cross-MPSP mobile payment for online shopping, showing that two of the three wallet apps are contracted with a bridging service provider and can be selected by the payer. [Figure 8D] 1 shows the content on a phone screen during cross-MPSP mobile payment for online shopping. The URL (e.g., QR code or payment link) provided by the online merchant does not include the payment amount, so the app displays a page for the payer to enter the amount. DETAILED DESCRIPTION OF THE INVENTION

[0023] The terms used in the description provided below are intended to be interpreted in their broadest reasonable manner, even when used in conjunction with a detailed description of certain embodiments of the present technology. Certain terms may be further emphasized below, but any terminology intended to be interpreted in any limited manner is specifically defined as such in this detailed description section.

[0024] The embodiments presented below may be implemented by programmable circuitry programmed or configured by software and / or firmware, or by entirely dedicated circuitry, or a combination of such forms, where such dedicated circuitry (if present) may be in the form of, for example, one or more application specific integrated circuits (ASICs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), graphics processing units (GPUs), etc.

[0025] This application relates to a method for facilitating transactions between two mobile payment service providers (MPSPs) using a bridging service provider. As described above, having bilateral agreements with many MPSPs and modifying the system accordingly is a cumbersome and time-consuming task. For example, referring to FIG. 1, there are six MPSPs (first SP, second SP, etc.) that wish to form a payment network. In this example, assume that a merchant is affiliated with the second SP and a consumer (payer) is affiliated with a third SP. The MPSP that the payer is affiliated with is called the "issuer," and the MPSP that the payee (usually a merchant) is affiliated with is called the "acquirer." Thus, the second SP is the acquirer, and the third SP is the issuer. If each MPSP establishes a bilateral agreement with another, 15 bilateral agreements are required in this network. Also, if a new MPSP wants to join, six new bilateral agreements are required, and each MPSP in the network needs to modify its own system to accept the new participant. This clearly shows that as the number of participating MPSPs increases, it becomes increasingly complicated to have bilateral agreements.

[0026] The above problem can be solved by introducing an intermediary partner called a Bridging Service Provider (Bridging SP), as shown in Figure 2. All participating MPSPs contact each other through the Bridging Service Provider. In this new configuration, each MPSP (other than the Bridging SP) only needs to have a bilateral agreement and establish a connection with the Bridging SP. In this example, only six bilateral agreements are needed to build such a network. And, if a new MPSP wants to join, only one new bilateral agreement (between the Bridging SP and the new participant) is needed.

[0027] Two MPSPs can execute cross-MPSP mobile payments with the help of an intermediary bridging service provider. For merchant presentment mode (MPM) transactions, WO 2021 / 211773 describes a method for an issuer MPSP to resolve a code having the format of an acquirer MPSP to proceed with the cross-MPSP transaction. For consumer presentment mode (CPM) transactions, WO 2023 / 132995 describes a method for a payer (a member of the issuer MPSP) to present a code having the format of an acquirer MPSP to proceed with the transaction. Also, WO 2018 / 022131 describes a method for a bridging service provider to facilitate the settlement process on a blockchain. The above documents are incorporated herein by reference.

[0028] However, the above examples are insufficient to provide seamless cross-MPSP transactions for online shopping. When using mobile payment at a brick-and-mortar store, the merchant typically provides a merchant code for the consumer to scan, or the merchant scans a consumer code displayed on the consumer's portable device. The merchant code and consumer code may each be a 1D code, a 2D code, or any other code format. Examples include, but are not limited to, a Universal Product Code (UPC), a QR code, a PDF417 code, and a Data Matrix code. On the other hand, online merchants cannot scan consumer codes presented by consumers, so merchants typically display the merchant code on a checkout page for the consumer to scan. Alternatively, the merchant may redirect the consumer to log in to their mobile payment account to make the payment. If the consumer chooses to pay with an issuer other than the merchant's affiliated acquirer, the merchant code or payment link typically cannot direct the consumer (the payer) to the issuer's app to make the payment. If the payer checks out using a portable device, the payer may first need to use the issuer app to "scan" the merchant code by taking a screenshot and uploading the screenshot to the app to proceed with the payment. Also, if the online merchant only provides a payment link, it may be more difficult for the payer to conduct cross-MPSP transactions. To address these issues, the merchant code or payment link provided by the online merchant should direct the payer's user device to the selected issuer's app so that the payer can conduct a seamless transaction while shopping online using their selected issuer.

[0029] FIGS. 3-5 illustrate three different embodiments for enabling seamless online checkout with cross-MPSP mobile payments. In all three embodiments, the payer (consumer) shops online using a user device. The user device may be a personal computer, a portable device (e.g., a smartphone or tablet), or any other suitable device. After the payer confirms the item to be purchased, the online merchant can generate a merchant code (e.g., a QR code) or a payment link to facilitate the payment. Here, a bridging service provider is involved, acting as an intermediary between the issuer and the acquirer. The issuer is the MPSP that the payer partners with to pass the payment, and the acquirer is the MPSP that the merchant partners with to collect the payment. The bridging service provider can connect to many MPSPs, as shown in FIG. 2, and in each transaction, one of the many MPSPs acts as the issuer and another of the many MPSPs acts as the acquirer. Theoretically, any MPSP that supports cross-MPSP payment transfers can be selected by a payer as an issuer, and any MPSP that supports cross-MPSP payment collections can be selected by a merchant as an acquirer. However, in practice, online merchants usually select an MPSP as an acquirer in advance and embed relevant information in a QR code or payment link. The checkout QR code or payment link may be or include a checkout URL. Based on the contract, the checkout URL may be recognized by the issuer system and the bridging system as a payment request from the acquirer. For increased security, the checkout URL may include an expiration date. After the expiration date, transactions using the checkout URL may be rejected by either the issuer system, the bridging system, or the acquirer system.

[0030] First embodiment: Bridging system receives list request and provides issuer list In the first embodiment shown in FIG. 3, in S101, the payer opens a merchant QR code or payment link in the payer's user device. If the merchant provides a QR code, the payer can scan the code (using another portable device) or tap the code (shown on the portable device screen) to parse the embedded checkout URL. Alternatively, if the merchant provides a payment link, the payer may simply click or tap the link to open the checkout URL. In S105, the checkout URL directs the user device to the bridging service provider's bridging system (server) for the issuer list. Then, in S106, the bridging service provider's bridging system returns the issuer list to the payer's user device. The issuer list may include one or more available issuers selected by the payer. Preferably, the issuer list may include all of the acceptable issuers that can pass payments to the acquirer via the bridging service provider. Alternatively, the issuer list may include only a portion of the acceptable issuers. For example, the issuer list may include only issuers available in a particular region, which may be determined by the payer's location. This functionality may be implemented, for example, by collecting GPS data, IP number, or other information related to the user device's location and then redirecting the payer to a web page with a region-specific listing.

[0031] In one example of the first embodiment, the checkout QR code or payment link is generated in the bridging service provider's format. Therefore, a checkout URL embedded in the checkout QR code or payment link may direct the user device to the bridging system (the bridging service provider's server), which may then provide a list of payers for selection. Upon selection, the user device may be instructed to open the selected issuer's app or login page and perform the following steps of a cross-MPSP transaction. This instruction may be based on the content of the checkout URL. The bridging system may generate such a URL and / or QR code when the acquirer requests one and provides the merchant identity and payment data to the bridging system. Alternatively, the acquirer may generate the URL or QR code by itself using the bridging service provider's format, also following some rules of the bridging service provider. In both cases, the bridging system may recognize the URL as a payment request from the acquirer's member.

[0032] In S201, after receiving the issuer list, the user device may present the issuer list for the payer to select, and the payer may select a selected issuer based on the list. Next, in S202, the user device may connect to the issuer system (server) of the selected issuer and provide a delivery request based on the merchant QR code or payment link. The merchant QR code or payment link may include information for instructing the user device to open the selected issuer's mobile app or redirect to the selected issuer's login page to proceed with the payment. The user device may then generate a delivery request and provide it to the selected issuer. The delivery request requests a delivery transaction from the acquirer's acquirer system (acquirer server) and is generated according to the information embedded in the merchant QR code or payment link based on a bilateral agreement between the selected issuer and the bridging service provider. For example, the issuer system may send a checkout URL as a payment request from the acquirer. The issuer system may not be able to fully resolve the content (e.g., merchant identity, transaction amount, etc.), but may generate a delivery request and provide the checkout URL in its original format to the Bridging system. The Bridging system and / or the Acquirer system may then resolve the remaining portion of the checkout URL and send it back to the Issuer system. In S203, after receiving the delivery request from the user device, the issuer system of the selected issuer may recognize the payer and then provide the delivery request along with the payer's identity to the Bridging system of the Bridging service provider. In S204, the Bridging system may add a tag (e.g., a Bridging transaction identifier) ​​indicating the identity of the payer and / or the selected issuer to the delivery request and send the delivery request to the Acquirer system of the Acquirer. Because the Merchant QR Code or Payment Link is provided by the online merchant, the Issuer system and / or the Bridging system may not be able to fully resolve the Merchant QR / Payment Link.However, based on bilateral agreement, the issuer system and / or bridging system may recognize the merchant QR / payment link as a payment request from an acquirer member and forward any outstanding merchant identity and payment data to the acquirer system for resolution.

[0033] At S301, the acquirer's acquirer system receives a delivery request from the bridging system. The acquirer system may resolve the URL if some unresolved information, such as merchant identity and payment data, still exists. Then, at S302, the acquirer system may return a payment request to request payment from the payer to the online merchant. The payment request may include information such as the acquirer identity, merchant identity, payment data, as well as any information provided in the delivery request (e.g., the issuer identity, payer identity, and bridging transaction identifier for this transaction). After receiving the payment request, at S303, the bridging system provides the payment request to the issuer system, and at S304, the issuer system relays the payment request to the user device for confirmation by the payer.

[0034] In cross-MPSP transactions (or bridging transactions), the acquirer typically does not recognize the payer, and the issuer typically does not recognize the payee (typically a merchant). To address this issue, the link between the payer and the payee needs to be established by a bridging system. For example, a bridging transaction identifier may be introduced to link the issuer's payer with the acquirer's payee (merchant). The bridging service provider's bridging system may generate a bridging transaction identifier for the transaction so that related transaction information can be connected by the bridging transaction identifier. To enhance privacy protection, the bridging service provider's bridging system may generate a job identifier (job ID) for each bridging transaction identifier for recording the transaction, which may be stored in a distributed ledger such as a blockchain. The bridging system may record each transaction with the job ID, the payer virtual wallet (corresponding to the payer identity), the payee virtual wallet (corresponding to the payee identity), the amount, and the currency type. Alternatively, the bridging service provider's bridging system may also generate multiple job IDs for a single bridging transaction identifier, in which case multiple portions of the transaction may be recorded using different job IDs that all correspond to one bridging transaction identifier. The bridging system may record the selected issuer payer and link the payer identity with the assigned bridging transaction identifier when it receives a delivery request from the issuer system, and then record the acquirer payee and link it to the same bridging transaction identifier after it receives a payment request from the acquirer system.

[0035] At S401, after receiving the payment request, the payer may confirm the payment on the user device and send the confirmation to the issuer system. Then, at S402, the issuer system may provide the confirmation to the bridging system, which may then provide the confirmation to the acquirer system to proceed with the payment at S403. Finally, at S404, the acquirer system may send the confirmation to the online merchant, which may show the confirmation to the payer on its web page.

[0036] Second embodiment: Acquirer system receives list request and provides issuer list Before bridging transactions between issuers and acquirers are available, acquirers may already have their own payment networks using their own QR / URL formats. Therefore, in the above embodiment, the acquirer's online merchants and other recipients need to change the format of the QR code from the acquirer's format to the bridging service provider's format. This causes some problems, as not only the acquirer system but also all associated merchant devices need to be changed accordingly. It is desirable for acquirers and their merchants to retain the original QR / URL formats. This can be solved by introducing a second embodiment as shown in Figure 4.

[0037] In the second embodiment, in S101, the payer opens a merchant QR code or payment link in the payer's user device, similar to the first embodiment. However, in S102, the checkout URL directs the user device to the acquirer system instead of the bridging system for the issuer list. The bridging system may provide the issuer list to the acquirer system in advance, so that the acquirer system can provide it to the payer when requested. The acquirer system may update the issuer list from time to time to ensure that the list matches the most recent list stored in the bridging service provider. Then, in S103, the acquirer system returns the issuer list to the payer's user device. As in the first embodiment, the issuer list may include one or more available issuers selected by the payer. Preferably, the issuer list may include all acceptable issuers that can pass payments to the acquirer via the bridging service provider, although the issuer list may include only a portion of the complete list based on configuration. For example, as described above, it may include only issuers available in a particular region.

[0038] In one example of the second embodiment, the checkout QR code or payment link is generated in the acquirer's format. Therefore, a checkout URL embedded in the checkout QR code or payment link may direct the user device to the acquirer system (the acquirer's server), which may then provide a list of payers for selection. Upon selection, the user device may be instructed to open an app or enter the selected issuer's login page to perform the following steps of a cross-MPSP transaction. This instruction may be based on the content of the checkout URL. The acquirer system may generate such a URL and / or QR code when a merchant requests one and provides its identity and payment data to the acquirer system. Alternatively, the merchant may generate a URL or QR code with the acquirer's format by itself, also following some acquirer rules. To proceed with the payment, in both cases, the URL is configured to be recognized by the bridging system as a payment request from an acquirer member, but the bridging system may not be able to fully resolve the embedded information.

[0039] After the user device receives the issuer list, S201 to S404 in the second embodiment are the same as S201 to S404 in the first embodiment. Because the merchant QR code or payment link is generated by the acquirer system or the online merchant, the issuer system and / or the bridging system may not be able to completely resolve the merchant QR / payment link. However, based on a bilateral agreement, the issuer system and / or the bridging system may recognize the merchant QR / payment link as a payment request from an acquirer member and forward the unresolved portion of the merchant identity and payment data to the acquirer system for resolution.

[0040] Third embodiment: Acquirer system receives list request and Bridging system provides issuer list The second embodiment allows acquirers and their merchants to retain the original QR / URL format. However, this configuration requires each acquirer to store a copy of the latest issuer list. If the acquirer can redirect the payer to a bridging system for the issuer list, as shown in the third embodiment, it can ensure that the payer receives the latest issuer list without having to frequently update the issuer list to maintain consistency.

[0041] In the third embodiment shown in FIG. 5, in S101, the payer opens a merchant QR code or payment link in the payer's user device, similar to the first and second embodiments. Then, in S102, the checkout URL directs the user device to the acquirer system for an issuer list. Here, the system may first check whether the payer has installed the acquirer's mobile app. If yes, the acquirer app may be directly invoked without any selection by the payer. If the payer does not have the acquirer app installed or the offer to open the acquirer app is rejected, in S104, the acquirer system redirects the user device to the bridging system to retrieve the issuer list. Then, in S106, the bridging system provides the issuer list to the payer's user device. Similar to the first and second embodiments, the issuer list may include one or more available issuers selected by the payer. Preferably, the issuer list may include all acceptable issuers, but may also include only a portion of the complete list based on settings, such as issuers available in a particular region.

[0042] In one example of the third embodiment, the checkout QR code or payment link is generated in the acquirer's format. Therefore, a checkout URL embedded in the checkout QR code or payment link may direct the user device to the acquirer system (the acquirer's server). In this example, the acquirer system is configured to redirect the user device to the Bridging system for a list of issuers. The Bridging system then provides a list for payer selection. Upon selection, the user device may be instructed to open the selected issuer's app or login page and perform the following steps of a cross-MPSP transaction. This instruction may be based on the content of the checkout URL. The acquirer system may generate such a URL and / or QR code when a merchant requests one and provides its identity and payment data to the acquirer system. Alternatively, the merchant may generate a URL or QR code with the acquirer's format by itself, also following some acquirer rules. To proceed with the payment, in both cases, the URL is configured to be recognized by the Bridging system as a payment request from an acquirer member, but the Bridging system may not be able to fully resolve the embedded information.

[0043] After the user device receives the issuer list, S201 to S404 in the third embodiment are similar to S201 to S404 in the first and second embodiments. As in the second embodiment, the issuer system and / or the bridging system may not be able to completely resolve the merchant QR / payment link, but the issuer system and / or the bridging system may recognize the merchant QR / payment link as a payment request from an acquirer member and forward the unresolved portion of the merchant identity and payment data to the acquirer system for resolution. [Example]

[0044] Example 1 The following example describes a flowchart of the present invention implemented in iOS, as shown in Figure 6, which allows a portable device (e.g., a smartphone) to "scan" a QR code on its screen and pop up a list of issuer mobile apps installed on the portable device. Then, upon user selection, the selected mobile app automatically parses the merchant QR code and proceeds with the payment. In this example, the QR code is in a bridging service provider format.

[0045] In S501, the online merchant displays a QR code on the screen of the payer's user device (which is a portable device). The QR code is a universal link that has the domain name of the bridging service provider. In this example, the bridging service provider is called "HIVEX," and the universal link of the QR code is in the format "https: / / qr.hivex.com / {acquirer_name} / ABCDEFG," where "{acquirer_name}" indicates the acquirer and "ABCDEFG" indicates the online merchant.

[0046] In step S502, the payer delegates the universal link by long-pressing (or tapping) the QR code picture to open the universal link URL in a browser. After connecting to HIVEX's bridging system (a bridging service provider) in step S503, the bridging system provides a list for the portable device to check whether any of the HIVEX contract MPSP apps are installed on the portable device. If yes, in step S504, the portable device pops up a list showing all installed HIVEX contract MPSP apps based on the domain name matching (*.HIVEX.com) in the universal link URL (https: / / qr.hivex.com).

[0047] In step S505, the payer selects an installed HIVEX contract MPSP app (e.g., HIVEX-Wallet-App-1), and the selected HIVEX-Wallet-App-1 receives an NSUserActivity (e.g., activityType==NSUserActivityTypeBrowsingWeb.webpageURL==https: / / qr.hivex.com / {acquirer_name} / ABCDEFG) and redirects to a page based on the path parameters "{acquirer_name}" and "ABCDEFG." In S506, the selected HIVEX-Wallet-App-1 delegates the Universal Link QR code content, and the app parses the path parameter components "{acquirer_name}" and "ABCDEFG" from the Universal Link URL and initiates the payment flow.

[0048] Referring back to S503, the Bridging System checks whether any of the HIVEX Contract MPSP Apps are installed on the portable device. If not, then in S507 the portable device is redirected to an MPSP App Download webpage to download the App. The payer may already have an account with one or more acceptable issuers. In this case, the payer is instructed to download one of the Apps and log in with the selected issuer to proceed with the payment. If the payer is not registered with any of the acceptable issuers, the payer may be required to first register after downloading the App.

[0049] At S504, a bidirectional association is established between each issuer app and the HIVEX website. The first direction is to bind the app to the HIVEX URL, and the second direction is to bind the HIVEX URL to the app. The bidirectional association specifies the URL that the app handles. To bind the app to the HIVEX URL, the associated domain name (e.g., applinks:*.hivex.com) is added to the app configuration, as shown in FIG. 7A. To bind the HIVEX URL to the app, the exemplary json file shown in FIG. 7B is uploaded to the HIVEX website at "https: / / qr.hivex.com / .well-known / apple-app-site-association."

[0050] To invoke the HIVEX Contract Wallet App (Issuer App), the system then updates the HIVEX Contract Wallet App Delegate to respond when it receives an NSUserActivity object with activityType set to "NSUserActivityTypeBrowsingWeb". Sample code is shown in Figure 7C.

[0051] Example 2 The following is an example illustrating the present invention implemented on iOS. During web checkout, the payer may select one of the merchant acquirer checkout methods contracted with HIVEX (a bridging service provider). After the payer clicks the merchant acquirer checkout method button (e.g., Acquirer Name_1), the user receives a universal link string with the prefix "https: / / ***.HIVEX.com / {Acquirer Name_1} / ***" as an HIVEX merchant QR code (e.g., https: / / qr.hivex.com / {Acquirer Name_1} / ABCDEFG), which is displayed on the user's phone screen. The universal link string (associated HIVEX merchant QR code) may be generated after the payer requests checkout payment or may be generated in advance. In the first case, after the payer clicks the HIVEX checkout option, the merchant store may call the HIVEX system to request the universal link string and display the returned string as the associated HIVEX merchant QR code on the screen of the payer's portable device. In the second case, the HIVEX system may already send back the universal link string before the payer clicks on the HIVEX checkout option, thereby directly showing it to the payer as the associated HIVEX merchant QR code on the screen of the payer's portable device, as shown in Figure 8A.

[0052] All or some of the HIVEX contracted MPSPs have their own merchants, and these merchants are also registered in the HIVEX system. Every time the HIVEX system generates a merchant's QR code, the merchant's QR code may be linked to the target merchant on the acquirer's MPSP. In this case, the merchant's QR code may be decoded by the HIVEX system through a request sent from the HIVEX contracted user wallet app (issuer app) on the issuer's MPSP. The wallet app provided by any of the HIVEX contracted MPSPs is the HIVEX contracted wallet app.

[0053] From HIVEX's perspective, it is the MPSPs themselves, not the users of the MPSPs (e.g., payers and merchants), who participate in the HIVEX network. This is the transfer / receive of funds between different MPSP accounts on the HIVEX network when a cross-MPSP transaction occurs. To enable this, exposure limits may be set during provisioning on the HIVEX network that define the amount of currency funds that will be received from peer MPSPs.

[0054] All HIVEX subscriber user wallet apps, e.g., HIVEX-wallet-app-1 and HIVEX-wallet-app-2, have added "aplinks:*.HIVEX.com" as a domain name associated with the app. At the same time, HIVEX includes an associated domains file on the HIVEX website "https: / / qr.hivex.com / .well-known / apple-app-site-association" for these app identifiers (the appID and app key specify the application identifier for the app available for use on this website, along with its service type. The appID has the following format: <application identifier prefix><bundle identifier>). The method for establishing the bidirectional association is described in Example 1 above.

[0055] The payer may press and hold or tap the HIVEX merchant QR code on the screen, and the portable device then provides a menu based on the domain name in the universal link "*.HIVEX.com." The contents of the menu depend on the number of HIVEX contract wallet apps (issuer apps) the payer has installed. For example, if the payer installs three HIVEX contract wallet apps, the menu will show three apps for the payer to choose from. In one embodiment, the long press QR gesture is supported by the UIKit framework, which provides the necessary infrastructure for iOS apps.

[0056] If the payer has installed multiple wallet apps, some of which are HIVEX contract wallet apps, all installed HIVEX contract wallet apps are enumerated. For example, if there are three wallet apps (as shown in Figure 8B), HIVEX-wallet-app-1 (HIVEX contract wallet app), HIVEX-wallet-app-2 (HIVEX contract wallet app), and wallet-app-3 (non-HIVEX contract wallet app), only HIVEX-wallet-app-1 and HIVEX-wallet-app-2 are enumerated, as shown in Figure 8C.

[0057] Next, the payer selects one of the HIVEX contract wallet apps, HIVEX-wallet-app-1, and jumps to open HIVEX-wallet-app-1 based on the registered HIVEX domain name in the associated domain name universal link "https: / / qr.hivex.com".

[0058] In the step of selecting the HIVEX contract wallet app, an alternative method is to establish a preference list before redirecting to the HIVEX contract wallet app. This can be done by setting the order of dictionaries in an array, creating one dictionary for each app supported by the HIVEX domain name. This determines the order of the preference list the system follows when searching for a match, allowing you to specify which app handles a specific portion of the path in the universal link. In this way, the universal link directs the user to the HIVEX contract wallet app according to the preference list and the availability of the app on the portable device.

[0059] In some cases, the payer's portable device may not have an HIVEX contract wallet app available. If this occurs, the universal link may redirect to an HIVEX webpage instructing the user to install one of the HIVEX contract wallet apps to proceed with the payment.

[0060] After being selected, HIVEX-wallet-app-1 may receive the universal link URL “https: / / qr.hivex.com / {acquirer_name_1} / ABCDEFG”, then extract the path parameters “{acquirer_name_1}” and “ABCDEFG” from it, redirect the page, and let the payer input the payment amount after automatically decoding the HIVEX merchant QR code content, as shown in FIG. 8D .

[0061] Alternatively, the online merchant may call the HIVEX system to generate a QR code with the currency and payment amount embedded in it, which eliminates the need for the payer to enter the amount after automatically decoding the HIVEX merchant QR code content, eliminating the possibility of the payer entering an incorrect payment amount and facilitating payment verification for the merchant.

[0062] Whether or not the payment amount needs to be entered depends on the type of QR code. If the QR code is an embedded QR code that links to both predetermined amount information and merchant store information in the HIVEX system, the app will not require the payer to enter amount information after the QR code is resolved. If the QR code is a regular QR code that links only to merchant store information in the HIVEX system, the app will require the payer to enter amount information after the QR code is resolved.

[0063] The above example is performed in iOS. However, the present invention can also be implemented in other operating systems. For example, when using a portable device with an Android® system, the steps can also be implemented via Android App Links. Android App Links are functionally similar to Universal Links in iOS. Functionally, Universal Links / Android App Links allow a single link to open an app or a web page in a browser. Android App Links (sometimes called "Universal Links") are HTTP URLs available in Android 6.0 and above that may take users directly to an Android app. They include an autoVerify attribute that allows an app to designate itself as a given type of link.

[0064] Additionally, the bridging service provider (e.g., HIVEX) system may also provide a web page listing issuers selected by the payer before redirecting the user device to a universal link / Android app link to open a specific app, which may allow the bridging service provider to perform various functions such as promoting specific issuers, displaying only issuers in specific areas, displaying the issuer list in a predetermined order, etc.

[0065] The foregoing description of the embodiments is provided to enable any person skilled in the art to make and use the present subject matter. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the novel principles and subject matter disclosed herein may be applied to other embodiments without the use of innovative equipment. The claimed subject matter as set forth in the claims is not intended to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein. Additional embodiments are contemplated within the spirit and true scope of the disclosed subject matter. Thus, it is intended that the present invention cover modifications and variations that come within the scope of the appended claims and their equivalents.

Claims

1. 1. A method for online checkout between an issuer system of a selected issuer and an acquirer system of an acquirer, comprising: providing, by a bridging system of a bridging service provider, an issuer list including one or more available issuers to a payer user device; receiving, by the bridging system, a delivery request from the issuer system of the selected issuer selected from the one or more available issuers; Including, The delivery request is generated based on a checkout URL; The delivery request requests a delivery transaction to the acquirer system of the acquirer; The method, wherein the selected issuer is different from the acquirer.

2. before providing said issuer list comprising one or more available issuers; receiving, by the bridging system, a list request from the user device of the payer; The method of claim 1 further comprising:

3. The method of claim 2 , wherein the list request is redirected from the acquirer system before being received by the bridging system.

4. The method of claim 1 , wherein the user device is a portable device, and the checkout URL is configured to open an issuer app for the one or more available issuers installed on the portable device.

5. The method of claim 2 , wherein the checkout URL is configured to direct the user device to the bridging system.

6. The method of claim 5 , wherein the checkout URL is embedded in a QR code of the bridging service provider.

7. The method of claim 3 , wherein the checkout URL is configured to direct the user device to the acquirer system.

8. The method of claim 7 , wherein the checkout URL is embedded in the acquirer's QR code.

9. After receiving the delivery request from the issuer system, providing, by the bridging system, the delivery request to the acquirer system; receiving, by the Bridging System, a payment request from the Acquirer System; providing, by the bridging system, the payment request to the issuer system; receiving, by the bridging system, a payment confirmation from the issuer system confirming the payment request; providing, by the bridging system, the payment confirmation to the acquirer system; The method of claim 1 further comprising:

10. 1. A method for online checkout between an issuer system of a selected issuer and an acquirer system of an acquirer, comprising: receiving, by a payer user device, an issuer list including one or more available issuers; submitting, by the user device of the payer, a delivery request to the issuer system of the selected issuer selected from the one or more available issuers; Including, The delivery request is generated based on a checkout URL; The delivery request requests a delivery transaction to the acquirer system of the acquirer; The method, wherein the selected issuer is different from the acquirer.

11. prior to receiving the issuer list including one or more available issuers; providing a list request by the user device; The method of claim 10 further comprising:

12. The method of claim 10 , wherein the user device is a portable device, and the checkout URL is configured to open an issuer app for the one or more available issuers installed on the portable device.

13. The method of claim 11 , wherein the list request is provided to the acquirer system.

14. The method of claim 13 , wherein the issuer list is received from the acquirer system.

15. The method of claim 13 , wherein the issuer list is received from a bridging system of a bridging service provider.

16. The method of claim 11 , wherein the list request is provided to a bridging system of a bridging service provider, and the issuer list is received from the bridging system.

17. The method of claim 15 , wherein the list request is redirected from the acquirer system to the bridging system.

18. The method of claim 16 , wherein the checkout URL is configured to direct the user device to the bridging system.

19. The method of claim 18 , wherein the checkout URL is embedded in a QR code of the bridging service provider.

20. The method of claim 13 , wherein the checkout URL is configured to direct the user device to the acquirer system.

21. 21. The method of claim 20, wherein the checkout URL is embedded in the acquirer's QR code.

22. After providing the delivery request to the issuer system, receiving, by the user device, a payment request from the issuer system; providing, by the user device, a payment confirmation to the issuer system confirming the payment request; The method of claim 10 further comprising:

23. 1. A method for online checkout between an issuer system of a selected issuer and an acquirer system of an acquirer, comprising: receiving, by the issuer system of the selected issuer, a delivery request from a payer user device; providing, by the issuer system of the selected issuer, the delivery request to a bridging system of a bridging service provider; Including, The delivery request is generated based on a checkout URL; The delivery request requests a delivery transaction to the acquirer system of the acquirer; The method, wherein the selected issuer is different from the acquirer.

24. 24. The method of claim 23, wherein the issuer system does not resolve payment requests embedded in the checkout URL.

25. 25. The method of claim 24, wherein the checkout URL is resolved by the bridging system or the acquirer system.

26. after providing the delivery request to the bridging system; receiving, by the issuer system, a payment request from the bridging system; providing, by the issuer system, the payment request to the user device; receiving, by the issuer system, a payment confirmation from the user device confirming the payment request; providing, by the issuer system, the payment confirmation to the bridging system; 24. The method of claim 23, comprising:

27. 1. A method for online checkout between an issuer system of a selected issuer and an acquirer system of an acquirer, comprising: receiving, by an acquirer system of the acquirer, a list request from a payer user device; redirecting, by the acquirer system, the user device to a bridging system of a bridging service provider, whereby the bridging system provides the user device with an issuer list including one or more available issuers; receiving, by the acquirer system, a delivery request from an issuer system of the selected issuer via the bridging system, the selected issuer being selected from the one or more available issuers; Including, The delivery request is generated based on a checkout URL; The delivery request requests a transaction to the acquirer system of the acquirer; The method, wherein the selected issuer is different from the acquirer.

28. 28. The method of claim 27, wherein the user device is a portable device, and the checkout URL is configured to open an issuer app for the one or more available issuers installed on the portable device.

29. 28. The method of claim 27, wherein the checkout URL directs the user device to the acquirer system.

30. 30. The method of claim 29, wherein the checkout URL is embedded in the acquirer's QR code.

31. After receiving the delivery request from the issuer system, providing, by the acquirer system, a payment request to the bridging system; receiving, by the acquirer system, a payment confirmation from the bridging system confirming the payment request; 28. The method of claim 27, further comprising:

32. 1. A method for online checkout between an issuer system of a selected issuer and an acquirer system of an acquirer, comprising: receiving, by an acquirer system of the acquirer, a list request from a payer user device; providing, by the acquirer system, an issuer list including one or more available issuers to the user device of the payer; receiving, by the acquirer system, a delivery request from an issuer system of the selected issuer via a bridging system, the selected issuer being selected from the one or more available issuers; Including, The delivery request is generated based on a checkout URL; The delivery request requests a transaction to the acquirer system of the acquirer; The method, wherein the selected issuer is different from the acquirer.

33. 33. The method of claim 32, wherein the user device is a portable device, and the checkout URL is configured to open an issuer app for the one or more available issuers installed on the portable device.

34. 33. The method of claim 32, wherein the checkout URL directs the user device to the acquirer system.

35. 35. The method of claim 34, wherein the checkout URL is embedded in the acquirer's QR code.

36. After receiving the delivery request from the issuer system, providing, by the acquirer system, a payment request to the bridging system; receiving, by the acquirer system, a payment confirmation from the bridging system confirming the payment request; 33. The method of claim 32, further comprising:

Images