Methods for performing bridged transactions between scannable target-based service provider and radio frequency target-based service provider

Abstract

The present disclosure relates to target bridging methods for method a bridged transaction between a payer as a user of a first service provider providing payment transfer service based on scannable targets and a receiver as a user of a second service provider providing payment transfer service based on radio frequency targets. The disclosed methods enable a portable device of the payer to present a bridging target recognizable to a merchant device of the receiver, which originally does not recognize a target of the first service provider.

Description

METHODS FOR PERFORMING BRIDGED TRANSACTIONS BETWEEN SCANNABLE TARGET-BASED SERVICE PROVIDER AND RADIO FREQUENCY TARGET-BASEDSERVICE PROVIDERCROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims the priority benefit of U.S. provisional applications serial No. 63 / 673,777 filed on July 21, 2024, serial No. 63 / 696,853 filed on September 19, 2024, serial No. 63 / 726,218 filed on November 27, 2024, and serial No. 63 / 785,076 filed on April 08, 2025. The entirety of the above-mentioned patent applications is hereby incorporated by reference herein and made a part of this specification.BACKGROUNDField of the Invention

[0002] The present disclosure relates to methods and a network system for bridging different payment service providers to execute cross-service provider transactions. In particular, some embodiments of the present disclosure relate to methods and a network system for bridging different service providers to execute cross -provider transactions between a first service provider based on scannable targets and a second service provider based on radio frequency targets.Description of Related Art

[0003] Traditionally, the radio frequency target communicated from a portable device of a payer to a radio frequency device (system) of a receiver for a transaction is associated with the payer’s account with an issuer, including primary account number (PAN), for example account information of a credit card, a debit card, or a bank account, and device account number (DAN) which is associated with PAN and the portable device of the payer that is used for contactless payment. Alternatively, a token generated based on the PAN or DAN is provided by the portable device of the payer to the radio frequency device (system), such as POS (point of sale) device, of a receiver, rather than the PAN or DAN itself in the radio frequency target. One example of the radio frequency target is an NFC (near field communication) tag, a short-range wireless communication technology that enables devices to exchange data when they are usually within a few centimeters to each other. Mobile payment systems leverage this technology to facilitate secure transactions. However, the traditional contactless transactions via radio frequency signals are not sufficiently secured because either the token or the radio frequency target used is associatedwith the payer or the portable device. Also, it is quite common that a POS terminal does not support QR code scanning and thus cannot accept QR code payments.

[0004] The most common merchant device with NFC sensing ability is traditional point-of-sale (POS) terminal accepting credit cards and digital wallets complying with EMV standards. A POS terminal of a receiver can process a transaction request via several different routes, as summarized in FIG. 1 and the following paragraphs.

[0005] The first route is traditional card payment. A POS system can accept credit card payments from cards or digital wallets complying with EMV standard (including mobile wallet such as Apple Pay or Google Pay) via card insertion or NFC sensing. The POS terminal then may decode (e.g., ISO-8583) the card information for further processing.

[0006] The second route is non-EMV NFC transactions. When a POS terminal receives a non- EMV NFC token, it will determine whether it recognize the type or format of the token. Many contactless smartcards having their own formats can be used to make payments. They are usually sensed by a POS via NFC. The smartcard information and the following transactions may be processed if the POS terminal recognize the type or format of the smartcard.

[0007] Other payment instruments may also be acceptable to a POS terminal, such as reading the magnetic stripe on a card. And recently, some POS systems can also scan QR code, and thus can receive QR code payments. Similar to the case of smartcard, the issuer information and following transactions may be processed if the POS terminal recognize the format of the QR code.SUMMARY

[0008] The present disclosure relates to systems and methods to enhance the security of contactless transactions, a one-time-use target which is generated not based on a payer or a portable device of the payer is provided between two different service providers respectively based on different contactless payment methods to complete highly secured transactions. The two different contactless payment methods may be respectively based on scannable targets, such as one dimensional barcode or two-dimensional QR (quick response) codes, and radio frequency targets, such as NFC (near field communication) tags. This invention provides a method for target bridging between a portable device of a payer of an issuer based on scannable targets and a radio frequency device (system), such as a POS (point of sale) device, of a receiver of an acquirer based on radio frequency targets.

[0009] Target bridging may be done if a first service provider based on scannable target and a second service provider based on radio frequency target have a bilateral agreement with each otherand modify their system accordingly. For example, an issuer based on scannable target may generate a radio frequency target acceptable to an acquirer based on radio frequency target according to their agreement, or an issuer based on radio frequency target may generate scannable target acceptable to an acquirer based on scannable target. However, since modifying their system is required when every time a first service provider is partnered with a second service provider, if the first service provider decides to implement this method with N second service providers, the first service provider will need to modify its system for N times. Similarly, a second service provider will need to modify its system M times if it would like to partner with M first service providers. Because there are so many payment service providers in the world, this becomes a multiplication problem. To simplify this problem, a bridging service provider with a bridging system may be introduced to act as middleman between a first service provider and a second service provider. Every service provider only needs to sign a bilateral agreement with the bridging service provider and modify its system once before it can communicate with other service providers. Multiple service providers linked together by a bridging service provider form a bridging network.

[0010] In an aspect of the present disclosure, a method for performing a bridged transaction between a payer of a first service provider and a receiver of a second service provider is provided from the perspective of a bridging service provider, wherein the first service provider provides payment transfer service based on scannable targets and the second service provider provides payment transfer service based on radio frequency targets. The method comprises steps of (1) storing, by a bridging system of the bridging service provider, a transaction identifier and a target identifier, wherein the transaction identifier is assigned in association with a payer identifier of the payer in the bridged transaction, and the target identifier is mapped to the transaction identifier; (2) receiving, by the bridging system, a transaction request, after a radio frequency bridging target generated based on the target identifier is presented to a merchant device of the receiver, wherein at least one of the transaction identifier and the target identifier is provided in the transaction request; and (3) identifying, by the bridging system, the first service provider based on the transaction identifier or the target identifier for transaction execution. The transaction request may be initiated based on a target content encoded in the radio frequency bridging target, and the transaction request is routed to the first management system via the bridging system based on the transaction identifier stored in the bridging system. The target identifier may be generated with a routing identifier, where the routing identifier encoded in the radio frequency bridging target enables a second management system of the second service provider to relay the transaction request correctly.

[0011] In one embodiment, the method comprises the following steps: (1) receiving, by a bridging system of a bridging service provider, a target request with a payer identifier for radio frequency target; (2) generating, by the bridging system, a transaction identifier mapped with the payer identifier; (3) obtaining, by the bridging system, target content of a radio frequency bridging target mapped with the transaction identifier; (4) providing, by the bridging system, the target content to a first management system of the first service provider; (5) receiving, by the bridging system, a target information corresponding to the radio frequency bridging target and a transaction information from a second management system of the second service provider; (6) authorizing and processing, by the bridging system, the bridged transaction based on the target information and the payment information; and (7) providing, by the bridging system, a transaction result of the bridged transaction to the first management system and the second management system. In this embodiment, the first service provider is different from the second service provider, and the radio frequency target becomes invalid after the bridging system receives it from the second management system for transaction authorization.

[0012] In an aspect of the present disclosure, a method for performing a bridged transaction between a payer of a first service provider and a receiver of a second service provider is provided from the perspective of the first service provider. The method comprises steps of (1) creating or receiving, by a first management system of the first service provider, a target identifier for the bridged transaction; and (2) providing, by the first management system, the target identifier to a portable device of the payer. In this method, the target identifier is mapped to a transaction identifier assigned in association with a payer identifier of the payer, and the target identifier is used as an identification of a radio frequency bridging target, which is readable to a merchant device of the receiver. The target identifier may be used to generate a transaction request. Either the target identifier or the radio frequency bridging target is not generated based on the payer identifier.

[0013] In one embodiment, the method comprises the following steps: (1) wirelessly receiving, by a first management system of the first service provider, a target request from the portable device of the payer; (2) providing, by the first management system, the target request to a bridging system of a bridging service provider; (3) receiving, by the first management system, target content of a radio-frequency bridging target from the bridging system; and (4) wirelessly providing, by the first management system, the target content to the portable device of the payer which further communicates the radio-frequency bridging target or its tokenized object to a merchant device of the receiver via radio frequency signals. In this embodiment, the merchant device of the receiverrecognizes at least one of the radio-frequency bridging target or its tokenized object but does not recognize scannable targets of the first service provider.

[0014] In an aspect of the present disclosure, a method for performing a bridged transaction between a payer of a first service provider and a receiver of a second service provider is provided from the perspective of the second service provider. The method comprises steps of (1) receiving, by a second management system of the second service provider, a transaction request from a merchant device of the receiver after a radio frequency bridging target is sensed by the merchant device, wherein the radio frequency bridging target is generated based on a target identifier mapped to a transaction identifier assigned in association with a payer identifier, and at least part of the target identifier is not generated based on the payer identifier; and (2) sending, by the second management system, a transaction notice to the merchant device after the bridged transaction corresponding to the transaction request is recorded.

[0015] In one embodiment, the method comprises the following steps: (1) receiving, by a second management system of a second service provider, a target information corresponding to a radio frequency bridging target and a transaction information from a merchant device of the receiver; (2) providing, by the second management system, a target information and the transaction information to a bridging system of a bridging service provider; (3) receiving, by the second management system, a transaction result of the bridged transaction from the bridging system. In this embodiment, the first service provider is different from the second service provider, the target information is parsed from the radio frequency bridging target, and the radio frequency bridging target and the target information become invalid after the second management system receives it from the merchant device for transaction authorization.

[0016] In an aspect of the present disclosure, a method for performing a bridged transaction between a payer of a first service provider and a receiver of a second service provider is provided from the perspective of a second service provider different from the first service provider, the second service provider and the bridging service provider. The method comprises steps of (1) receiving, by a third management system of a third service provider, a target request with a transaction identifier from a bridging system of a bridging service provider; (2) providing, by the third management system, target content of a radio frequency bridging target mapped with the transaction identifier to the bridging system; (3) receiving, by the third management system, a payment request from a second management system of the second service provider; (4) authorizing and processing, by the third management system, the bridged transaction based on the payment request; and (5) providing, by the third management system, a transaction result of the bridged transaction to the bridging system and the second management system.

