System and method for facilitating verification of electronic payments

Abstract

The present invention relates to a system and method for facilitating confirmation of electronic payments in bridge transactions by generating a second service provider's second confirmation page (SCP) that differs from the first service provider's first confirmation page (FCP). In this method, a service provider's bridge system provides SCP content for the first service provider's payer to generate the SCP. The generated SCP may then be presented to the second service provider's payee for payee confirmation.

Description

[Technical Field]

[0001] Related Applications This application claims the benefit of U.S. Provisional Application No. 63 / 378,048, filed September 30, 2022, and entitled "SYSTEMS AND METHODS TO FACILITATE ELECTRONIC PAYMENT CONFIRMATION," which is incorporated herein by reference in its entirety.

[0002] The present invention relates to a system and method for facilitating electronic payments, and in particular, confirmation of QR code payments between a payer at one service provider and a payee at a different service provider. [Background technology]

[0003] QR code payment is a contactless payment method conducted by scanning a QR code from a mobile app 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), which differ in which party presents the QR code for the other party to scan. In merchant-presented mode (MPM), a consumer scans a QR code displayed by a merchant with their smartphone to make a payment. Conversely, in consumer-presented mode (CPM), a merchant scans a QR code displayed by the consumer to receive a payment. With QR code payments, transactions can occur even without the infrastructure traditionally associated with electronic payments, such as a payment card, payment network, payment terminal, and merchant account.

[0004] However, the above situation applies only when the consumer and merchant who hold the account belong to the same electronic payment system provider (service provider). If the consumer and merchant's payment accounts belong to different service providers, a transaction between the consumer and the merchant is not possible. To enable the transaction, a bridge service provider is required to connect the two service providers, and the bridge transaction is conducted between the consumer and the merchant. The term "bridge" or "bridging" describes a system or method that allows a payer at a first service provider to present a target (e.g., a QR code) at a second service provider to a payee at the second service provider who does not recognize the target (e.g., the QR code) at the first service provider, thereby completing the transaction between the payer and the payee. Details of the bridge technology used in bridge transactions are described in PCT International Patent Publications WO2021 / 211773 and WO2023 / 132995. Briefly, bridge technology employs a bridge service provider as a "bridge" between various service providers in a bridge network, allowing a payer from any service provider to either (1) recognize a target (e.g., a QR code) presented by a payee from any other service provider, or (2) present a target (e.g., a QR code) that the payee's device (e.g., a POS) can recognize. Such QR code transactions can be conducted between various service providers without modifying the merchant's existing infrastructure. The only requirement is that the software in the payer's mobile phone be updated to enable bridge transactions. If the payer is a user of the first service provider, after the transaction, the payer receives a confirmation page in the first service provider's format, and the first service provider then similarly conducts the transaction within the first service provider's payment network.

[0005] However, there are cases where the payer is required to show the confirmation page of the payee's service provider. For example, if the payer wants to return an item and request a refund, the payer may need to show the confirmation page to the merchant so that the merchant can identify the exact transaction. Presenting the confirmation page in a format that the merchant is familiar with is significantly more convenient for communication. There are other instances where the payer may be required to show the confirmation page of the payee's service provider. In some cases of MPM transactions, the merchant has a fixed code for payment capture, and the transaction is usually confirmed by the consumer showing the confirmation page to the merchant. If the transaction described above is a bridge transaction, the merchant may have trouble recognizing the confirmation page shown by the consumer because the confirmation page may be in a different format or even a different language if the consumer is using a service from a different service provider. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] PCT International Patent Publication No. WO2021 / 211773 [Patent Document 2] PCT International Patent Publication No. WO2023 / 132995 Summary of the Invention [Problem to be solved by the invention]

[0007] In order to address the above-mentioned problems, the present invention provides a "Dual Confirmation Page" (DCP) technology. The DCP technology allows a user of one service provider to provide a confirmation page in the format of another service provider. The confirmation page of the other service provider is shown to the merchant, thereby solving the above-mentioned problems encountered by the merchant. [Means for solving the problem]

