System and method for facilitating confirmation of electronic payment

Abstract

A system and method for facilitating electronic payment confirmation by generating a second confirmation page (SCP) of a second service provider different from a first confirmation page (FCP) of a first service provider in a bridge transaction. In the method, a bridging system of a service provider provides content of the SCP to a payer of a first service provider to generate the SCP. The generated SCP may then be presented to the recipient of the second service provider for confirmation by the recipient.

Description

Technical Field

[0001] Related Applications: This application claims the benefit of U.S. Provisional Application No. 63 / 378,048, filed on September 30, 2022, entitled “SYSTEMS AND METHODS TO FACILITATE ELECTRONIC PAYMENT CONFIRMATION,” the entire contents of which are incorporated herein by reference.

[0002] The present invention relates to a system and method for facilitating electronic payment confirmation, particularly for QR code payment between a payer of a service provider and a receiver of a different service provider. Background Art

[0003] QR code payment is a contactless payment method performed by scanning a QR code through a mobile application or a merchant's point of sale (POS) system. There are two types of QR code payment methods: merchant presented mode (MPM) and consumer presented mode (CPM). The difference lies in who presents the QR code for the other party to scan. In merchant presented mode (MPM), consumers use their smartphones to scan the QR code displayed by the merchant to make payments. Conversely, in consumer presented mode (CPM), merchants scan the QR code presented by consumers to receive payments. With QR code payment, transactions can be completed even without the infrastructure traditionally associated with electronic payments, such as payment cards, payment networks, payment terminals, and merchant accounts.

[0004] However, the above situation only applies to the case where the consumer and the merchant have accounts belonging to the same electronic payment system provider (service provider). In the case where the payment accounts of the consumer and the merchant belong to different service providers, transactions between the consumer and the merchant are impossible. In order to implement this transaction, a bridging service provider is required to connect the two service providers and perform a bridging transaction between the consumer and the merchant. The term "bridging" describes a system or method that enables the payer of the first service provider to present the subject (such as a QR code) of the second service provider to the recipient of the second service provider who cannot recognize the subject (such as a QR code) of the first service provider, so that the transaction between the payer and the recipient can be completed. The details of the bridging technology used in bridging transactions are described in PCT International Patent Publication Nos. WO2021 / 211773 and WO2023 / 132995. In short, bridging technology uses a bridging service provider as a "bridge" between different service providers in a bridging network, and enables a payer of any service provider to (1) recognize an object (such as a QR code) presented by a receiver of any other service provider, or (2) present an object (such as a QR code) that can be recognized by the receiver's device (such as a POS). In this way, QR code transactions can be conducted between different service providers without changing the merchant's existing infrastructure. The only change required is to update the software in the payer's mobile phone to allow bridging transactions. If the payer is a user of the first service provider, after the transaction, the payer will receive a confirmation page in the format of the first service provider, which is the same as the transaction within the payment network of the first service provider.

[0005] However, sometimes the payer needs to present a confirmation page from the recipient's service provider. For example, if the payer wants to return a product and request a refund, he / she may need to show the merchant a confirmation page so that the merchant can identify the exact transaction. Presenting the confirmation page in a format that the merchant is familiar with is more convenient in communication. In other examples, the payer may need to present a confirmation page from the recipient's service provider. In the case of some MPM transactions, the merchant has a fixed payment code, and the consumer usually presents the confirmation page to the merchant to confirm the transaction. If the above transaction is a bridge transaction, the merchant may not be able to recognize the confirmation page shown to the consumer because the consumer uses the services of another service provider and its confirmation page has a different format or even another language. Summary of the Invention

[0006] The present invention proposes "Dual Confirmation Page" (DCP) technology to address the aforementioned issues. DCP technology enables users of one service provider to provide a confirmation page formatted in the format of another service provider. This other service provider's confirmation page can then be presented to the merchant, thereby resolving the aforementioned issues faced by merchants.