[0017] In an aspect of the present disclosure, a method for registering a first service app of a first service provider under a digital wallet app of a wallet service provider based on radio frequency targets in a portable device of a payer of the first service provider based on scannable targets is provided. The method comprises steps of (1) receiving, by the digital wallet app in the portable device, a registration request of the first service app listed on an issuer table; (2) verifying, by the digital wallet app, that the qualifying first service app is installed in the portable device of the payer; and (3) generating, by the digital wallet app, an issuer icon in the digital wallet app, which, after selected by the payer, activates the first service app to request target content of a radio frequency bridging target.

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

[0019] FIG. 1 illustrates several different routes a POS terminal of a receiver may process to request a transaction.

[0020] FIG. 2 shows the first case of contactless transaction flow via radio frequency payment, wherein a digital wallet app of a wallet service provider is involved to convert target content into a radio-frequency target. “1stSP” is the abbreviation for first service provider; “2ndSP” is the abbreviation for second service provider; and “Bridging SP” is the abbreviation for bridging service provider.

[0021] FIG. 3 shows the second case of contactless transaction flow via radio frequency payment, wherein a third service provider different from the first service provider and the second service provider is involved to provide target content of a bridging target. “1stSP” is the abbreviation for first service provider; “2ndSP” is the abbreviation for second service provider; “3rdSP” is the abbreviation for third service provider; and “Bridging SP” is the abbreviation for bridging service provider.

[0022] FIG. 4 shows the third case of contactless transaction flow via radio frequency payment, wherein the second service provider is also the party which provides target content of a bridging target. “1stSP” is the abbreviation for first service provider; “2ndSP” is the abbreviation for second service provider; and “Bridging SP” is the abbreviation for bridging service provider.

[0023] FIG. 5 shows the fourth case of contactless transaction flow via radio frequency wave payment, wherein the second service provider is the only acquirer which can recognize thebridging target. “1stSP” is the abbreviation for first service provider; “2ndSP” is the abbreviation for second service provider; and “Bridging SP” is the abbreviation for bridging service provider.

[0024] FIG. 6 shows the fifth case of contactless transaction flow via radio frequency payment, wherein the second service provider modifies its system to recognize a target of the bridging service provider. “1stSP” is the abbreviation for first service provider; “2ndSP” is the abbreviation for second service provider; and “Bridging SP” is the abbreviation for bridging service provider.

[0025] FIG. 7A is an example of adding a card or new payment method in a digital wallet app. FIG. 7B is an image of a digital wallet app added with a “card” of a mobile payment service.

[0026] FIG. 8 shows the detailed process of a bridged transaction of Case 1 with blank credential registration (BCR) to a digital wallet. “Bridging SP” is the abbreviation for bridging service provider.DETAILED DESCRIPTION OF EMBODIMENTS

[0027] The terminology used in the description presented below is intended to be interpreted in its broadest reasonable manner, even though it is used in conjunction with a detailed description of certain specific embodiments of the technology. Certain terms may even be emphasized below; however, any terminology intended to be interpreted in any restricted manner will be specifically defined as such in this Detailed Description section.

[0028] As used in the specification and claims, the term “service provider” refers to a party providing payment transfer service via sending and / or receiving target information or a target. In one embodiment of this disclosure, a service provider is an electronic payment or transfer system provider which enables electronic payments or transfers of digital property between its payers and receivers utilizing a target to exchange information, such as a payer identifier, a receiver identifier, a time stamp and a request for transaction. A service provider usually contains management system(s) to execute its functionalities related to digital property transactions.

[0029] The term “payer” used herein refers to a party, an individual or an entity, who authorizes a transaction to transfer his / her digital properties to others. A payer of a service provider is also a user of the service provider who holds an account of the service provider. The user is able to transfer digital properties stored in the account to others and receive digital properties from others. In one embodiment, the account is implemented by a digital wallet. The payer may present a target via his / her mobile device to a receiver.

[0030] The term “receiver” refers to a party, an individual or an entity, who receives digital properties transferred from others. A receiver of a service provider may be either a user or amerchant of the service provider. A merchant of a service provider is able to recognize a target of the service provider. However, a merchant of a service provider who may not hold an account of the service provider and, thus may not be a user of the service provider. In other words, the merchant of the service provider may carry out the merchant function through a merchant acquirer, and do not have direct relationship with the service provider.

[0031] The term “digital property” used herein refers to anything that exists in digital form and has economic value, including but not limited to multiple types of digital assets, credits, and obligations, such as digital currencies, digital securities, digital bonds, digital futures, digital precious metals, non-fungible tokens (NFTs), digital coupons, and digital fee tokens. Digital currencies may include but may not be limited to digital US Dollars, digital Japanese Yens, digital Euros, and digital New Taiwan Dollars. Digital securities may include but may not be limited to digital Apple stocks, digital Google stocks, and digital mutual funds. Digital precious metals may include but not limited to digital gold, digital platinum, and digital silver. Digital futures may include but may not be limited to digital futures of coffee beans, soy beans, and coms. An NFT may be an electronic record a party owned / controlled in which the party has a right or interest, which includes but may not be limited to photography, logos, illustrations, animations, audiovisual media, presentations, spreadsheets, digital paintings, word documents, electronic mails, websites, and a multitude of other digital formats and their respective metadata.

[0032] The term “target” used herein refers to a medium containing information in a format which can be recognized or sensed by specific devices. Examples include but may not be limited to barcode, QR code, NFC (Near-field Communication) tag, voice signature, and fingerprint. The target information may be resolved by extracting features embedded in the target, for example, by scanning QR code, sensing NFC tag, extracting voice signature from voice, or scanning fingerprint to extract the features and obtain the target information contained therein. In an embodiment of the present invention, the target is an NFC tag.

[0033] The term “target content” used herein refers to the information encoded in the target, which includes but may not be limited to locators, identifiers, and trackers. The target content may be in a format of a string. In one embodiment of the present invention, a target content contains a payer identifier, a receiver identifier, and / or a request for transaction, which provides the information of a payer and / or a receiver. A target may be generated based on the target content.

[0034] The term “portable device” used herein refers to a device with basic computing resources (in the form of a processor, memory, and storage) and wireless communication, such as telecommunication network, WiFi, Bluetooth, satellite, radio broadcast, microwave, infrared, etc. Examples include but may not be limited to laptops, tablets and smartphones.

[0035] The term “bridge” or “bridging” used herein refer to the system or the method that enables a payer of a first service provider to present a target recognizable for a second service provider to a receiver of the second service provider, who does not recognize a target of the first service provider, so that a transaction between the payer and the receiver can be completed. Since the first service provider and the second service provider use different target formats or rules, the receiver of the second service provider does not recognize a target of the first service provider. In some embodiments, in a consumer presented mode (CPM), the bridging service enables a consumer’ s mobile device to present a QR code recognizable by the merchant device (e.g. POS) which cannot recognize a QR code of the consumer’ s service provider.

[0036] The term “bridging service provider” refers to a service provider that provides bridging technology to other service providers. A bridging service provider may be the first service provider, the second service provider, or a separate bridging service provider which is neither the first service provider nor the second service provider. And the term “bridging system” refers to the system(s) of the bridging service provider to execute functionalities of bridging service.

[0037] The embodiments introduced below can be implemented by programmable circuitry programmed or configured by software and / or firmware, or entirely by special-purpose circuitry, or in a combination of such forms. Such special-purpose circuitry (if any) can be in the form of, for example, one or more application specific integrated circuits (ASICs), programmable logic devices (PLDs), field- programmable gate arrays (FPGAs), etc.

[0038] The present disclosure provides methods and a network system for bridging different payment service providers to execute cross-service provider transactions, especially between a first service provider based on scannable targets and a second service provider based on radio frequency targets. Specifically, the present disclosure introduces a transaction identifier to bridge two parties in the bridged transaction, which enables a target identifier such as NFC target content to be issued by either the bridging service provider, the first service provider, the second service provider, or even a third service provider. A target identifier may be part of target content, or an entire target content, which uniquely identifies a bridging target within a specific time period.

[0039] In this kind of cross-service provider transactions, a first service provider such as PayPay and JKOPay may be the issuer which provides contactless payment service based on scannable targets, such as QR codes, for payers; and a second service provider may be an acquirer based on radio frequency targets, which allows receivers to accept payments from issuers via radio frequency targets such as NFC tags. Because the target format of the first service provider and that of the second service provider are different, the first service provider needs to obtain a target recognizable to the merchant device of the second service provider for the portable device to usefirst. The above mentioned target for the portable device’s use is called a bridging target. In such scenarios, a bridging service provider, such as HIVEX, facilitates contactless high secured transactions between the issuer and the acquirer.

[0040] There are several ways to achieve target bridging between a first service provider based on scannable targets and a second service provider based on radio frequency targets. For example, the second service provider may generate and send target content of a bridging target to the issuer via the bridging service provider. Alternatively, the second service provider may authorize the bridging service provider to generate a target recognizable to the merchant device and the second service provider. Also, the second service provider may modify its system so that it can recognize a bridging target issued by the bridging service provider. After obtaining the bridging target, the portable device of the payer then may use it to initiate a transaction with the merchant device of the receiver. Upon receiving the bridging target, the second service provider can identify it as a request for a bridged transaction and will relay the request to the bridging service provider to resolve the issuer (i.e., the first service provider) and / or the payer.