[0008] One aspect of the present application provides a method for bridging a transaction between a payer of a first service provider and a payee of a second service provider by generating a second confirmation page (SCP) of a second service provider that is different from a first confirmation page (FCP) of the first service provider. The method includes: (1) receiving, by a bridge system of the bridge service provider, a second confirmation page (SCP) request from a first management system of the first service provider, the second confirmation page (SCP) request including a transaction identifier; (2) searching, by the bridge system, a transaction database for transaction information corresponding to the transaction identifier; (3) generating, by the bridge system, an SCP content file including page layout information for generating the SCP; and (4) providing, by the bridge system, the SCP content file to the first management system. In the method, the first service provider is different from the bridge service provider and the second service provider. In one embodiment, the transaction identifier is an identifier recognizable to the bridge system, and the bridge system uniquely identifies the transaction between the payer and the payee.

[0009] The method may further include (1) identifying, by the bridge service provider, a second service provider from the plurality of acquirers based on the transaction information; and (2) generating, by the bridge service provider, an SCP content file for the second service provider. In one embodiment, the SCP content file includes text content and image referencing content. In a preferred embodiment, the SCP content file includes an HTML file that generates the SCP. In one embodiment, the image referencing content provides a URL to access SCP image content, and the SCP image content is provided from an image database that stores image content for multiple acquirers.

[0010] After providing the SCP content file to the first management system, the method may further include (1) receiving, by the bridge service provider, an image request for the SCP image content from the payer's portable device based on the SCP content file, and (2) providing, by the bridge service provider, the SCP image content to the payer's portable device.

[0011] In one embodiment, the transaction database stores transaction information for transactions between a first service provider and a plurality of acquirers, and the transaction information corresponding to a transaction identifier may include a payee name, a transaction number, a transaction time, a transaction currency, and a transaction amount.

[0012] 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), which may have tabs for switching between the first confirmation page (FCP) and the second confirmation page (SCP).

[0013] Another aspect of the present application provides a system for bridging a transaction between a first service provider and a second service provider that is one of a plurality of acquirers by generating a second confirmation page (SCP) for the second service provider that is different from the first service provider's first confirmation page (FCP), the system comprising: (1) a transaction database; (2) an image database; and (3) a view maker. The transaction database is configured to store information for bridging a transaction between the first service provider and the plurality of acquirers, the image database is configured to store image content for the confirmation pages of the plurality of acquirers, and the view maker is configured to be communicatively connected to the transaction database and to a first management system of the first service provider. The view maker also includes instructions stored on the view maker, and in response to execution of the instructions, the view maker is configured to perform operations including: (1) receiving a second confirmation page (SCP) request from a first management system of a first service provider, the second confirmation page (SCP) request including a transaction identifier; (2) searching a transaction database for transaction information corresponding to the transaction identifier; (3) generating an SCP content file based on the transaction information, the SCP content file including page layout information for generating the SCP; and (4) providing the SCP content file to the first management system. The second service provider configured to interface with the system is different from the first service provider.

[0014] 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 the SCP content file, and (2) provide the SCP image content to the first management system. In one embodiment, the view maker is configured to communicatively connect to a plurality of issuers, one of the plurality of issuers being the first management system of the first service provider.

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

[0016] [Figure 1] FIG. 1 is a diagram of a system for implementing bridge trading. [Figure 2] 1 is a diagram of a system and method for implementing dual verification page (DCP) technology. [Figure 3] An example diagram of a user wireflow for an app implementing DCP. Figure 3 shows the steps from initiation to "select payment mode." In this example, Pi Wallet is the first service provider and PayPay® is selected as the second service provider. The "HIVEX® API" logo in this diagram means that a bridge service provider is involved in this step. [Figure 4] An example diagram of a wireflow for a user of an app implementing DCP. Figure 4 shows a merchant-presented mode (MPM) bridge transaction from the step "select MPM as payment mode" to the step "send payment confirmation to bridge service provider." The "HIVEX API" logo in this diagram indicates the involvement of a bridge service provider in this step. [Figure 5] Figure 5 shows an example of a wireflow for a user of an app implementing DCP. Figure 5 shows a Consumer Present Mode (CPM) bridge transaction from the "Select CPM as payment mode" step to the "Merchant Scan Process" step. The "HIVEX API" logo in this diagram indicates the involvement of a bridge service provider in this step. [Figure 6] This is an example of a wireflow diagram for a user of an app implementing DCP. Figure 6 shows the DCP in the case of a failed transaction. On the left is the second confirmation page in the format of the second service provider (PayPay), and on the right is the first confirmation page in the format of the first service provider (Pi Wallet). [Figure 7]Figure 7 shows an example of a wireflow for a user of an app implementing DCP. Figure 7 shows the Dual Confirmation Page (DCP) for a successful transaction. On the left is the second confirmation page in the format of the second service provider (PayPay), and on the right is the first confirmation page in the format of the first service provider (Pi Wallet). DETAILED DESCRIPTION OF THE INVENTION