[0007] One aspect of the present application provides a method for generating a second confirmation page (SCP) of a second service provider that is different from a first confirmation page (FCP) of a first service provider for use in a bridge transaction between a payer of the first service provider and a receiver of the second service provider. The method comprises: (1) a bridge system of a bridge service provider receives a second confirmation page (SCP) request including a transaction identification code from a first management system of the first service provider; (2) the bridge system searches a transaction database for transaction information corresponding to the transaction identification code; (3) the bridge system generates an SCP content file including page layout information for generating the SCP; and (4) the bridge system provides the SCP content file to the first management system. In the present method, the first service provider is different from the bridge service provider and the second service provider. In one embodiment, the transaction identification code is an identification code that can be recognized by the bridge system and uniquely identifies the transaction between the payer and the receiver.

[0008] The method may further include the following steps: (1) the bridging service provider identifies the second service provider from a plurality of acquirers based on the transaction information; and (2) the bridging service provider generates the SCP content file of the second service provider. In one embodiment, the SCP content file includes a text content and an image reference content. In a preferred embodiment, the SCP content file includes an HTML file for generating the SCP. In one embodiment, the image reference content provides a URL for accessing the SCP image content, and the SCP image content is provided by an image database that stores image content of a plurality of acquirers.

[0009] After providing the SCP content file to the first management system, the method may further include: (1) receiving, by the bridging service provider, an image request for SCP image content from a portable device of the payer based on the SCP content file; and (2) providing, by the bridging service provider, the SCP image content to the portable device of the payer.

[0010] In one embodiment, the transaction database stores transaction information of transactions between the first service provider and the plurality of acquirers. The transaction information corresponding to the transaction identification code may include a recipient name, a transaction number, a transaction time, a transaction currency, and a transaction amount.

[0011] In a preferred embodiment, the generated second confirmation page (SCP) is displayed on the portable device together with the first confirmation page (FCP) generated by the first management system to form a dual confirmation page (DCP). The dual confirmation page (DCP) may have a tab for switching between the first confirmation page (FCP) and the second confirmation page (SCP).

[0012] Another aspect of the present application provides a system for generating a second confirmation page (SCP) of a second service provider that is different from a first confirmation page (FCP) of a first service provider for a bridge transaction between a payer of the first service provider and a receiver of the second service provider that is one of a plurality of acquirers, the system comprising: (1) a transaction database, (2) an image database, and (3) a view maker. The transaction database is configured to store information of the bridge transaction between the first service provider and the plurality of acquirers; the image database is communicatively connected to the transaction database and is also communicatively connected to a first management system of the first service provider. The view maker is also communicatively connected to the first management system and includes instructions stored thereon, the instructions being configured to perform operations including the following in response to execution of the instructions: (1) receiving a second confirmation page (SCP) request including a transaction identification code from the first management system of the first service provider; (2) searching the transaction database for transaction information corresponding to the transaction identification code; (3) generating an SCP content file including page layout information for generating the SCP based on the transaction information; and (4) providing the SCP content file to the first management system; and wherein the first service provider is different from the second service provider.

[0013] In one embodiment, the image database is configured to: (1) receive an image request for SCP image content from the first management system based on an SCP content archive; and (2) provide the SCP image content to the first management system. In one embodiment, the view maker is configured to be communicatively connected to a plurality of issuers, one of which is the first management system of the first service provider.

[0014] Other objects, advantages and novel features of the present invention will become more apparent from the following detailed description in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 Shown is a system for implementing bridge transactions.

[0016] Figure 2 Shown are systems and methods for implementing double confirmation page (DCP) technology.

[0017] Figures 3 to 7 An example showing the user flow of an application (App) running DCP. Figure 3 Shows the steps from the beginning to "Select Payment Method." In this example, Pi Wallet is the first service provider, and PayPay is selected as the second service provider. The "HIVEX API" logo in the image indicates that a bridge service provider is involved in this step.

[0018] Figure 4 The steps in a Merchant Presentation Mode (MPM) bridge transaction from "selecting MPM as the payment mode" to "sending payment confirmation to the bridge service provider." The "HIVEX API" logo in the diagram indicates that the bridge service provider is involved in this step.