[0041] The bridging target is presented by the portable device of the payer to the merchant device of the receiver. Therefore, the target content of the bridging target requires to be recognizable to the merchant device and the second management system of the second service provider. Upon receiving the bridging target, the second management system shall route a transaction request to the bridging system of the bridging service provider for a bridged transaction. To correctly route the transaction request, the target content shall contain a routing identifier. For example, in an embodiment where a bridging target complies with EMV standards, the routing identifier may be an Issuer Identification Number, the first six digits of a credit card number, which identifies a card issuer. The routing identifier may be included in a target identifier. And the bridging system should be able to route the transaction request correctly to the first management of the first service provider. Besides those basic requirement, there may be additional features to further improve the bridging network. For example, the bridging target may be designed to be one- time-use only. In one embodiment, the one-time-use radio-frequency target is valid only for a predetermined period. The related systems may record a first time stamp indicating the time the target is generated, and may record a second time stamp indicating the time the target is received by the merchant device of the receiver. If the time difference between the first time stamp and the second time stamp exceeds a predetermined period, the transaction may be considered invalid. In another embodiment, such target may comprise the first time stamp and the period thereafter for the target to remain valid. Regarding transaction recording, the bridging system of the bridging service provider may generate a transaction identifier for the bridged transaction so that the relatedtransaction information may be connected by the transaction identifier. To enhance privacy protection, the bridging system of the bridging service provider may generate a job identifier (job ID) for each transaction identifier for recording the transaction, which may be stored in a distributed ledger, such as a blockchain. In one embodiment, the bridging system of the bridging service provider may record each transaction with a job ID, a payer identifier registered in the bridging system, a receiver identifier registered in the bridging system, an amount and a currency type. In another embodiment, the bridging system of the bridging service provider may generate multiple job IDs for a single transaction identifier, in which case multiple parts of the transaction may be recorded using different job IDs that all correspond to one transaction identifier.

[0042] In some embodiments, there is a wallet service provider of the issuer, such as Apple Pay, Google Pay, and Samsung Pay, which provides contactless payment service based on radio frequency targets, such as NFC tags, to merchants via a digital wallet app. In the first phase, systems and methods are provided for registering a first service app, such as JKOPay and PayPay app, of a first service provider, in a digital wallet app, such as Apple Pay, Google Pay, and Samsung Pay, of a wallet service provider, so that radio-frequency targets, such as NFC tags, may be provided in a portable device of a payer of the first service provider based on scannable targets. The steps include that the digital wallet, such as Apple Pay, receives a registration request of the first service app listed on an issuer table of the digital wallet. The digital wallet (such as Apple Pay) or a wallet management system of the wallet service provider then verifies that the qualifying version of first service app is installed in the portable device of the payer. For example, the qualifying version of the JKOPay or PayPay app is installed in the iPhone of the payer. The digital wallet, such as Apple Pay, may generates an issuer icon, for example in a shape that looks like a card, in the digital wallet. A linkage between the issuer icon and the first service app is established. Thus, once the issuer icon is selected by the payer before a transaction begins, the digital wallet activates the first service app to request a one-time-use radio frequency target. The registration phase is completed when the first service app is added as a “card” in the digital wallet. The first service provider may provide a payer identifier of the payer to be registered in the digital wallet of the wallet service provider, or may leave it blank at this moment and provide a payer identifier later during transaction. In one embodiment, the first service provider, such as JKOPay and PayPay, does not provide a payer identifier to be stored in the portable device of the payer before completion of registering the first service app. In another embodiment, the first service provider does not authenticate the payer before completion of registering the first service app.

[0043] In some other embodiments, the portable device may obtain and present the bridging target without the involvement of a digital wallet (e.g., Apple Pay, Google Pay) of a wallet serviceprovider. This requires that the first service app to have access and control of NFC component on the portable device, thereby enabling the app and the NFC chip on the portable device to act like a contactless card with NFC payment ability.

[0044] In the next phase, systems and methods are provided for target bridging between a portable device of a payer of a first service provider based on scannable targets, and a merchant device (e.g., a radio frequency device) of a receiver of a second service provider based on radio frequency targets to complete contactless transactions. The steps include that a first management system of the first service provider, such as JKOPay and PayPay, wirelessly receives a radiofrequency target request from the portable device of the payer. The first management system of the first service provider then may authenticate either one of or both the payer and the portable device of the payer. After authentication, the first management system provides the target request to a bridging system of the bridging service provider, such as HIVEX, and then receives a target content of a one-time-use radio frequency target, such as an NFC tag, from the bridging system. To distinguish from other users of the first service provider, the first service provider may also provide an identifier such as a payer identifier to the bridging system. And the bridging system may link the payer identifier with another identifier such as a transaction identifier in the bridging system to facilitate subsequent transaction processing.

[0045] For target content generation, either the second management system or the bridging system may generate the target content of the one-time-use radio-frequency target for a highly secured transaction. However, in the case where the second management system generates the target content, the payer or the first management system may need to specify the second service provider if multiple acquirers are available as a candidate of the second service provider. The selected second service provider should be the one which the receiver affiliates with. In both cases, the generated radio-frequency target or its content should be recognizable to the bridging system, or the second management system should transmit some identifier recognizable to the bridging system, so that the bridging system can route the transaction to the correct issuer (first service provider). The first management system then wirelessly provides the target content of the one- time-use radio -frequency target to the portable device of the payer which further communicates the one-time-use radio-frequency target or its tokenized object to a merchant device (a radio frequency device) of the receiver via radio frequency signals. In the embodiments where a digital wallet is involved, the digital wallet, such as Apple Pay, may simply convert the target content into the one-time-use radio-frequency target and provide it to the merchant device of the receiver, or further generate a token based on the target content and provide such a tokenized object to the merchant device of the receiver. The first service provider, such as JKOPay and PayPay, isdifferent from the second service provider, such as an acquiring bank. In addition, the merchant device of the receiver recognizes at least one of the one-time-use radio-frequency target or its tokenized object but does not recognize scannable targets of the first service provider, such as QR codes of JKOPay or PayPay.

[0046] In one embodiment, a request for the radio frequency target is made by a portable device of the payer and relayed to the bridging service provider before the first management system of the first service provider receives the target content of the one-time-use radio-frequency target from the bridging system. The target content is issued and managed by a target generator, which may be a system / module of the second service provider, the bridging service provider, or a party other than the second service provider and the bridging service provider. In one embodiment, at least part of a target content is generated independent of identities of the payer and the portable device. This means that the identity of the payer cannot be deciphered from the target content without knowing the mapping between the target content and the payer identity. For example, the target content may contain a identifier (e.g., a transaction identifier) which is assigned based on the sequential order of a target request / transaction request instead of the payer identifier. Alternatively, the transaction identifier may also be randomly generated or randomly selected from a pool of available candidates. In another embodiment, at least part of a target content is generated based on the identities of first service provider and / or the payer.

[0047] After the merchant device of the receiver receives the one-time-use radio-frequency target or its tokenized object from the portable device of the payer, a second management system (the server of the second service provider) parses the at least one of the one-time-use radiofrequency target or its tokenized object to determine the issuer (the first service provider), such as JKOPay and PayPay, or the bridging service provider, such as HIVEX, based on a routing identifier, and the second management system provides a transaction request to initiate the transaction. In one embodiment, the first management system of the first service provider receives a transaction request from the bridging system or the second management system. Based on the settings, the first management system may further wirelessly provide the transaction request to the portable device of the payer and then wirelessly receive a transaction approval from the portable device of the payer. The first management system may also approve the transaction by its own if authorized beforehand. Then the first management system of the first service provider provides the transaction approval to the bridging system. In another embodiment, the bridging system approves and executes the transaction by its own based on an agreement between the first service provider and the bridging service provider. For example, the bridging system may approve the transaction if authorized beforehand, e.g. the payment is under a predetermined amount. After thebridging system records a transaction associated with the transaction notice, both the first management system and the second management system receive a transaction notice from the bridging system. The bridging system may record each transaction based on a transaction identifier, which is described above. In one embodiment, the bridging system records the transaction in a distributed ledger.

[0048] In some alternative embodiments, the target generator is a third management system of a third service provider other than the second service provider and the bridging service provider. A third service provider such as an issuing bank may provide contactless payment service based on radio frequency targets, such as NFC tags, to the bridging service provider. The steps include that a first management system of the first service provider, such as JKOPay and PayPay, wirelessly receives a radio-frequency target request from the portable device of the payer. The first management system of the first service provider then authenticates either one of or both the payer and the portable device of the payer. After authentication, the first management system provides the target request to the bridging system of the bridging service provider, such as HIVEX. The first management system or the bridging system may identify the location of the portable device of the payer first, and then sends a request for a radio-frequency target to a third management system of the third service provider. The third service provider may be selected based on the location of the portable device. Upon request, the third management system issues a target content of a one-time-use radio frequency target, such as an NFC tag, and provides it to the bridging system. The target content should be recognizable to the bridging system, or the third management system should transmit some identifier recognizable to the bridging system, so that the bridging system can route the transaction to the issuer correctly afterwards. For example, the bridging system may map the payer of the first service provider to the radio-frequency target with a transaction identifier. The bridging system then provides target content of the one-time-use radio frequency target to the first management system. The first management system then wirelessly provides the target content to the portable device of the payer which further communicates the one-time-use radio-frequency target to the merchant device of the receiver via radio frequency signals.

[0049] A request for the radio frequency target may be made by the portable device of the payer and relayed to the bridging service provider before the first management system of the first service provider receives target content of the one-time-use radio-frequency target from the bridging system. In one embodiment, the radio-frequency target is generated by the third management system or a system / module of the third service provider, and is recognizable to the bridging system, so that the bridging system can route the transaction to the correct issuer (first service provider). Otherwise, the third management system may transmit some identifier recognizable to the bridgingsystem (e.g., a transaction identifier assigned by the bridging system) to enable correct transmittal of the target content to the payer. The target content may be randomly generated, and not be associated with the payer and the portable device of the payer. In one embodiment, the third management system or the system / module of the third service provider does not receive information of the payer or the issuer from the bridging system. In another embodiment, the radiofrequency target is generated by the bridging system but may be routed to the third management system by the second management system after the one-time-use radio-frequency target is received by the receiver.