[0017] The terms used in the specification presented below are intended to be interpreted in their broadest reasonable manner, even though they are used in conjunction with detailed descriptions of some specific embodiments of the present technology. Some terms may even be emphasized below. However, any terms intended to be interpreted in any restrictive manner are specifically defined in this Detailed Description section.

[0018] The embodiments presented below may be implemented with programmable circuitry that is programmed or configured by software and / or firmware, or solely with special purpose circuitry, or a combination of such forms, where such special purpose circuitry (if any) 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.

[0019] The present application provides a method and system for providing a transaction confirmation page (second confirmation page) of a second service provider to a portable device (e.g., a mobile phone) of a first service provider, where the first service provider is different from the second service provider, and the second confirmation page may be displayed on the screen of the portable device. Herein, the first service provider's confirmation page is referred to as the first confirmation page, and the second service provider's confirmation page is referred to as the second confirmation page. The method enables the generation of a second confirmation page (SCP) in addition to the first confirmation page (FCP), and the two pages are collectively referred to as a "dual confirmation page (DCP)." The method is particularly useful in merchant-presented mode (MPM) bridging QR code transactions when the payee (e.g., merchant) does not have a point-of-sale system to immediately confirm the transaction outcome (and thus can only rely on the confirmation page presented by the payer on the payer's portable device).

[0020] See Figure 1. In a QR code bridge transaction, the consumer typically acts as the payer 11 and the merchant typically acts as the payee 15. Assume here that the payer 11 is a user of a first service provider 12 and the payee 15 is a user of a second service provider 14.

[0021] In Merchant Present Mode (MPM) bridging QR code transactions, the payee 15 (merchant) first presents a received QR code to the second service provider 14. The payer 11 (e.g., a consumer) scans the QR code with a portable device 110 and transmits the QR code content to the first management system 120 of the first service provider 12. The first management system 120 then relays the QR code content to the bridge system 130 of the bridge service provider 13. The bridge system 130 then transmits the QR code content along with the payer's 11 identification information to the second management system 140 of the second service provider 14. Upon receiving the request from the payer 11, the second management system 140 transmits the payee's identification information back to the payer's 11 portable device 110 via the bridge system 130 and the first management system 120. The payer 11 may then enter the transfer amount and confirm and effect the payment by sending a confirmation back to the first management system 120, the bridge system 130, and the second management system 140. Alternatively, some QR code presented by the payee 15 may include the payment currency and amount. In this case, the payer 11 need only confirm the payment and does not need to enter the transfer amount in the confirmation return.

[0022] In a consumer-presented mode (CPM) bridging QR code transaction, the payer 11 (consumer) must 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 relays the request to the bridge system 130 of the bridge service provider 13. The bridge system 130 then transmits the bridging payment QR code back to the portable device 110 via the first management system 120. Details of the request and return of bridging QR codes used in bridge transactions are described in PCT International Patent Publication No. WO 2023 / 132995, the entire contents of which are incorporated herein by reference. The payer 11 presents the bridging payment QR code on the portable device 110, and the payee 15 scans this QR code with the merchant device. The merchant device then transmits the QR code content to the second management system 140 of the second service provider 14, which relays the QR code content to the bridge system 130 of the bridge service provider 13. Depending on the system configuration, the bridge system 130 may proceed directly with the bridge transaction or first require confirmation by the payer 11. The bridge system 130 then executes the transaction and pushes a notification to both the payer 11 (via the first management system 120) and the payee 15 (via the second management system 140) informing them of the transaction outcome.

[0023] In this network, a bridge service provider 13 acts as a "bridge" linking the payment systems of a first service provider 12 and a second service provider 14. More generally, in a bridge network that includes multiple service providers, a bridge service provider 13 acts as a "bridge" linking any of the two service providers that conduct bridge transactions.

[0024] In one embodiment, after the portable device 110 (e.g., the payer's 11 mobile phone) receives a notification confirming the success of the bridge transaction, it requests the bridge transaction information and image / text data from the second service provider 14. As noted above, the second service provider 14 is the service provider used by the payee 15 to accept payments, and the second service provider 14 is different from the first service provider 12, which the payer 11 uses to send payments. A program installed on the portable device 110 may request bridge transaction information (such as the recipient's name, time, transaction number, currency, and amount) and image / text data (such as the image and text to be shown on the confirmation page) of the second service provider 14 from the bridge network, combine them, and generate a second confirmation page for the transaction in the format of the second service provider 14. For example, the program in the portable device 110 may 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.

[0025] In another embodiment, a program installed on the portable device 110 (e.g., the payer's 11 mobile phone) gains access to bridge transaction information during the bridge transaction process. For example, in an MPM, upon QR code scanning, the payer's 11 portable device 110 initiates the payment transaction and relays the request via the portable device 110-first management system 120-bridge system 130-second management system 140 path. The second management system 140 then sends the name of the payee 15 back to the payer 11 via the reverse path, i.e., second management system 140-bridge system 130-first management system 120-portable device 110. Depending on the QR code content, the second management system 140 may also send the transaction amount / currency for the payer 11 to confirm, or the second management system 140 may send the payee information without specifying the transaction amount, leaving it blank for the payer 11 to fill in. In either case, the portable device 110 of the payer 11 may collect information such as the identity of the second service provider 14, the name of the payee 15, and the amount / currency to be transferred in this bridge transaction. Similarly, in CPM, the portable device 110 may collect transaction information during the scanning and verification steps. The image / text data of the second service provider 14 may be requested from a network (e.g., a content delivery network) or may be pre-stored in an app for generating the second confirmation page. A program in the portable device 110 may then combine the transaction information and the image / text data and generate the second confirmation page in the format of the second service provider 14.

[0026] In a preferred embodiment, the program in the portable device 110 may request the transaction information and image / text data separately and then directly request the raw content of the second confirmation page rather than combining them together. The raw content of the second confirmation page may be provided by a bridge service provider 13 that acts as a "bridge" linking the payer at the first service provider 12 and the payee at the second service provider 14. The bridge system 130 of the bridge service provider 13 may record bridge transaction information in its database and store image and text data of all participating service providers. Then, upon request, the bridge system 130 of the bridge service provider 13 may provide transaction information (e.g., the recipient's name, transaction amount / currency) and the image / text data of the second service provider's confirmation page. The above information / data may be provided together in the form of a raw confirmation page (second confirmation page) in the format of the second service provider 14. In one example, the information about the second confirmation page may be provided in the form of a markup language, such as an HTML file. The HTML file may include a text message for the confirmation page and links for the image content. The portable device 110 may then generate the raw confirmation page based on the HTML file and display the second confirmation page on the portable device screen. Alternatively, the raw content of the second confirmation page may be provided entirely as an image, such as a JPG file.

[0027] With respect to a system for implementing DCP generation, in one embodiment the system comprises a first management system 120 of a first service provider 12, a bridge system 130 of a bridge service provider 13, and a portable device 110 of a payer 11. Additionally, a second management system 140 of a second service provider 14 is typically also included. In this system, the first management system 120 is communicatively coupled to both the portable device 110 and the bridge system 130. The second management system 140 is also communicatively coupled to the bridge system 130. The system configuration of the present invention is shown in Figures 1 and 2. This configuration enables a bridge transaction between a payer 11 of a first service provider and a payee 15 of a second service provider. Furthermore, once the required information is provided, this configuration also enables the generation of a DCP after the bridge transaction. For details on bridge transactions, PCT International Patent Publication Nos. WO2021 / 211773 and WO2023 / 132995 are incorporated herein by reference in their entirety. Briefly, the bridge service provider 130 acts as a "bridge" between the payer 11 of the first service provider 12 and the payee 15 of the second service provider 14, facilitating the transaction between them. As described in steps S111, S112 and S113 of FIG. 2, after the bridge transaction is processed and confirmed, the bridge system 130 of the bridge service provider 13 (e.g., HIVEX shown in FIG. 2) pushes a notification to the portable device 11 of the payer 11 via the first management system 120 of the first service provider 12.

[0028] Regarding DCP generation, as is typically performed for transactions within the network of the first service provider 12, after receiving notification, a confirmation page (first confirmation page) may be generated in the format of the first service provider and displayed on the screen of the portable device 110. The confirmation page typically includes transaction information such as the payee's name, transaction number, transaction time, transaction currency, and transaction amount. This confirmation page generated in the format of the first service provider may be presented by the payer 11 to the payee 15 as confirmation of the payment.

[0029] When the payer 11 generates a confirmation page (second confirmation page) in the format of the second service provider, the payer's portable device 110 requests the necessary information to generate the new confirmation page. The necessary information may include the transaction information and image / text format of the second service provider. In the case of a bridge transaction, the bridge system 130 of the bridge service provider 13 may have a database that records transactions involving various service providers, such as a transaction between the payer 11 of the first service provider 12 and the payee 15 of the second service provider 14 that is bridged by the bridge service provider 13. Typically, the first service provider 12 and / or the second service provider 14 also have their own databases that store data on processed bridge transactions. The transaction information may be extracted from the database of the first service provider 12 or the bridge service provider 13 and transmitted 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 may be obtained from the entire bridge network, including the first service provider 12, the second service provider 14 and / or the bridge service provider 13. In one embodiment, the image and text format of the second service provider 14 is obtained from the bridge system 130 of the bridge service provider 13.

[0030] A computer program (e.g., an app) in the portable device 110 may collect the transaction information and image / text format of the second service provider 14, aggregate the information, and generate a second confirmation page for the second service provider 14. Alternatively, if the first management system 120 or the bridge system 130 aggregates the content of the second confirmation page together, the portable device need only receive the data without aggregation.

[0031] Secondary Confirmation Page (SCP) Generation Flowchart An example of a system for implementing SCP generation is shown in FIG. 2. The system 100 includes a first management system 120 of a first service provider, a bridge system 130 of a bridge service provider, and a payer portable device 110. The first management system 120 of the first service provider (or "Issuer") is communicatively connected to the bridge system 130 of the bridge service provider (or "HIVEX"). The first management system 120 may include an app server 121, a push server 122, and an elastic load balancer (ELB) 123 that implements SCP generation-related functions. The app server 121 may be a virtual machine (VM) on a cloud (e.g., Amazon® Web Services (AWS)) configured to implement bridge transaction-related tasks for the first management system 120, such as system interfacing to the bridge system 130. The functionality of the app server 121 may include, but is not limited to, processing received requests / notifications and / or forwarding requests / notifications to the correct destination. For example, the app server 121 may forward a transaction notification from the bridge system 130 to the correct payer's portable device 110 based on a user identifier, or may forward an SCP request from the portable device 110 to the bridge system 130. The push server 122 may be a logically isolated virtual network on the cloud (e.g., Amazon Virtual Private Cloud) configured to relay transaction messages and notifications from the app server 121 to the payer's 11 portable device 110. The elastic load balancer 123 may be an online service that distributes network traffic to improve application scalability, such as a service provided by AWS, configured to receive requests from the portable device 110 to the app server 121. The bridge service provider's bridge system 130 may include a view maker 131, a transaction database 132 (or "job model"), and an image database 133 (which may be a content delivery network (CDN)). In one embodiment, the view maker may receive SCP requests from the app server 121 and provide instructions to render the SCP according to the request. The transaction database 132 (job model) is configured to record various service provider transactions (e.g., transactions between a payer at a first service provider and a payee at a second service provider) that are bridged by a bridge service provider. In this example, the image database 133 is a geographically distributed proxy server network, and the proxy server data centers on the cloud are configured to provide high availability and performance by spatially distributing services to end users, such as a CDN provided by AWS. The image database can be used to store image resources required for generating confirmation pages. If multiple service providers are in the bridge network, the image database can store image resources from multiple service providers. The first management system 120 can operate two compartments within its system. The first compartment is an off-cloud server that performs traditional service provider functions, such as connecting to members and executing transactions within the first service provider 120. The second compartment, including the app server 121, push server 122, and ELB 123, is an on-cloud server configured to connect to the bridge network via the bridge system 130. In this example, the app server 121, push server 122, and ELB 123 are virtual machines (VMs) on the cloud. A user app on the portable device 110 may establish a connection to the push server 122 through the first management system 120. In this example, the push server 122 and the ELB 123 act as intermediate servers between the user app 110 and the app server 121 VM. In this way, the app server 121 is more secure because this configuration avoids the app server 121 being flooded with data traffic or attacked by malicious users.

[0032] As illustrated in steps S111, S112, and S113 of FIG. 2, after a bridge transaction, the bridge system 130 of the bridge service provider (HIVEX) may push a notification to the first service provider's user (i.e., payer) 110 via the first service provider's first management system 120. In step S111, the first service provider's first management system (issuer) 120 receives confirmation from the bridge system (HIVEX) 130 within its app server 121. Then, as shown in S112 and S113, the first management system 120 relays this confirmation to the payer's portable device 110 via the push server 122 and an off-cloud server (not shown). Conventional service provider functionality may generate a first confirmation page. If the payer provides a confirmation page in a format of another service provider (e.g., provides a second confirmation page in a format of a second service provider), the app installed in the payer's portable device 110 requests such confirmation page including transaction details and image format. As shown in FIG. 2, the request, along with the user identifier, is sent to the off-cloud server of the first management system 120, then to the elastic load balancer (ELB) 123 that links with the first service provider's app server 121 (step S121), and then to the app server 121 (step S122). The first service provider's app server 121 then relays the request to the view maker 131 of the bridge system 130 (e.g., HIVEX in FIG. 2) (step S123). Upon request, the view maker 131 in the bridge system 130 sends the user identifier provided by the payer's 110's portable device to the transaction database 132 and extracts the value recorded in the transaction database 132 (job model) (steps S124 and S125). The view maker 131 then returns the content of the second confirmation page to the user app 110 in the format of the second service provider 14 based on the user identifier. In this example, the content of the second confirmation page is generated by the view maker 131 as an HTML file. Based on the user identifier, the bridge system 130 and the first management system 120 can identify the user app 110 logged in with the payer's account. The bridge system 130 (HIVEX) then returns the content of the confirmation page to the user app 110 via the first management system 120 of the first service provider through the reverse path (steps S126, S127, and S128). The user app 110 then obtains image data for the second confirmation page as an HTML file from the image database 124 and generates a confirmation page for the second service provider based on the content of the second confirmation page (step S129). Depending on the configuration and security needs, the image data can be retrieved directly from the Internet (if the image database is directly accessible from the Internet) or can be sent from the bridge system 130 via the first management system 120 to the portable device 110 via secure transmission. The generated second confirmation page may be shown to the merchant on the portable device 110 for the merchant to confirm.

[0033] Double confirmation page and bridge network scalability In the above example, the bridge system 130 provides the raw content of the second confirmation page of the second service provider. The user app 110 passively receives the content and simply extracts image resources from the image database to generate the confirmation page as an HTML file. Therefore, the first service provider does not need to implement any additional system for DCP generation, except for the system for establishing a connection with the bridge system.

[0034] Imagine a bridge network with many (say, 100) participating service providers. If each of the 100 service providers were configured to generate its own DCP, the network would need to store 9,900 copies of the image data for the various service providers' confirmation pages. Furthermore, if any one of the participating service providers changed its image format, all the 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. It would also be difficult for the bridge service provider to guarantee the accuracy of the image resources stored in the participating service providers' servers.

[0035] This invention provides an example in which the content of the SCP (including image resources and transaction details) is provided by the bridge system of the bridge service provider. In this way, it is more convenient for participating service providers to implement such a system and realize this functionality. The content of the generated DCP can also be controlled by the bridge system (which means that participating service providers cannot generate SCPs for any other service provider). All service providers do not need to store the format content and image resources related to SCP generation. Even if the bridge network grows (as more service providers join the bridge network), participating service providers do not need to change their systems at all.

[0036] DCP functionality on portable devices Figures 3-7 show an example of how DCP technology works on a portable device. In this example, a user is traveling to Japan and wishes to pay via mobile payment at a Japanese store. Bridge technology must be employed to enable the transaction between the two mobile payment systems. In this example, Pi Wallet is utilized to make the payment (i.e., Pi Wallet acts as the first service provider), and PayPay is selected as the recipient of the payment (i.e., PayPay acts as the second service provider). After selecting PayPay as the second service provider, as shown in Figure 3, the app further prompts the user to select a payment mode: Consumer Presented Mode (CPM) or Merchant Presented Mode (MPM). In Merchant Presented Mode (MPM), as shown in Figure 4, after the user (payer) enters and confirms the payment amount, the app directs the user to a transaction result page. On the other hand, in Consumer Presented Mode (CPM), as shown in Figure 5, after the merchant scans the bridging QR code, the app also directs the user to a transaction result page. The app displays a dual confirmation page (DCP) regardless of whether the transaction is successful. Figure 6 shows the DCP for a failed transaction, and Figure 7 shows the DCP for a successful transaction. The DCP consists of two parts: one is a first confirmation page in the format of the first service provider (Pi Wallet) and the other is a second confirmation page in the format of the second service provider (PayPay).

[0037] When the merchant is a retail store, the QR code presented by the merchant is usually a fixed QR code, and there is usually no POS system to receive the transaction results immediately. With DCP technology, the merchant can confirm the transaction status from the consumer even if the merchant does not understand the language (in this case, Chinese) displayed on the first service provider's confirmation page. DCP technology facilitates cross-border electronic payments by making transaction confirmation much easier.

[0038] The above description of the embodiments is provided to enable one skilled in the art to make and use the subject matter. Various modifications to these embodiments will be apparent to those skilled in the art. The novel principles and subject matter disclosed herein may be applied to other embodiments without the use of innovative skills. The subject matter set forth in the claims and claimed herein 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. Accordingly, it is intended that the present invention include modifications and variations that come within the scope of the appended claims and their equivalents.

Claims

1. 1. A method for bridging a transaction between a first service provider payer and a second service provider payee by generating a second service provider second confirmation page (SCP) that is different from a first service provider first confirmation page (FCP), the method comprising: The method comprises: receiving, by a bridge system of a bridge service provider, a second confirmation page (SCP) request from a first management system of the first service provider, the second confirmation page (SCP) request including a transaction identifier; searching, by the bridge system, a transaction database for transaction information corresponding to the transaction identifier; generating, by the bridge system, an SCP content file containing page layout information for SCP generation; providing, by the bridge system, the SCP content file to the first management system; the first service provider is different from the bridge service provider and the second service provider; method.

2. The generation of the SCP content file includes: identifying, by the bridge service provider, the second service provider from a plurality of acquirers based on the transaction information; generating, by the bridge service provider, the SCP content file of the second service provider; 2. The method of claim 1, comprising:

3. 3. The method of claim 2, wherein the SCP content file includes text content and image-referenced content.

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

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

6. 5. The method of claim 4, wherein the SCP image content is provided from an image database that stores image content for the plurality of acquirers.

7. 2. The method of claim 1, wherein the SCP content file comprises an HTML file that generates the SCP.

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

9. 10. The method of claim 1, wherein the transaction identifier is an identifier recognizable to the bridge system, the bridge system uniquely identifying the transaction between the payer and the payee.

10. 2. The method of claim 1, wherein the transaction information corresponding to the transaction identifier includes the recipient's name, a transaction number, a transaction time, a transaction currency, and a transaction amount.

11. 2. 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 dual confirmation page (DCP).

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

13. 1. A system for bridging a transaction between a first service provider and the second service provider, the second service provider being one of a plurality of acquirers, by generating a second confirmation page (SCP) of the first service provider that is different from a first confirmation page (FCP) of the first service provider, the second confirmation page (SCP) comprising: The system comprises: a transaction database configured to store information bridging transactions between the first service provider and the plurality of acquirers; an image database configured to store image content for confirmation pages of the plurality of acquirers; a view maker configured to be communicatively connected to the transaction database and to be communicatively connected to a first management system of the first service provider; The view maker includes instructions stored on the view maker, and in response to execution of the instructions: receiving a second confirmation page (SCP) request from a first management system of the first service provider, the second confirmation page (SCP) request including a transaction identifier; searching the transaction database for transaction information corresponding to the transaction identifier; generating an SCP content file based on the transaction information, the SCP content file including page layout information for generating an SCP; providing the SCP content file to the first management system; the first service provider is different from the second service provider; system.

14. 14. The system of claim 13, wherein the SCP content file includes text content and image-referenced content.

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

16. The image database includes: receiving an image request for SCP image content from the first management system based on the SCP content file; Providing the SCP image content to the first management system 14. The system of claim 13, configured to:

17. 14. The system of claim 13, wherein the SCP content files include HTML files that generate the SCP.

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

19. 14. The system of claim 13, wherein the transaction identifier is an identifier recognizable to the view maker, the view maker uniquely identifying a transaction between a payer of the first service provider and a payee of the second service provider.

20. 14. The system of claim 13, wherein the transaction information corresponding to the transaction identifier includes the recipient's name, transaction number, transaction time, transaction currency, and transaction amount.

21. 14. 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 dual confirmation page (DCP).

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

Images