[0019] Figure 5 The steps in a Consumer Presentation Model (CPM) bridge transaction from "Select CPM as a payment method" to "Merchant scanning process." The "HIVEX API" logo in the diagram indicates that a bridge service provider is involved in this step.

[0020] Figure 6 This is the double confirmation page (DCP) when a transaction fails. The left side is the second confirmation page in the format of the second service provider (PayPay), and the right side is the first confirmation page in the format of the first service provider (Pi Wallet).

[0021] Figure 7 This is the double confirmation page (DCP) when the transaction is successful. The left side is the second confirmation page in the format of the second service provider (PayPay), and the right side is the first confirmation page in the format of the first service provider (Pi Wallet). DETAILED DESCRIPTION

[0022] The terms used in this specification are intended to be interpreted in their broadest reasonable manner, even when used in conjunction with the detailed description of certain specific embodiments of the present technology. Certain terms may even be specifically emphasized below; however, any term intended to be interpreted in any limited manner will be specifically defined in this detailed description section.

[0023] The embodiments described below may be implemented using programmable circuits programmed or configured using software and / or firmware, or entirely using special-purpose circuits, or a combination thereof. Such special-purpose circuits, if any, may be, for example, one or more application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), and the like.

[0024] The present application provides a method and system for enabling a portable device (e.g., a mobile phone) of a first service provider to provide a transaction confirmation page (second confirmation page) of a second service provider, wherein the first service provider is different from the second service provider, and the second confirmation page can be displayed on the screen of the portable device. In this specification, the confirmation page of the first service provider is referred to as the first confirmation page, and the confirmation page of the second service provider is referred to as the second confirmation page. This method can generate a second confirmation page (second confirmation page, SCP) in addition to the first confirmation page (first confirmation page, FCP), and these two pages are collectively referred to as "dual confirmation page" (dual confirmation page, DCP). This method is very practical in bridged QR code transactions in merchant presentment mode (MPM), especially when the recipient (e.g., merchant) does not have a POS system to immediately check the transaction results (and therefore can only rely on the payer to present the confirmation page on his / her portable device).

[0025] See also Figure 1 In a bridged QR code transaction, the consumer usually acts as the payer 11, and the merchant usually acts as the receiver 15. Here we assume that the payer 11 is a user of the first service provider 12, and the receiver 15 is a user of the second service provider 14.

[0026] In a Merchant Presentation Mode (MPM) bridged QR code transaction, the recipient 15 (merchant) first presents the receiving QR code from the second service provider 14. The payer 11 (e.g., consumer) scans the QR code using a portable device and transmits the QR code content to the first management system 120 of the first service provider 12. The first management system 120 then forwards the QR code content to the bridge system 130 of the bridge service provider 13. The bridge system 130 then sends the QR code content, along with the payer 11's identity information, to the second management system 140 of the second service provider 14. Upon receiving a request from the payer 11, the second management system 140 transmits the recipient's identity information back to the payer 11's portable device 110 via the bridge system 130 and the first management system 120. The payer 11 then enters the intended transfer amount and confirms the payment by sending confirmation to the first management system 120, the bridge system 130, and the second management system 140 to proceed with the payment. Alternatively, some QR codes presented by the recipient 15 may include the currency and amount of payment. In this case, the payer 11 only needs to confirm the payment and does not need to enter the amount to be transferred in the returned confirmation information.

[0027] In a bridged QR code transaction in a consumer presentation mode (CPM), the payer 11 (consumer) needs to request a QR code in the format of a second service provider to conduct a CPM bridge transaction. First, the payer 11 requests a payment QR code from the second service provider 14. The first management system 120 of the first service provider 12 receives the request and forwards the request to the bridge system 130 of the bridge service provider 13. The bridge system 130 then returns a bridged payment QR code to the portable device 110 via the first management system 120. The details of requesting and returning a bridged QR code used in a bridged transaction are described in PCT International Patent Publication No. WO2023 / 132995 and are incorporated herein by reference in their entirety. The payer 11 displays the bridged payment QR code on the portable device 110, and the recipient 15 scans it through a merchant device. The merchant device then transmits the QR code content to the second management system 140 of the second service provider 14, which in turn forwards the QR code content to the bridging system 130 of the bridging service provider 13. Depending on the system configuration, the bridging system 130 can proceed directly with the bridging transaction or first request confirmation from the payee 11. The bridging system 130 then executes the transaction and pushes a notification informing the payee 11 (via the first management system 120) and the recipient 15 (via the second management system 140) of the transaction result.