[0050] After the merchant device receives the one-time-use radio-frequency target from the portable device of the payer, the second management system of the second service provider parses the at least part of the one-time-use radio-frequency target to determine the identity of the third service provider, and the second management system provides a transaction request to initiate the transaction. In some cases, the second service provider happens to be the third service provider which issues the target content. If the second service provider is the same as the third service provider, the second management system may route the transaction request directly to the bridging system to approve the transaction. If the second service provider is different from the third service provider, the second management system first routes the transaction request to the third management system of the third service provider, and the third management system then relays the transaction request to the bridging system. In one embodiment, the first management system of the first service provider receives a transaction request from the bridging system or the third management system of the third service provider. Based on the settings, the first management system may further wirelessly provide the transaction request to the portable device of the payer and then wirelessly receive a transaction approval from the portable device of the payer. The first management system may also approve the transaction by its own if authorized beforehand. Then the first management system of the first service provider provides the transaction approval to the bridging system. In another embodiment, the bridging system approves and executes the transaction by its own based on an agreement between the first service provider and the bridging service provider. After the bridging system records a transaction associated with the transaction notice, the first management system and the third management system receive a transaction notice from the bridging system. The bridging system may record each transaction based on a transaction identifier as described above. In one embodiment, the bridging system records the transaction in a distributed ledger. In the case where the third service provider is different from the second service provider, the third management system further transmits a transaction confirmation to the second management system so that the second management system can provide a confirmation to the receiver.

[0051] In one embodiment, the first service provider also acts as a bridging service provider. In another embodiment, the second service provider also acts as a bridging service provider. This may include the case where a bridging service provider also has its own payers and receivers and may act as an issuer or an acquirer in a cross-service provider transaction.

[0052] Different Embodiments of Contactless Transaction Flow via Radio Frequency Payment with Enhanced Security

[0053] Below are several different payment flows of radio frequency signals payment with enhanced security. The radio-frequency payment may be NFC payment.

[0054] Case 1:

[0055] In the first case, a digital wallet app of a wallet service provider is involved to convert a target content into a bridging target and present the bridging target to a merchant device. The transaction flow comprises PART A (Steps 1-6) and PART B (Steps 7-12) as illustrated in FIG. 2 and described in detail below.

[0056] PART A: one-time-use radio-frequency target request

[0057] 1. A payer, who is a normal user of first service provider, does not register a user account with the wallet service provider to get a fixed target beforehand. In contrast, a target is requested only after the payer initiates mobile payment. In this step, the first management system of the first service provider (an issuer) authenticates the user and / or the portable device via the first service app, such as JKOPay or PayPay app.

[0058] 2. The first management system relays the target request to a bridging system of an intermediary institution called “bridging service provider”. To distinguish the target request from others, a payer identifier (e.g., a user identifier of the payer) is provided along with the target request. The payer identifier is used in the bridging system to uniquely identify the payer in the bridging network. The payer identifier may be generated by the first service provider or the bridging service provider. And the payer identifier may be tokenized to enhance security and privacy. In the case where the payer identifier is generated by the bridging service provider, the bridging system may assign a new payer identifier to a new payer when the first service provider register the new payer in the bridging network.

[0059] 3. The bridging system creates a transaction identifier, such as transaction ID or job ID, mapped with the payer identifier and generates target content of a one-time use bridging target(one-time-use radio-frequency target). The bridging target is also mapped with the transaction identifier in the bridging service provider. An expiration time such as 1 min or 5 min may be applied to the target.

[0060] 4. The target content of the one-time use target is sent back to the first management system of the first service provider.

[0061] 5. The first management system relays the target content to the portable device of the payer via the first service app installed in the portable device.

[0062] 6. The first service app transmits the target content to a digital wallet app of a wallet service provider (e.g. Apple Pay), so that the digital wallet app can present the one-time-use radiofrequency target to the receiver.

[0063] PART B: radio-frequency contactless payment transaction

[0064] 7. The payer pays by providing the one-time-use radio-frequency target or its tokenized object via radio frequency signals to a merchant device (e.g., a point of sale (POS) device or system) of a receiver (e.g., a merchant).

[0065] 8. The receiver sends one-time-use radio-frequency target or its tokenized object, with payment (transaction) information to a second management system of the second service provider or its supporter which recognizes the radio-frequency target for authorization.

[0066] 9. The second management system parses the one-time-use radio-frequency target or its tokenized object to determine the bridging service provider (or the first service provider), and then routes the related information to the bridging system for authorization. The routing may be based on a routing identifier in the target content which identifies the bridging service provider.

[0067] 10. The bridging system accepts or declines the transaction. This step may further include a step of providing a transaction request and payment (transaction) information to the first management system for authorization (10a) and receiving a transaction approval from the first management system (10b).

[0068] 11. The response is sent back to the second management system.

[0069] 12. The transaction result is routed back to the receiver for their confirmation.

[0070] In this payment (transaction) flow, both PART A and PART B are executed every time when a radio-frequency mobile payment is initiated by the payer.

[0071] Case 2:

[0072] In the second case, a third service provider provides target content of bridging targets to the first service provider for the payer to present the bridging target to a merchant device. The transaction flow comprises PART A (Steps 1-6) and PART B (Steps 7-14) as illustrated in FIG. 3 and described in detail below.

[0073] PART A: one-time-use radio-frequency target request

[0074] 1. A payer, who is a normal user of first service provider, does not register a user account with the first service provider to get a fixed target beforehand. In contrast, a target is requested only after the payer initiates mobile payment. In this step, the first management system of the first service provider (an issuer) authenticates the payer and / or the portable device via the first service app, such as JKOPay or PayPay app.

[0075] 2. The first management system relays the target request to a bridging system of an intermediary institution called “bridging service provider”. To distinguish the target request from others, a payer identifier of the payer is provided along with the target request. The payer identifier may be generated by the first service provider or the bridging service provider. And the payer identifier may be tokenized to enhance security and privacy.

[0076] 3. The bridging system creates a transaction identifier, such as transaction ID or job ID, mapped with the payer identifier. Then the bridging system relays the target request and the transaction identifier to a third management system of a third service provider.

[0077] 4. The third management system generates a target content of a one-time use bridging target (one-time-use radio-frequency target) and maps it with the transaction identifier. An expiration time such as 1 min or 5 min may be applied to the target. The one-time use target or its content is sent back to the bridging system of the bridging service provider.

[0078] 5. The bridging system relays the target content to the first management system of the first service provider.

[0079] 6. The first management system further relays the target content to the portable device of the payer via the first service app installed in the portable device so that the payer can use the radio-frequency target on the portable device.

[0080] PART B: NFC contactless payment transaction

[0081] 7. The payer pays by providing the one-time-use radio-frequency target via radio frequency signals to a merchant device (e.g., a point of sale (POS) device or system) of a receiver (e.g., a merchant).

[0082] 8. The receiver sends the one-time-use radio-frequency target with payment (transaction) information to a second management system of the second service provider which recognizes the radio-frequency target for authorization.

[0083] 9. The second management system parses the one-time-use radio-frequency target to determine the third service provider, and then routes the related information to the third management system of the third service provider for authorization. The routing may be based on a routing identifier in the target content which identifies the third service provider.

[0084] 10. The third management system recognizes the radio-frequency target and routes the related information to the bridging system for authorization.

[0085] 11. The bridging system accepts or declines the transaction. This step may further include a step of providing a transaction request and payment (transaction) information to the first management system for authorization (I la) and receiving a transaction approval from the first management system (11b).

[0086] 12. The response is sent back to the third management system.

[0087] 13. The response is sent back to the second management system.

[0088] 14. The transaction result is routed back to the receiver for their confirmation.

[0089] In this payment (transaction) flow, both PART A and PART B are executed every time when a radio-frequency mobile payment is initiated by the payer.

[0090] Case 3:

[0091] The third case is similar to the second case, except that the third service provider is the same as the acquirer. The transaction flow of the third case comprises PART A (Steps 1-6) and PART B (Steps 7-12) as illustrated in FIG. 4 and described in detail below.

[0092] PART A: one-time-use radio-frequency target request

[0093] 1. A payer, who is a normal user of first service provider, does not register a user account with the first service provider to get a fixed target beforehand. In contrast, a target is requested only after the payer initiates mobile payment. In this step, the first management system of the first service provider (an issuer) authenticates the payer and / or the portable device via the first service app, such as JKOPay or PayPay app.

[0094] 2. The first management system relays the target request to a bridging system of an intermediary institution called “bridging service provider”. To distinguish the target request fromothers, a payer identifier is provided along with the target request. The payer identifier may be generated by the first service provider or the bridging service provider. And the payer identifier may be tokenized to enhance security and privacy.

[0095] 3. The bridging system creates a transaction identifier, such as transaction ID or job ID, mapped with the payer identifier. Then the bridging system relays the target request and the transaction identifier to a second management system of the second service provider.

[0096] 4. The second management system generates a target content of a one-time use bridging target (one-time-use radio-frequency target) and maps it with the transaction identifier. An expiration time such as 1 min or 5 min may be applied to the target. The one-time use target or its content is sent back to the bridging system of the bridging service provider.

[0097] 5. The bridging system relays the target to the first management system of the first service provider.

[0098] 6. The first management system further relays the target content to the portable device of the payer via the first service app installed in the portable device so that the payer can use the radio-frequency target on the portable device.

[0099] PART B: NFC contactless payment transaction

[0100] 7. The payer pays by providing the one-time-use radio-frequency target via radio frequency signals to a merchant device (e.g., a point of sale (POS) device or system) of a receiver (e.g., a merchant).

[0101] 8. The receiver sends the one-time-use radio-frequency target with payment (transaction) information to the second management system of the second service provider which recognizes the radio-frequency target for authorization.

[0102] 9. The second management system parses the one-time-use radio-frequency target and discovered that the target is issued by itself, and then routes the related information to the bridging system for authorization.

[0103] 10. The bridging system accepts or declines the transaction. This step may further include a step of providing a transaction request and payment (transaction) information to the first management system for authorization (10a) and receiving a transaction approval from the first management system (10b).

[0104] 11. The response is sent back to the second management system.

[0105] 12. The transaction result is routed back to the receiver for their confirmation.

[0106] In this payment (transaction) flow, both PART A and PART B are executed every time when a radio-frequency mobile payment is initiated by the payer.

[0107] In Case 2 and Case 3, the target content of the bridging target is designed to be recognizable to multiple acquirers, where in Case 3 the second service provider happens to be the same as the third service provider which issues the target content. Therefore, in both Case 2 and Case 3 the target content should have a format acceptable to multiple acquirers, such as standards complying with EMV Specification.

[0108] Case 4:

[0109] In Case 4, the first service provider is the issuer, and the second service provider is the acquirer. Here, the receiver is a merchant with a merchant device linked to an acquirer. The merchant device may be a POS system which can accept credit cards and other NFC-based payment methods. The acquirer may be an acquiring bank. There are several ways to use or modify existing routes to perform bridged transactions between a portable device of a payer and the merchant device of a receiver. In this case, the portable device provides a target with format of the acquirer. Although the transaction flow of this case is similar to Case 3, in Case 4 the bridging target is designed to be recognizable to the second service provider only. Therefore, the target content needs not to take a widely accepted format (e.g., EMV standards) but can use the second service provider’s self-developed format. The transaction flow of Case 4 comprises PART A (Steps 1-7) and PART B (Steps 8-13) as illustrated in FIG. 5 and described in detail below.

[0110] PART A: one-time-use bridging target request

[0111] 1. A payer, who is a normal user of the issuer, initiates mobile payment and request a bridging target for the transaction. In this step, the first service provider authenticates the user and / or the portable device via an issuer app, such as JKOPay or PayPay app.

[0112] 2. The first management system of the first service provider relays the target request to a bridging system of an intermediary institution called “bridging service provider”. To distinguish the target request from others, a payer identifier (e.g., a user identifier of the payer) is provided along with the target request. The payer identifier may be generated by the first service provider or the bridging service provider. And the user identifier may be tokenized to enhance security and privacy.

[0113] 3. The bridging system creates a transaction identifier, such as transaction ID or job ID, mapped with the payer identifier. Then the bridging system relays the target request and thetransaction identifier to a second management system of the second service provider, such as a management system of Taishin Bank.

[0114] 4. The second management system generates content of a one-time use bridging target and maps it with the transaction identifier. An expiration time such as 1 min or 5 min may be applied to the target. The target content of the one-time use target is sent back to the bridging system of the bridging service provider.

[0115] 5. The bridging system relays the target content to the first management system of the first service provider.

[0116] 6. The first management system further relays the target content to the portable device of the payer via the first service app installed in the portable device.

[0117] 7. The first service app generates a bridging target (such as a QR code or an NFC tag) based on the target content so that the payer can use it on the portable device.

[0118] PART B: Bridging target contactless payment transaction

[0119] 8. The payer pays by providing the one-time-use bridging target to a merchant device, such as a point of sale (POS) system of Taishin Bank run by the receiver (e.g., a merchant).

[0120] 9. The receiver sends received target content with payment (transaction) information to the second management system of the second service provider which recognizes the bridging target for authorization.

[0121] 10. The second management system parses the one-time-use bridging target and discovered that the target is issued by itself, and then routes the related information to the bridging system for authorization.

[0122] 11. The bridging system accepts or declines the transaction. This step may further include a step of providing a transaction request and payment (transaction) information to the first management system for authorization (I la) and receiving a transaction approval from the first management system (11b).

[0123] 12. The response is sent back to the first management system and the second management system.

[0124] 13. The transaction result is routed back to the receiver for confirmation.

[0125] In the above example, the bridging target may be with QR code format or with NFC format as described below.

[0126] (1) Bridging target with QR code format: Some merchant devices such as a POS system of Taishin Bank inherently have ability to scan and recognize QR codes of several issuers. Besides, Taishin Bank has its own QR code mobile payment brand (Taishin Pay) with its own format. Therefore, the second service provider may generate bridging targets with target format complying to its own QR code mobile payment. In this case, the first service app (e.g., JKOPay app) can receive and display a bridging target with format of the second service provider (e.g., Taishin Pay). However, the second service provider may also choose to use a QR code format different from its own mobile payment system to conduct bridged transactions. The only requirement is that the merchant device and the second management system recognize the bridging target and relay the transaction request to the bridging system for payment authorization.

[0127] (2) Bridging target with NFC format: Although the system of some acquiring banks have upgraded their systems to enable QR code recognition, not every merchant device of the acquirer run by individual merchants update their hardware to the newest ones. Thus, some merchant devices are not equipped with a scanner to scan QR codes. To deal with this problem, an acquirer (i.e., the second service provider) may choose to use bridging targets with NFC format. This is similar to payment by contactless smartcard via non-EMV NFC. For example, the system of an acquirer, Taishin Bank, can accept payments from iPASS card via non-EMV NFC route. The second service provider may define its own NFC format for bridged transactions, as long as the merchant device and the second management system recognize the bridging target and can relay the transaction request to the bridging system for payment authorization.

[0128] Case 5:

[0129] In this case, the second service provider does not provide a bridging target to the first service provider via the bridging service provider. Instead, the second service provider modifies its system so that a target of the bridging service provider becomes recognizable to the merchant device and the second management system. Here the target of the bridging service provider serves as a bridging target. The first management system of the first service provider may send a request to the bridging service provider for a bridging target, and the bridging system of the bridging service provider may then return one for the portable device’s use. Upon receiving the bridging target, the second management system then relays the transaction request to the bridging system to resolve the issuer and / or the payer. The transaction flow of Case 5 comprises PART A (Steps 1-6) and PART B (Steps 7-12) as illustrated in FIG. 6 and described in detail below.

[0130] PART A: one-time-use bridging target request

[0131] 1. A payer, who is a normal user of the issuer requests a bridging target after the payer initiates mobile payment. In this step, the first management system of the first service provider authenticates the payer and / or the portable device via the first service app, such as JKOPay or Pay Pay app.

[0132] 2. The first management system relays the target request to a bridging system of an intermediary institution called “bridging service provider”. To distinguish the target request from others, a payer identifier of the payer is provided along with the target request. The payer identifier may be generated by the first service provider or the bridging service provider. And the payer identifier may be tokenized to enhance security and privacy.

[0133] 3. The bridging system creates a transaction identifier, such as transaction ID or job ID, mapped with the payer identifier and generates target content of a one-time use bridging target. The bridging target is also mapped with the transaction identifier in the bridging service provider. An expiration time such as 1 min or 5 min may be applied to the bridging target.

[0134] 4. The target content of the one-time use target is sent back to the first management system of the first service provider.

[0135] 5. The first management system relays the target content to the portable device of the payer via the first service app installed in the portable device.

[0136] 6. The first service app generates a bridging target (such as a QR code or an NFC tag) based on the target content so that the payer can use it on the portable device.

[0137] PART B: Bridging target contactless payment transaction

[0138] 7. The payer pays by providing the one-time-use bridging target to a merchant device, such as a point of sale (POS) system of Taishin Bank run by the receiver (e.g., a merchant).

[0139] 8. The merchant device of the receiver sends the bridging target with payment(transaction) information to a second management system of the second service provider (e.g., a management system of Taishin Bank), which recognizes the bridging target, for authorization.

[0140] 9. The second management system parses the one-time-use bridging target to determine the bridging service provider, and then routes the related information to the bridging system for authorization. The routing may be based on a routing identifier in the target content which identifies the bridging service provider.

[0141] 10. The bridging system accepts or declines the transaction. This step may further include a step of providing a transaction request and payment (transaction) information to the firstmanagement system for authorization (10a) and receiving a transaction approval from the first management system (10b).

[0142] 11. The response is sent back to the first management system and the second management system.

[0143] 12. The transaction result is routed back to the receiver for their confirmation.

[0144] Similar to the example in Case 4, the bridging target may be with QR code format or with NFC format as described below.

[0145] (1) Bridging target with QR code format: Some merchant devices such as a POS system of Taishin Bank inherently have ability to scan and recognize QR codes of several issuers. In this case, the issuer app (e.g., JKOPay app) can be modified to gain the ability to receive and display a bridging target with format of the bridging service provider (e.g., HIVEX QR code). It requires that the merchant device and the second management system recognize the bridging target and relay the transaction request to the bridging system for payment authorization.

[0146] (2) Bridging target with NFC format: Although the systems of some acquiring banks have upgraded their systems to enable QR code recognition, not every merchant device of the second service provider run by individual merchants update their hardware to the newest ones. Thus, some merchant devices are not equipped with a scanner to scan QR codes. To deal with this problem, the second service provider may choose to use bridging targets with NFC format. The bridging service provider may define an NFC target format for the first service provider and the second service provider’s use in bridged transactions. In this case, the merchant device and the second management system need to modify their systems to be able to recognize the bridging target and relay the transaction request to the bridging system for payment authorization.

[0147] In Case 4, the first service provider, the second service provider and the bridging service provider use a bridging target with format of the second service provider. In Case 5, a bridging target with format of the bridging service provider is used instead. When multiple acquirers (i.e., acquiring banks) are available, case 5 would be more beneficial, because the bridging target with single format (the format of the bridging service provider) can be used universally. In contrast, in Case 4 the payer needs to know the identity of the second service provider (i.e., the acquirer) and generates bridging target with different formats for merchant devices (e.g., POS system) of different acquirers.

[0148] Besides, initiating a transaction via NFC route may be superior to QR code route. This is because most POS terminals are equipped with NFC sensing functionality, while many POS terminals cannot scan QR codes.

[0149] The case above summarize some embodiments to bridge between two different service providers respectively based on different contactless payment methods. The new radio-frequency payment flow differs from the traditional one in several aspects. First, in the new payment flow, the account authentication is performed only after a payer initiates a payment. This provides the flexibility to the device to accommodate different user accounts on the same portable device. Second, in the new payment flow, the payment target is one-time use and only generated before a transaction, and no radio-frequency token corresponding to the payment target will be permanently stored in the device, such as in the Secure Element or SIM card. The content of the payment target such as radio-frequency code is created on demand for one-time use with expiration time from external source, i.e., the bridging system of the bridging service provider, compared to devicedependent radio-frequency token management such as NFC tokens stored in Secure Element. The short valid period also makes unauthorized use of this target extremely difficult. Third, since in the new payment flow targets are generated by the bridging system, the payer can hide more identity-related information from the acquirer and the receiver. For example, it is possible to hide not only the payer identity but also the issuer (first service provider) identity of the payer from the acquirer, if the generated target does not contain is suer- specific information.