[0028] In this network, the bridging service provider 13 acts as a "bridge" between the payment systems of the first service provider 12 and the second service provider 14. More generally, in a bridging network comprising many service providers, the bridging service provider 13 acts as a "bridge" between any two service providers conducting bridged transactions.

[0029] In one embodiment, after receiving a notification confirming a successful bridge transaction, the portable device 110 (e.g., the mobile phone of the payee 11) requests bridge transaction information and image / text data from the second service provider 14. As described above, the second service provider 14 is the service provider used by the recipient 15 to accept payments, and is different from the first service provider 12 used by the payee 11 to make payments. A program installed on the portable device 110 can request bridge transaction information (e.g., the recipient's name, time, transaction number, currency, and amount) and image / text data (e.g., the image and text on the confirmation page) from the bridge network, and combine them to generate a second confirmation page for the transaction in the format of the second service provider 14. For example, the program on the portable device 110 can request the required transaction information and image / text data from the first management system 120 of the first service provider 12 or the bridge system 130 of the bridge service provider 13.

[0030] In another embodiment, a program installed on portable device 110 (such as payee 11's mobile phone) obtains bridge transaction information during the bridge transaction process. For example, in the MPM, upon QR code scanning, payee 11's portable device 110 initiates a payment transaction and relays the request via the portable device 110-first management system 120-bridge system 130-second management system 140 route. Second management system 140 then sends the name of recipient 15 back to payee 11 via the reverse route: second management system 140-bridge system 130-first management system 120-portable device 110. Depending on the QR code content, second management system 140 may also send the transaction amount / currency for payee 11 to confirm, or it may send the recipient information without specifying the transaction amount and leave it blank for payee 11 to enter. In both cases, the portable device 110 of the payer 11 can collect information such as the identity of the second service provider 14, the name of the recipient 15, and the amount / currency to be transferred in the bridge transaction. Similarly, in CPM, the portable device 110 can collect transaction information during the scanning and confirmation steps. The image / text data of the second service provider 14 can be requested from the network (e.g., a content delivery network) or can be pre-stored in the application for use in the production of the second confirmation page. The program in the portable device 110 can then combine the transaction information and the image / text data to generate a second confirmation page in the format of the second service provider 14.

[0031] In a preferred embodiment, the program in the portable device 110 can directly request the full content of the second confirmation page, rather than requesting the transaction information and image / text data separately and then combining them. The full content of the second confirmation page can be provided by the bridging service provider 13, which acts as a "bridge" between the payer of the first service provider 12 and the recipient of the second service provider 14. The bridging system 130 of the bridging service provider 13 can record information about the bridged transaction in its database and store the image and text data of all participating service providers. Upon request, the bridging system 130 of the bridging service provider 13 can then provide the transaction information (e.g., recipient name, transaction amount / currency) and the image / text data of the second service provider's confirmation page. This information / data can be provided together in the form of a complete confirmation page (second confirmation page) in the format of the second service provider 14. In one example, the information of the second confirmation page can be provided in a markup language such as an HTML file. The HTML file can contain links to the textual content of the confirmation page and the image content. Then, portable device 110 can generate a complete confirmation page based on the HTML file and display the second confirmation page on the screen of the portable device. Alternatively, the complete content of the second confirmation page can also be provided as an entire image, for example, as a JPG file.

[0032] Regarding the system for generating a DCP, in one embodiment, the system includes a first management system 120 of a first service provider 12, a bridging system 130 of a bridging service provider 13, and a portable device 110 of a payer 11. Furthermore, a second management system 140 of a second service provider 14 is generally included. In this system, the first management system 120 is communicatively connected to the portable device 110 and the bridging system 130. The second management system 140 is also communicatively connected to the bridging system 130. The system configuration of the present invention is as follows: Figure 1 and Figure 2 As shown. This configuration enables a bridge transaction between a payer 11 of a first service provider and a receiver 15 of a second service provider. In addition, if the required information is provided, this configuration can also generate a DCP after the bridge transaction. For details on bridge transactions, PCT International Patent Publication Nos. WO2021 / 211773 and WO2023 / 132995 are fully incorporated herein by reference. In short, the bridge service provider 130 acts as a "bridge" between the payer 11 of the first service provider 12 and the receiver 15 of the second service provider 14 to facilitate transactions between the two parties. When the bridge transaction is processed and confirmed, the bridge service provider 13 (e.g. Figure 2 The bridging system 130 of HIVEX shown in FIG. 1 pushes a notification to the portable device 110 through the first management system 120 of the first service provider 12, such as Figure 2 As described in steps S111, S112 and S113.

[0033] To generate the DCP, a confirmation page (first confirmation page) in the format of the first service provider can be generated upon receiving the notification and displayed on the screen of the portable device 110, as would typically be performed in a transaction on the network of the first service provider 12. The confirmation page typically includes transaction information such as the recipient's name, transaction number, transaction time, transaction currency, and transaction amount. The confirmation page generated in the format of the first service provider can be presented by the payer 11 to the recipient 15 as confirmation of payment.

[0034] In order for the payer 11 to generate a confirmation page in the second service provider's format (the second confirmation page), the portable device 110 of the payer 11 requests the necessary information to generate a new confirmation page. This required information may include transaction information and the second service provider's image / text format. When performing a bridged transaction, the bridging system 130 of the bridging service provider 13 may maintain a database that records transactions between different service providers bridged by the bridging service provider 13, such as transactions between the payer 11 of the first service provider 12 and the recipient 15 of the second service provider 14. Typically, the first service provider 12 and / or the second service provider 14 also maintain their own databases to store data on processed bridged transactions. Transaction information can be retrieved from the databases of the first service provider 12 or the bridging service provider 13 and sent to the portable device 110 by the first management system 120 of the first service provider 12. The image / text format of the second service provider 14 can be obtained from the entire bridging network, including the first service provider 12, the second service provider 14, and / or the bridging service provider 13. In one embodiment, the image and text formats of the second service provider 14 are obtained by the bridge system 130 of the bridge service provider 13 .

[0035] The computer program (e.g., an App) in the portable device 110 can collect the transaction information and image / text format of the second service provider 14 and integrate the above information to generate a second confirmation page for the second service provider 14. Alternatively, if the first management system 120 or the bridge system 130 has already integrated the content of the second confirmation page, the portable device can simply receive the data without integrating it.

[0036] Flowchart for generating the second confirmation page (SCP)

[0037] Figure 2An example of a system for generating an SCP is shown. The system 100 includes a first management system 120 of a first service provider, a bridging system 130 of a bridging service provider, and a portable device 110 of a payer. The first management system 120 of the first service provider (or "issuer") can be communicatively connected to the bridging system 130 of the bridging service provider (or "HIVEX"). The first management system 120 can include an application server 121, a push server 122, and an elastic load balancer (ELB) 123 to perform functions related to generating an SCP. The application server 121 can be configured as a virtual machine (VM) located in the cloud (e.g., Amazon Web Services (AWS)) associated with executing bridging transactions of the first management system 120. This can include, but is not limited to, processing incoming requests / notifications and / or redirecting the requests / notifications to the correct destination. For example, the application server 121 can redirect transaction notifications from the bridging system 130 to the correct portable device 110 of the payer 11 based on the user identification code, or can redirect SCP requests from the portable device 110 to the bridging system 130. The push server 122 can be a logically isolated virtual network located in the cloud (e.g., Amazon Virtual Private Cloud), which is configured to forward notifications from the application server 121 to the portable device 110 of the payer 11. The elastic load balancer 123 can be a network service that distributes network traffic to improve application scalability, such as a service provided by AWS, which is configured to receive requests from the portable device 110 to the application server 121. The bridging system 130 of the bridging service provider can include a view generator 131, a transaction database 132 (or "work model"), and an image database 133 (which can be a content delivery network (CDN)). In one embodiment, the view generator can receive SCP requests from the application server 121 and return the SCP content based on the request. The transaction database 132 (working model) is configured to record transactions between different service providers bridged by the bridging service provider (e.g., transactions between a payer of a first service provider and a receiver of a second service provider). The image database 133 in this example is a geographically distributed network of proxy servers and their cloud-based data centers, configured to provide high availability and efficiency by spatially distributing services relative to end users, such as the CDN provided by AWS. This image database can be used to store image resources required to generate the confirmation page.When multiple service providers exist within the bridged network, the image database can store image resources from multiple service providers. The first management system 120 can run two components within its system. The first component is a non-cloud-based server that performs traditional service provider functions, such as connecting to members and executing transactions within the first service provider 12. The second component, including the application server 121, the push server 122, and the ELB 123, is a cloud-based server configured to connect to the bridged network via the bridge system 130. In this example, the application server 121, the push server 122, and the ELB 123 are virtual machines (VMs) on the cloud. User applications (apps) on the portable device 110 can establish connections to the push server 122 via the first management system 120. In this example, the push server 122 and the ELB 123 act as intermediaries between the user application 110 and the application server 121 VM. This provides greater security for the application server 121, preventing it from being overwhelmed by data traffic or attacked by malicious users.

[0038] After the bridging transaction, the bridging system 130 of the bridging service provider (HIVEX) can push a notification to the user (ie, payer) 110 of the first service provider via the first management system 120 of the first service provider, such as Figure 2 . In step S111, the first management system (issuer) 120 of the first service provider receives the confirmation in its application server 121 by the bridge system (HIVEX) 130. The first management system 120 then forwards the confirmation to the payer's portable device 110 via the push server 122 and the non-cloud server (not shown in the figure), as shown in S112 and S113. The function of the traditional service provider can generate a first confirmation page. In order for the payer to provide a confirmation page in the format of another service provider (for example, a second confirmation page in the format of a second service provider), the application installed in the payer's portable device 110 will request a confirmation page containing transaction details and image format. As shown in FIG. Figure 2 As shown, the request along with the user identification code is transmitted to the non-cloud server of the first management system 120, an elastic load balancer (ELB) 123 connected to the application server 121 of the first service provider (step S121), and then to the application server 121 (step S122). Then, the application server 121 of the first service provider forwards the request to the bridge system 130 (e.g. Figure 2The view maker 131 in the bridge system 130 (HIVEX) is connected to the user application 110 (step S123). Upon request, the view maker 131 in the bridge system 130 transmits the user identification code provided by the payer's 110 portable device to the transaction database 132 and retrieves the value recorded in the transaction database 132 (working model) (steps S124 and S125). The view maker 131 then returns the content of the second confirmation page in the format of the second service provider 14 to the user application 110 based on the user identification code. In this example, the content of the second confirmation page is generated by the view maker 131 in an HTML file. Based on the user identification code, the bridge system 130 and the first management system 120 can identify the user application 110 logged in using the payer's account. The bridge system 130 (HIVEX) then returns the content of the confirmation page to the user application 110 via the reverse path via the first management system 120 of the first service provider (steps S126, S127, and S128). Next, the user application 110 can retrieve the image data of the second confirmation page from the image database 124 based on the HTML file and generate the second service provider's confirmation page based on the content of the second confirmation page (step S129). Depending on the configuration and security requirements, the image data can be obtained directly from the Internet (if the image database can be directly accessed from the Internet), or can be transmitted from the bridge system 130 to the portable device 110 via the first management system 120 via a secure transmission. The generated second confirmation page can be displayed on the portable device 110 for the merchant to confirm.

[0039] Double confirmation page and scalability of bridge networks

[0040] In the above example, the bridge system 130 provides the complete content of the second confirmation page for the second service provider. The user application 110 passively receives the content and retrieves image resources from the image database to generate the confirmation page based on an HTML file. Therefore, other than establishing a connection with the bridge system, the first service provider does not need to implement any additional systems for generating the DCP.

[0041] Imagine a bridge network with many (e.g., 100) participating service providers. If any of these 100 service providers were configured to generate their own DCPs, the network would need to store 9,900 copies of confirmation page image data from different service providers. If any one participating service provider changed its image format, all other 99 service providers would need to update their systems accordingly. Failure to update in a timely manner would render the second confirmation page invalid. Furthermore, it would be difficult for the bridge service provider to ensure the accuracy of the image resources stored on the participating service providers' servers.

[0042] The present invention provides a paradigm in which the content of an SCP (including image resources and transaction details) is provided by the bridging system of a bridging service provider. This allows participating service providers to more conveniently implement this functionality within their systems. Furthermore, the content of the generated DCP is controlled by the bridging system (meaning that participating service providers cannot generate SCPs for any other service provider). No service provider needs to store the formatting content and image resources associated with SCP generation. As the bridging network expands (due to the participation of more service providers), participating service providers do not need to modify their systems at all.

[0043] DCP function on portable devices

[0044] Figure 3-7 is an example showing how DCP technology works on a portable device. In this example, a user travels to Japan and wants to pay in a foreign store via mobile payment. At this time, bridging technology must be used to enable transactions between two mobile payment systems. In this example, Pi Wallet is used to make payments (i.e., Pi Wallet as the first service provider), and PayPay is selected as the recipient of the payment (i.e., PayPay as the second service provider). After selecting PayPay as the second service provider, the application further instructs the user to select a payment mode, i.e., Consumer Presentation Mode (CPM) or Merchant Presentation Mode (MPM), as shown in Figure 3 In the merchant presentation mode (MPM), when the user (payer) enters and confirms the payment amount, the application will enter the transaction result page, as shown in Figure 4 On the other hand, in the consumer presentation mode (CPM), when the merchant scans the bridge QR code, the application will also enter the transaction result page, as shown in Figure 5 Regardless of whether the transaction is successful or not, the application will display the Double Confirmation Page (DCP). Figure 6 It is the DCP whose transaction failed. Figure 7 It is the DCP of a successful transaction. The DCP consists of two parts: a first confirmation page in the format of the first service provider (Pi Wallet), and a second confirmation page of the second service provider (PayPay).

[0045] For small merchants, the QR codes they display are often fixed, and they often don't have a point-of-sale (POS) system to immediately receive transaction results. With DCP technology, merchants can confirm transaction status to consumers even if they don't understand the language displayed on the first service provider's confirmation page (in this case, Chinese). DCP technology makes transaction confirmation easier, thereby facilitating cross-border electronic payments.

[0046] The embodiments provided above are intended to enable any person of ordinary skill in the art to make and use the present invention. Various modifications to these embodiments will be apparent to those skilled in the art, and the novel principles disclosed herein and the present invention may be applied to other embodiments without the need for inventiveness. The invention claimed in this application is not intended to be limited to the embodiments shown herein, but is to be construed in the widest sense consistent with the principles and novel features disclosed herein. Additional embodiments are expected to fall within the spirit and scope of the invention disclosed in this application. Therefore, the present invention is intended to cover modifications and variations that fall within the scope of this application and its equivalents.

Claims

1. A method for generating a second confirmation page (SCP) of a second service provider that is different from a first confirmation page (FCP) of a first service provider for use in a bridge transaction between a payer of the first service provider and a receiver of the second service provider, comprising: receiving, by a bridging system of the bridging service provider, a second confirmation page (SCP) request including a transaction identification code from a first management system of the first service provider; The bridge system searches a transaction database for transaction information corresponding to the transaction identification code; generating, by the bridge system, an SCP content file containing page layout information for generating the SCP; as well as; The bridge system provides the SCP content file to the second management system; The first service provider is different from the bridge service provider and the second service provider.

2. The method of claim 1 , wherein generating the SCP content archive comprises the following steps: identifying, by the bridging service provider, the second service provider from a plurality of acquirers based on the transaction information; as well as The SCP content archive of the second service provider is generated by the bridge service provider.

3. The method of claim 2, wherein the SCP content file comprises text content and image reference content.

4. The method of claim 3, further comprising, after providing the SCP content file to the first management system: Receiving, by the bridging service provider, an image request for SCP image content from the payer's portable device based on the SCP content profile; as well as The bridging service provider provides the SCP image content to the portable device of the payer.

5. The method of claim 4, wherein the image referential content provides a URL for accessing the SCP image content.

6. The method of claim 4, wherein the SCP image content is provided by an image database storing image contents of a plurality of acquirers.

7. The method of claim 1, wherein the SCP content archive comprises an HTML archive used to generate the SCP.

8. The method of claim 2, wherein the transaction database stores transaction information of transactions between the first service provider and the plurality of acquirers.

9. The method of claim 1, wherein the transaction identification code is an identification code that can be recognized by a bridging system and uniquely identifies the transaction between the payer and the recipient.

10. The method of claim 1, wherein the transaction information corresponding to the transaction identification code includes a recipient name, a transaction number, a transaction time, a transaction currency, and a transaction amount.

11. The method of claim 1, wherein the generated second confirmation page (SCP) is displayed on the portable device together with the first confirmation page (FCP) generated by the first management system to form a double confirmation page (DCP).

12. The method of claim 11, wherein the dual confirmation page (DCP) has a tab for switching between the first confirmation page (FCP) and the second confirmation page (SCP).

13. A system for generating a second confirmation page (SCP) of a second service provider that is different from a first confirmation page (FCP) of a first service provider for use in a bridge transaction between a payer of the first service provider and a receiver of the second service provider that is one of a plurality of acquirers, comprising: a transaction database configured to store information of bridged transactions between the first service provider and the plurality of acquirers; an image database configured to store image contents of confirmation pages of the plurality of acquirers; as well as a view maker communicatively coupled to the transaction database and configured to be communicatively coupled to a first management system of the first service provider; The view maker includes instructions stored thereon, the instructions being configured to, in response to execution of the instructions, perform operations including: receiving a second confirmation page (SCP) request including a transaction identification code from the first management system of the first service provider; searching the transaction database for transaction information corresponding to the transaction identification code; generating an SCP content file including page layout information for generating the SCP based on the transaction information; as well as Providing the SCP content archive to the first management system; And wherein the first service provider is different from the second service provider.

14. The system of claim 13, wherein the SCP content file comprises text content and image reference content.

15. The system of claim 14, wherein the image referencing content provides a URL for accessing the SCP image content.

16. The system of claim 13, wherein the image database is configured to: receiving an image request for SCP image content from the first management system based on the SCP content archive; and The SCP image content is provided to the first management system.

17. The system of claim 13, wherein the SCP content archive comprises an HTML archive for generating the SCP.

18. The system of claim 13, wherein the view maker is configured to be communicatively connected to a plurality of issuers, one of which is the first management system of the first service provider.

19. The system of claim 13, wherein the transaction identification code is an identification code recognizable by the view maker that uniquely identifies a transaction between a payer of the first service provider and a receiver of the second service provider.

20. The system of claim 13, wherein the transaction information corresponding to the transaction identification code includes a recipient name, a transaction number, a transaction time, a transaction currency, and a transaction amount.

21. The system of claim 13, wherein the generated second confirmation page (SCP) is displayed on the portable device together with the first confirmation page (FCP) generated by the first management system to form a double confirmation page (DCP).

22. The method of claim 21, wherein the dual confirmation page (DCP) has a tab for switching between the first confirmation page (FCP) and the second confirmation page (SCP).

Images