[0150] Examples

[0151] Below are implemented examples for cross-provider transactions between a first service provider based on scannable targets and a second service provider based on radio frequency targets.

[0152] Example 1

[0153] This example shows the flows for a user (who is a payer) of JKOPay (a QR payment service provider) to pay via Apple Wallet’s NFC mobile payment to a merchant (who is a receiver). In this example, JKOPay is a first service provider who acts as an issuer, and Apple Pay is a wallet service provider which may provide contactless NFC payment service to merchants. A merchant device of a receiver may be a traditional POS system which may request payment after sensing an NFC token on a payment card or a portable device. A second service provider (an acquirer) may be a traditional acquiring bank or a financial institution which may collect fund from an issuer on behalf of the receiver. To do so, the second service provider may receive payment request from a POS system of the receiver, and transmit the payment request to the payment network, so that the payment request may then be routed to the first service provider. Besides, a bridging serviceprovider, HIVEX, provides bridging features to enable the user of JKOPay to pay via Apple Wallet’s NFC mobile payment.

[0154] NF C Accessibility

[0155] Regarding NFC mobile payment, one important thing is the accessibility of NFC component in the mobile device. Depending on the mobile device operating system, the access and control of NFC component on the device can be different. For example, Android OS from Google allows mobile applications developers to access the NFC, while iOS from Apple provides limited access. If direct access to NFC is available, there is no need to use central control such as Apple Wallet to perform NFC transactions.

[0156] In the case where the first service app may directly access to the NFC component in the portable device and generate an NFC token complying with payment standards (such as EMVCo standard), after requesting an NFC token from the bridging system and receiving one, the first service app of the first service provider may directly transform the NFC token into an NFC target recognizable to the merchant device (such as POS) of the receiver. The merchant device and / or a second management system of the second service provider should be able to recognize the bridging service provider (such as HIVEX) and route a payment request to the bridging service provider based on the NFC target. This may be achieved through an agreement between the bridging service provider and the second service provider or the payment network.

[0157] For the case where the first service app of the first service provider provides an NFC target to the receiver via registering in a digital wallet app of the wallet service provider (such as Apple Wallet in iPhone or Google Wallet in Android System), 2 features of NFC mobile payment are described in detail: (1) Registering to Mobile Wallet, and (2) Processes in NFC mobile payments with HIVEX’ s bridging features.

[0158] Registering a first service app to Mobile Wallet

[0159] For a mobile wallet service such as Apple Pay, its mobile wallet (digital wallet; Apple Wallet) allows a user (payer) to add a “card”, which is similar to the picture shown in FIG. 7A. A card (icon) can be a payment card such as credit card or debit card, a transit card for transportation purposes, or state IDs. Each card is a unique credential to be used for the sole purpose of the card type.

[0160] In Apple Pay, there are 2 options of adding a mobile app wallet to Apple Wallet:

[0161] (1) Use a flow similar to existing flows - Unique Credential Registration (UCR)

[0162] (2) Add a blank mobile wallet without any specific user identification - Blank Credential Registration (BCR)

[0163] Unique Credential Registration (UCR)

[0164] In this example, Apple Wallet establishes a new category of “Mobile Payment App” that lists, for example, PayPay, JKOPay, and others. A user can add the corresponding Mobile Payment App to the Apple Wallet. Depending on the implementation of the process, there may be additional steps for authentication and registration as described below.

[0165] A user using mobile payment service such as JKOPay, for example, will need to provide a user id from the Mobile App Account Section to Apple Wallet. Apple Wallet passes the user id to mobile payment service provider (e.g., JKOPay) to initiate a verification process, that requires, for instance, the user to enter a 6-digit code sent from mobile payment service provider to the user via a secure and verified method such as a pre-registered cell phone number.

[0166] After successful authorization, a unique id tied to the Mobile Payment App user is stored in the secure area of the mobile device. This unique id can be a user id, a reference id issued by the Mobile Payment App provider, or an id provided by a bridging service provider (e.g., HIVEX) who runs the payment network. In all cases, the unique id needs to be able to support the correct payment routing from the merchant's payment processor or backend payment network.

[0167] Blank Credential Registration (BCR)

[0168] A Mobile Payment App icon can be added without linking to any unique id (e.g., a user id).

[0169] 1. There is a Mobile Payment App installed in the device corresponding to the “payment card” selected by the user. This can be achieved by checking an App identifier (such as Apple Store App ID) that is associated with the Mobile Payment App.

[0170] 2. The version compatibility and support needs to be verified. User will be prompted to update Mobile Payment App if required.

[0171] Processes in NF C mobile payments

[0172] When a user selects the Mobile Payment App icon, it invokes the Mobile Payment App (e.g., via Apple App ID) for the user to perform authentication and start the NFC process. The detailed process is described below. The mobile wallet (e.g., Apple Wallet) should be able to communicate with the Mobile Payment App and get a target content for NFC, which can be used to identify the payment routing later on, to transmit via NFC to the merchant's NFC reader.

[0173] In the following sections, we use an example showing a QR code mobile payment service (JKOPay in this example) user coming to the US to pay at a merchant that accepts Apple Pay.

[0174] Unique Credential Registration (UCR)

[0175] 1. User clicks on Wallet icon on the iPhone

[0176] 2. User select the corresponding Mobile Payment App card (the JKO card in this example) with a mobile payment account registered in Apple Wallet as shown in FIG. 7B

[0177] 3. User taps on the merchant NFC reader and completes the payment transaction

[0178] Blank Credential Registration (BCR)

[0179] 1. User clicks on Wallet icon on the iPhone

[0180] 2. User select the corresponding Mobile Payment App card, in our case, the JKO card

[0181] 3. Apple Wallet recognizes the JKO card and invoke the JKO mobile app on the iPhone

[0182] 4. JKO mobile app request user to sign-on

[0183] 5. With success sign-on, JKO mobile app provides a unique id (e.g., a user id) back to Apple Wallet, where the unique id is (a) stored and provided via the JKO mobile app, or (b) a value provided by payment network, such as HIVEX, for one-time use with expiration time (this process is described in detail later)

[0184] 6. Apple Wallet sends the above unique id along with other required data per Apple NFC standards

[0185] 7. Payment transaction completes

[0186] The BCR process described above is a brief version of the process. A detailed description along with the process flow is expanded below.

[0187] Blank Credential Registration (BCR) with HIVEX’s bridging features

[0188] This section describes in detail the process of using bridging features in conjunction with the one-time use NFC target content provided by HIVEX, a bridging service provider, as shown in FIG. 8 and the process flow below.

[0189] 1. User clicks on Wallet icon on the mobile device and selects the corresponding MobilePayment App card, in this example, the JKO card. The mobile wallet in the OS (e.g., Apple Wallet in iOS) recognizes the JKO card and invoke the JKO mobile app on the mobile device. Then the user is prompted to login to the JKO mobile app. (1.1) With successful login and authentication, it sends an NFC target content to issuer server (JKO mobile backend server). The NFC targetcontent is packaged to comply with, say, EMVCo, standard to translate via NFC to merchant’s NFC reader before it can be sensed by a merchant device.

[0190] 2. Issuer (JKO) backend service relays JKO user id, issuer code, and other information to HIVEX (the bridging service provider) to request an NFC target content. This action initiates a request for a payment target.

[0191] 3. HIVEX creates an NFC target content that is linked to a transaction identifier called REID (Request Eink ID), which is to be used later to resolve HIVEX transactions. An RLID is HIVEX binding identification used to tie issuer and user information when a request for payment, containing the same RLID, is sent by acquirer / merchant. For security reasons, the above NFC target content is one-time use, time-bound expiration, or with other setup to prevent fraudulent activities. Once done, HIVEX sends the NFC target content to issuer (JKOPay) backend service.

[0192] 4. Issuer relays NFC target content to issuer (JKO) mobile app, and then NFC target content is sent to mobile wallet (Apple Wallet). The mobile device activates NFC and sends NFC target content to the merchant’s payment terminal. To proceed with a payment, EMVCo compliance can be performed by issuer (JKO) backend service if not done by HIVEX in step 3.

[0193] 5. After receiving NFC target content in mobile wallet (Apple Wallet), the mobile device activates NFC and sends the target content to the merchant’s payment terminal. EMVCo compliance can be performed by mobile wallet (Apple Wallet) if not done by HIVEX in step 3 and step 4.

[0194] 6. After receiving the NFC data, the merchant’s payment terminal routes NFC target content and transaction information to acquirer or payment processor, which decodes the payload, identifies routing destination as HIVEX, and sends the payment request for authorization.

[0195] 7. Acquirer backend processor sends relevant NFC target content and other information to HIVEX to process the payment transaction.

[0196] 8. Once the payment request, along with the NFC target content, is received by HIVEX, it proceeds to the standard HIVEX transaction flow to authenticate and perform payment authorization, as well as the necessary processes to complete the transaction via NFC target content lookup, RLID matching, and other necessary steps. In some cases, an authorization from issuer may be required to perform transactions.

[0197] 9. HIVEX sends a payment success confirmation to Acquirer backend services with transaction related data and identifier.

[0198] 10. Acquirer backend relays the payment success confirmation to the merchant

[0199] 11. Merchant receives the payment confirmation from Acquirer, and releases the goods or services to JKO users

[0200] In the above example, the wallet service provider is usually different from the acquirer (the second service provider). In this case a digital wallet app of the wallet service provider (such as Apple Wallet in iPhone or Google Wallet in Android System) only receives a content of NFC tag from the first service app and provides a transformed NFC target to the receiver, but does not play an important role on acquirer’s side. Like traditional routes, the POS machine of the receiver sends a payment request to an acquirer bank, and the acquiring bank sends this payment request to the card network to resolve the NFC target. Then the payment request is routed to the bridging service provider for approving the transaction.

[0201] However, since the wallet service provider is configured to recognize an NFC tag or its content of the first service provider generated by the bridging system and transform such a tag into an NFC token, and since some wallet service provider may also act as a financial institution (such as Apple Pay runs Apple Cash), the wallet service provider may also act as an acquirer (the second service provider) who specifically receives NFC targets of service providers based on scannable targets (such as QR code mobile payment service providers).

[0202] In this case, the merchant’s payment terminal (such as POS system) may route NFC target content and transaction information to wallet service provider / second service provider to decode the payload, and identify routing destination as the bridging service provider (HIVEX), and send the payment request for authorization. After authorization, the wallet service provider / second service provider may then directly receive a success confirmation from the bridging service provider and relay it to the receiver.

[0203] Example 2

[0204] This example shows the flows for a user (who is a payer) of a QR payment service provider (e.g., JKOPay) to pay via NFC by utilizing a card issued by a third service provider. The QR payment service provider acts as an issuer in this case. A merchant device of a receiver may be a traditional POS terminal which may request payment after sensing an NFC token on a payment card or a portable device. A second service provider (which acts as an acquirer) may be a traditional acquiring bank or a financial institution which may collect funds from an issuer on behalf of the receiver. Besides, a bridging service provider, HIVEX, provides bridging features to enable the user of the QR payment service provider to pay via NFC mobile payment.

[0205] NFC Accessibility

[0206] This example requires that the first service app to have access and control of NFC component on the portable device, thereby enabling the app to act like a contactless card with NFC payment ability.

[0207] The third service provider being the same as the acquirer

[0208] In the first embodiment, the third service provider is the same as the second service provider, and thus the second management system can recognize the NFC token as a target issued to HIVEX (the bridging service provider) and correctly routes the payment request to the bridging system of HIVEX. Since the target is issued and accepted by the same party, the content of NFC token may be with any format, as long as it can be correctly routed to the bridging system and can be linked to a specific transaction identifier. The second service provider may receive payment request from a POS system of the receiver, and transmit the payment request to HIVEX, so that the payment request can then be routed to the first management system of the first service provider. The payment flow of this embodiment is as illustrated in the above-mentioned Case 3 and FIG. 4.

[0209] The third service provider being different from the acquirer

[0210] In the second embodiment, the third service provider is different from the second service provider, and thus the second management system can recognize the NFC token only if the NFC token complies with some payment standards (such as EMVCo standard, or other standards among all acquirers in a region). For example, the third service provider may assign a card number belonging to a card scheme (e.g., a number representing a VISA card issued by the third service provider) to the payer, and so the third management system may generate an NFC tag or the content thereof and provide it to the first management system via the bridging system. A pool comprising multiple generated card numbers may be established by the third service provider for bridged transactions. Every time when a target for a bridged transaction is requested, a card number from the pool is temporally assigned to this transaction. After the merchant device (such as a POS terminal) of the receiver receives the NFC tag provided by the payer, it transmits the NFC tag and a payment request to the second management system. The second management system will recognize the NFC token as a card issued by the third service provider, and routes the payment request to the third management system of the third service provider via the payment network of the card scheme (e.g., the payment network of VISA). The third management system then recognizes that the NFC tag is for a transaction initiated by a payer of a first service provider using scannable targets, and relays the transaction request to bridging system of HIVEX for approval. The payment flow of this embodiment is as illustrated in the above-mentioned Case 2 and FIG. 3.

[0211] Payment security

[0212] Several measures can be applied to enhance payment security. For example, the third service provider may set a low transaction limit, may check the location of the payer and the receiver, and may set a short validity period for each NFC tokens.

[0213] Regarding transaction limits, the third service provider may ask the first service provider and / or the bridging service provider to provide a transaction limit for a transaction request, and only approve a transaction below this amount.

[0214] The third service provider may also check the location information of the payer and the receiver to prevent fraudulent transactions. The bridging system may collect the location information of the payer from the issuer (i.e., the QR payment service provider) and provide such information to the third service provider. The acquirer may also collect the location information of the receiver and provide it to the third service provider. The third service provider may authorize the transaction only when the payer and the receiver are located at the same place.

[0215] Since an NFC token in this example is only provided after the issuer requests one, the third service provider can set a short validity period for the NFC token, e.g., 1, 3, or 5 minutes after provided. A transaction request received after the validity period should be denied.

[0216] Example 3

[0217] This example shows how to construct an NFC tag for a bridged transaction. In this example, NFC Tag type 4 tag with application identifier (AID) of D2760000850101 is used. There are 5 steps in the NFC communication (APDU command). In the script, “Command” is POS terminal to device, and “Response” is device to POS terminal.1. NDEF Tag Application selectCommand: [0x000xA4 0x040x00 ,0x07 0xD20x76 0x000x00 0x85 0x01 0x01 / / select AID:D2760000850101 0x00]Response: [0x900x00] / / A_OKAY2. Capability Container selectCommand: [0x000xa4 0x000x0c 0x02 Oxel 0x03]Response: [0x900x00] / / A_OKAY3. ReadBinary data from CC fileCommand: [0x00 OxbO 0x000x00 OxOf]Response: [0x00, OxOF, / / CCLEN length of the CC file0x20, / / Mapping Version 2.00x00, 0x3B, / / MLe maximum0x00, 0x34, / / MLc maximum0x04, / / T field of the NDEF File Control TLV 0x06, / / L field of the NDEF File Control TLV OxEl, 0x04, / / File Identifier of NDEF file0x00, OxFF, / / Maximum NDEF file size of 65534 bytes0x00, / / Read access without any security OxFF, / / Write access without any security 0x90, 0x00 / / A_OKAY ]4. NDEF Select command (Section 5.5.5 in NFC Forum spec) Command: [0x000xa4 0x000x0c 0x02 OxEl 0x04] Response: [0x900x00]5. Read custom Binary dataCommand: [0x00 OxbO 0x000x00 OxOf]Response: [0x00, 0x22, / / APDU command length (variable)0xD9, / / header status0x01, / / Type lengthOx lb, / / pay load length (variable)0x02, / / NDEF ID length0x54, / / RTD_TEXT typeOxel, 0x04, / / NDEF ID0x02, / / language code length0x65, 0x6e, / / language code (en){payload} / / payload in HEX array (variable)0x90, 0x00 / / A_OKAY]

[0218] Example 4

[0219] Besides being used in a bridged transaction between a QR-code based mobile payment app and an NFC-based POS terminal, the method described above may also be applied to other scenarios. For example, many public transport systems utilize NFC-based smart card (non-EMV NFC), which can be used for public transport and other electronic purses.

[0220] A first service app of a first service provider can create a virtual card for a specific public transport system with the aid of the bridging service provider. For example, the bridging service provider may provide the target content of a transport card to the first service provider and then to the payer. The target content may either be generated by the bridging system or by the management system of the public transport system. Then the portable device of the payer may create an NFC tag for a virtual card. After linking the virtual card with a mobile payment account (or a subaccount with a prepaid value), the payer can use the portable device just like an NFC-based smart card.This implementation enables the payer to use the features of a transport card with his / her portable device with preferred mobile payment service.

[0221] The foregoing description of embodiments is provided to enable any person skilled in the art to make and use the 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 the innovative faculty. The claimed subject matter 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. It is contemplated that additional embodiments are within the spirit and true scope of the disclosed subject matter. Thus, it is intended that the present invention covers modifications and variations that come within the scope of the appended claims and their equivalents.

Claims

WHAT IS CLAIMED IS:

1. A method for performing a bridged transaction between a payer as a user of a first service provider based on scannable targets and a receiver as a user of a second service provider based on radio frequency targets, comprising: storing, by a bridging system of a bridging service provider, a transaction identifier and a target identifier, wherein the transaction identifier is assigned in association with a payer identifier of the payer in the bridged transaction, and the target identifier is mapped to the transaction identifier; receiving, by the bridging system, a transaction request, after a radio frequency bridging target generated based on the target identifier is presented to a merchant device of the receiver, wherein at least one of the transaction identifier and the target identifier is provided in the transaction request; and identifying, by the bridging system, the first service provider based on the transaction identifier or the target identifier for transaction execution.

2. The method according to claim 1, wherein at least part of the target identifier is not generated based on the payer identifier.

3. The method according to claim 1, wherein the radio frequency bridging target are only used for a single transaction.

4. The method according to claim 1, wherein the target identifier is stored in a portable device of the payer, and is available for multiple transactions.

5. The method according to claim 1, wherein the radio frequency bridging target is only valid within a predetermined time interval.

6. The method according to claim 1, wherein the target identifier provided to a portable device of the payer is in accordance with Europay, MasterCard and Visa (EMV) specifications.

7. The method according to claim 1, wherein the target identifier is provided by the bridging system to the first management system.

8. The method according to claim 7, wherein the payer identifier is provided to the bridging system from the first management system.

9. The method according to claim 7, wherein the payer identifier is created by the bridging system.

10. The method according to claim 7, wherein the target identifier is generated with a routing identifier, and a second management system of the second service provider relays the transaction request to the bridging system according to the routing identifier encoded in the radio frequency bridging target.

11. The method according to claim 7, wherein the bridging system provides the target identifier in response to a target request sent from a payment application of the first service provider on a portable device of the payer.

12. The method according to claim 1, wherein the transaction request is received from a second management system of the second service provider.

13. The method according to claim 1, wherein the transaction request is received from a third management system of a third service provider, and wherein the third service provider is different from the first service provider and the second service provider.

14. The method according to claim 13, wherein the target identifier includes a routing identifier of the third service provider to enable the second management system to relay the transaction request to the third management system according to the routing identifier encoded in the radio frequency bridging target.

15. The method according to claim 7, before storing the transaction identifier and the target identifier further comprising: receiving, by the bridging system, a target request with an identity of the first service provider from the first management system, wherein the transaction identifier is created in association with the payer identifier and the identity of the first service provider.

16. The method according to claim 1, wherein the bridging system receives the target identifier from the first management system.

17. The method according to claim 16, before receiving the target identifier and the transaction identifier further comprising: providing, by the bridging system, a routing identifier to the first management system, such that the target identifier provided by the first management system is embedded with the routing identifier to enable the second management system to relay the transaction request to the bridging system according to the routing identifier encoded in the radio frequency bridging target.

18. The method according to claim 1, wherein the bridging system receives the target identifier from the second management system, and relays the target identifier to the first management system for target generation.

19. The method according to claim 18, before receiving the target identifier and the transaction identifier further comprising: providing, by the bridging system, a routing identifier to the second management system, such that the target identifier provided by the second management system is embedded with the routing identifier to enable the second management system to relay the transaction requestto the bridging system according to the routing identifier encoded in the radio frequency bridging target.

20. The method according to claim 1, further comprising: recording the transaction by the bridging system; and sending, by the bridging system, the transaction notice to the first management system and the second management system.

21. The method according to claim 20, before recording the bridged transaction further comprising: relaying, by the bridging system, the transaction request to the first management system based on the transaction identifier or the target identifier; and receiving, by the bridging system, a transaction approval from the first management system.

22. The method according to claim 20, wherein a transaction information of the bridged transaction is recorded under the transaction identifier.

23. A method for performing a bridged transaction between a payer as a user of a first service provider based on scannable targets and a receiver as a user of a second service provider based on radio frequency targets, comprising: creating or receiving, by a first management system of the first service provider, a target identifier for the bridged transaction; and providing, by the first management system, the target identifier to a portable device of the payer, wherein the target identifier is mapped to a transaction identifier assigned in association with a payer identifier of the payer, wherein the target identifier is used as an identification of a radio frequency bridging target, which is readable to a merchant device of the receiver, and is used for generating a transaction request, and wherein either the target identifier or the radio frequency bridging target is not generated based on the payer identifier.

24. The method according to claim 23, wherein the transaction identifier and the target identifier are generated by and stored in the first management system.

25. The method according to claim 24, wherein the target identifier is generated with a routing identifier, such that a transaction request including a target content encoded in the radio frequency bridging target is able to be routed to the first management system based on the routing identifier in the target content.

26. The method according to claim 24, further comprising: receiving a transaction request by the first management system after the radio frequency bridging target is sensed by the merchant device of the receiver, wherein the transaction request includes a target content encoded in the radio frequency bridging target.

27. The method according to claim 26, further comprising: recording, by the first management system, the bridged transaction; and providing, by the first management system, a transaction notice to the portable device and the merchant device.

28. The method according to claim 23, wherein the target identifier and the transaction identifier are generated by the first management system, and the method further comprises: providing, by the first management system, the transaction identifier and the target identifier to a bridging system of a bridging service provider.

29. The method according to claim 28, further comprising: receiving a transaction request by the first management system after the radio frequency bridging target is sensed by the merchant device of the receiver, wherein the transaction request includes a target content encoded in the radio frequency bridging target, and the transaction request is routed to the first management system via the bridging system based on the transaction identifier; recording, by the first management system, the bridged transaction; and providing, by the first management system, a transaction notice to the portable device and to the merchant device via the bridging system.

30. The method according to claim 23, further comprising: receiving a transaction notice from the bridging system by the first management system after the merchant device of the receiver senses the radio frequency bridging target and the bridging system records a transaction in response to a transaction request sent from the merchant device.

31. The method according to claim 23, wherein the target identifier and the transaction identifier are generated by the first management system, and the method further comprises: receiving a transaction notice from a second management system of the second service provider, after the second management system of the second service provider records a transaction in response to a transaction request sent from the merchant device of the receiver upon sensing the radio frequency bridging target presented by the portable device.

32. The method according to claim 23, wherein the transaction identifier and the target identifier are generated by and stored in a bridging system of a bridging service provider, and the first management system receives the target identifier from the bridging system.

33. The method according to claim 32, further comprising: receiving a transaction request by the first management system after the radio frequency bridging target is sensed by the merchant device of the receiver, wherein the transaction request includes a target content encoded in the radio frequency bridging target, and the transaction request is routed to the first management system via the bridging system based on the transaction identifier stored in the bridging system; approving or executing the bridged transaction by the first management system; and providing a transaction notice by the first management system, to the portable device and to the merchant device via the bridging system.

34. The method according to claim 32, further comprising: receiving a transaction notice from the bridging system by the first management system after the merchant device of the receiver senses the radio frequency bridging target and the bridging system records a transaction in response to a transaction request sent from the merchant device upon sensing the radio frequency bridging target.

35. The method according to claim 32, further comprising: receiving, by the first management system, a transaction notice routed via the bridging system from a second management system of the second service provider, after the second management system of the second service provider records a transaction in response to a transaction request sent from the merchant device of the receiver upon sensing the radio frequency bridging target presented by the portable device.

36. The method according to claim 23, wherein the transaction identifier and the target identifier are generated by a second management system of the second service provider.

37. The method according to claim 36, further comprising: receiving a transaction request by the first management system after the radio frequency bridging target is sensed by the merchant device of the receiver, wherein the transaction request includes a target content encoded in the radio frequency bridging target, and the transaction request is routed to the first management system via the second management system, based on the transaction identifier; approving or executing the bridged transaction by the first management system; and providing a transaction notice by the first management system, to the portable device and to the merchant device via the second management system.

38. The method according to claim 36, further comprising: receiving a transaction notice from the bridging system by the first management system after the merchant device of the receiver senses the radio frequency bridging target and the bridging system records the bridged transaction in response to a transaction request sent from the merchant device upon sensing the radio frequency bridging target.

39. The method according to claim 36, further comprising: receiving, by the first management system, a transaction notice routed via the bridging system from the second management system of the second service provider, after the second management system of the second service provider records the bridged transaction in response to a transaction request sent from the merchant device of the receiver upon sensing the radio frequency bridging target presented by the portable device.

40. A method for performing a bridged transaction between a payer as a user of a first service provider based on scannable targets and a receiver as a user of a second service provider based on radio frequency targets, comprising: receiving, by a second management system of the second service provider, a transaction request from a merchant device of the receiver after a radio frequency bridging target is sensed by the merchant device, wherein the radio frequency bridging target is generated based on a target identifier mapped to a transaction identifier assigned in association with a payer identifier, and the target identifier is not generated based on the payer identifier; and sending, by the second management system, a transaction notice to the merchant device after the bridged transaction is recorded.

41. The method according to claim 40, wherein the target identifier and the transaction identifier are generated by and stored in a bridging system of a bridging service provider, and the target identifier is provided to a portable device of the payer from the bridging system via a first management system of the first service provider before the radio frequency bridging target is presented to the merchant device by the portable device.

42. The method according to claim 40, wherein the target identifier and the transaction identifier are generated by and stored in a first management system of the first service provider, and the target identifier is provided to a portable device of the payer by the first management system before the radio frequency bridging target is presented to the merchant device by the portable device.

43. The method according to claim 40, wherein the target identifier and the transaction identifier are generated by and stored in the second management system, and the target identifier is provided to a portable device of the payer from the second management system viaa first management system of the first service provider before the radio frequency bridging target is presented to the merchant device by the portable device.

44. The method according to claim 40, wherein the bridged transaction is recorded by a bridging system of a bridging service provider, and the transaction notice received by the second management system of the second service provider is provided by the bridging system.

45. The method according to claim 40, wherein the bridged transaction is recorded by a first management system of the first service provider, and the transaction notice received by the second management system of the second service provider is provided by the first management system.

46. The method according to claim 40, wherein the transaction is recorded by the second management system of the second service provider.

47. A method for registering a first service app of a first service provider under a digital wallet app of a wallet service provider based on radio frequency targets in a portable device of a payer of the first service provider based on scannable targets, comprising: receiving, by the digital wallet app in the portable device, a registration request of the first service app listed on an issuer table; verifying, by the digital wallet app, that the qualifying first service app is installed in the portable device of the payer; generating, by the digital wallet app, an issuer icon in the digital wallet app, which, after selected by the payer, activates the first service app to request target content of a radio frequency bridging target.

48. The method according to claim 47, wherein the first service provider does not provide a payer identifier to be stored in the portable device of the payer before completion of registering the first service app.

49. The method according to claim 47, wherein the first service provider does not authenticate the payer before completion of registering the first service app.

50. The method according to claim 47, wherein the radio frequency targets are NFC (near field communication) tags and the scannable targets are QR (quick response) codes.

51. The method according to claim 47, further comprising: receiving, by the digital wallet app, the target content of the radio frequency bridging target from the first service app; generating, by the digital wallet app, the radio frequency bridging target; and providing, by the digital wallet app, the radio frequency bridging target to a merchant device of a receiver of a second service provider different from the first service provider;wherein the merchant device of the receiver recognizes the radio frequency bridging target but does not recognize scannable targets of the first service provider.

52. The method according to claim 51, before receiving the target content of the radio frequency bridging target further comprising: providing, by the digital wallet app, an instruction to the first service app so that the first service app sends out a target request.

53. The method according to claim 51, wherein the digital wallet app generates a tokenized object to replace the radio frequency bridging target.

54. The method according to claim 51, wherein the target content is converted to the radio frequency bridging target by the digital wallet app.

55. A method for performing a bridged transaction between a payer as a user of a first service provider based on scannable targets and a receiver as a user of a second service provider based on radio frequency targets, comprising: receiving, by a third management system of a third service provider, a target request with a transaction identifier from a bridging system of a bridging service provider; providing, by the third management system, target content of a radio frequency bridging target mapped with the transaction identifier to the bridging system; receiving, by the third management system, a payment request from a second management system of the second service provider; authorizing and processing, by the third management system, the bridged transaction based on the payment request; and providing, by the third management system, a transaction result of the bridged transaction to the bridging system and the second management system.

56. The method according to claim 55, before authorizing and processing the bridging transaction further comprising: providing, by the third management system, the payment request to the bridging system; and receiving, by the third management system, a transaction approval from the bridging system.

Images