CN105096115B

CN105096115B - Electronic payment transaction method without point-of-sale terminal and mobile device

Info

Publication number: CN105096115B
Application number: CN201510368135.8A
Authority: CN
Inventors: 潘昕; 谢祥臻
Original assignee: RFCyber Corp
Current assignee: RFCyber Corp
Priority date: 2015-06-29
Filing date: 2015-06-29
Publication date: 2020-04-03
Anticipated expiration: 2035-06-29
Also published as: CN105096115A

Abstract

Techniques are described for completing financial transactions without deploying POS (Point of sale) terminals. According to one aspect of the invention, a user or buyer uses his/her smartphone to complete a monetary transaction with a seller who does not have a POS terminal, instead receiving confirmation from a designated party that the buyer's payment has been received. A platform for supporting such transactions is described.

Description

Electronic payment transaction method without point-of-sale terminal and mobile device

Technical Field

The present invention relates generally to the field of electronic commerce. In particular, the present invention relates to an electronic payment transaction without requiring the seller to have a POS (Point of sale) type device, which is particularly useful for at least two types of merchants, including small entity store merchants and Internet/Internet merchants that do not have an in-store point of sale (POS) system.

Background

With the popularity of smartphones, many small businesses and customers expect to carry their smartphones anytime and anywhere. All smartphones now have a camera that can be used to read QR codes (two-dimensional identification codes). As more and more Near Field Communication (NFC) handsets enter the market, people have contactless Integrated Circuit Card (ICC), also commonly referred to as smart card, reading capability at substantially anytime and anywhere. Furthermore, most of these handsets have one or more Secure Elements (SE). SE is another name for a smart card (e.g., an external existing device such as SD or USB dongle).

A method, an apparatus, a system and/or a platform for completing a financial transaction without deploying a merchant POS are disclosed.

Disclosure of Invention

This section is for the purpose of summarizing some aspects of the invention and to briefly introduce some preferred embodiments. Simplifications or omissions may be made to avoid obscuring the purpose of this section. Such simplifications or omissions are not intended to limit the scope of the present invention.

The present invention relates to techniques for completing a financial transaction without deploying a merchant POS. According to one aspect of the invention, a user or buyer uses his/her smartphone to complete a monetary transaction with a seller, wherein the seller does not have a POS device, instead receiving confirmation from a designated party that the buyer's payment has been received. A platform for supporting such transactions is described.

According to another aspect of the invention, the payment platform allows merchants to accept electronic payments (e.g., IC-based payments) with electronic wallet, credit card, and debit card applications. According to yet another aspect of the invention, electronic payments are successfully made based on a merchant's Identifier (ID) obtained via a user-associated smartphone, where the ID may be presented in the form of a merchant tag (e.g., RFID) or in the form of a one-dimensional or two-dimensional barcode (e.g., QR code).

The invention may be embodied as a method or program, as a single device, as a server, as a system or as part of a system. According to one embodiment, the invention is a method for facilitating a payment transaction without a point of sale (POS) terminal, the method comprising: issuing an identification package to a merchant, the identification package including at least an identifier of the merchant; receiving into a server the identification package from a computing device associated with a user who wishes to make a payment to the merchant, wherein the identification package is obtained by the user from a medium using the computing device; a confirmation message is sent from the server to a device associated with the merchant to indicate that payment to the merchant has been successfully made.

According to another embodiment, the present invention is a mobile device for facilitating a payment transaction without a point of sale (POS) terminal, the mobile device comprising: a memory space for storing a module; a processor connected to the memory space to execute the modules to cause the mobile device to: obtaining an identification package for a merchant when a user is ready to make a payment to the merchant; creating a secure link with a server to send the identification packet, wherein the server is configured to confirm that the identification packet is authenticated; determining how to make the payment from a display on the mobile device; receiving confirmation that the payment has been successfully executed after the server executes the payment to the merchant, wherein the merchant need not have the point-of-sale terminal and only receives a confirmation message from the server that the payment has been received.

In contrast to the prior art, a user or buyer uses his/her smartphone to complete a monetary transaction with a seller who does not have a POS device, instead receiving confirmation from a designated party that the buyer's payment has been received.

Other objects, features and advantages of the present invention will become apparent upon examination of the following detailed description of embodiments thereof, taken in conjunction with the accompanying drawings.

Drawings

The present invention will be readily understood by the following detailed description in conjunction with the accompanying drawings, wherein like reference numerals designate like structural elements, and in which:

FIG. 1A shows an exemplary configuration according to one embodiment of the invention;

FIG. 1B illustrates an internal functional block diagram that may be used in the computing device of FIG. 1A;

FIG. 2 illustrates a data flow between different entities according to one embodiment; and

fig. 3A and 3B illustrate two exemplary deployment platforms, one online and the other offline, respectively.

Detailed Description

In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. The present invention may be practiced without these specific details. The description and representations herein are the ones by which those of ordinary skill in the art effectively convey the substance of their work to others of ordinary skill in the art. In other instances, well-known methods, procedures, components, and circuits have not been described in detail as they are fully understood and so as not to unnecessarily obscure aspects of the present invention.

Reference herein to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one implementation of the invention. The appearances of the phrase "in one embodiment" or "in this embodiment" in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Additionally, the order of blocks in a program, flow, or functional diagram representing one or more embodiments is not inherently related to any particular order nor does it imply limitations in the invention. As used in this specification and the appended claims, the singular forms "a", "an", and "the" include plural referents unless the context clearly dictates otherwise. It should also be noted that the term "or" is generally employed in its sense including "and/or" unless the context clearly dictates otherwise.

The present invention relates to a platform and an application, both designed to allow buyers and sellers to electronically conduct payment transactions. As used herein, any pronoun reference to gender (e.g., his (he), his (him), her (she), her (her), etc.) refers to being neutral. The terms "his", "his" or "his" are used hereinafter for the sake of clarity and convenience of management, unless explicitly noted otherwise. Furthermore, the use of any singular or plural reference should also be taken to indicate the plural or singular, respectively, as the context dictates.

Embodiments of the present invention are discussed herein with reference to fig. 1A-3B. However, those skilled in the art will readily appreciate that the detailed description given herein with respect to these figures is for explanatory purposes as the invention extends beyond these limited embodiments.

Smart cards provide many benefits to consumers, merchants, and banks, such as the ability to store information and improved security through fraud reduction techniques. Smart cards or Integrated Circuit (IC) cards are small-sized cards with embedded integrated circuits that can process information. Smart cards have far more uses than traditional magnetic stripe cards due to their ability to store transaction information and add/subtract values accordingly. Smart cards that incorporate traffic ticketing, convenience stores, supermarkets, fast food restaurants, parking services, payment applications in vending machines, and other point-of-sale applications are becoming increasingly popular worldwide. In china, smart cards are used for a variety of applications, and the advantages of these multi-purpose cards have also proved popular in over 80 cities. In cities such as hong kong, beijing, shanghai and shenzhen, multifunctional smart cards are used not only for transportation but also for payment of electric power, gas and water bills. Typically, smart cards are operated based on point of sale (POS) terminals.

As the use of smartphones has become popular, instead of providing individual physical smartcards, smartcards are implemented together with or within smartphones. Unless otherwise noted, a card herein refers to a function provided by or in a smartphone that can be used as a smart card.

EMV, which stands for Europay, MasterCard and Visa, is an international standard for the interoperation of integrated circuit cards (IC cards or "chip cards") and point of sale (POS) terminals with IC cards and Automatic Teller Machines (ATMs) for authenticating credit and debit card transactions. EMV was a common effort originally conceived by Europay, MasterCard and Visa to ensure security and global interoperability of chip-based payment cards. In addition to EMV, there is also the PBOC (chinese financial integrated circuit card specification) standard. The PBOC standard is a chinese technology and a security standard for smart cards, which applies to both contact smart cards and contactless smart cards. This standard is also known as "chinese EMV" and is largely analogous to the EMV standard. However, the introduction of these standards still requires that electronic payments must be made through the POS terminal.

One of the important features, advantages and objects of the present invention is to provide a payment platform that does not require a POS terminal. FIG. 1A shows an exemplary configuration 100 according to one embodiment of the invention. The platform of fig. 1 has four components, all of which are connected to a network 101. Examples of network 101 include, but are not limited to, a wireless and/or wired network, the internet, and/or a local area network. As a representative, each of the four components is:

a consumer mobile device 102 for making a payment;

merchant smartphone 106 for receiving payment notifications after payment by consumer mobile device 102 is approved;

for offline stores, merchant information stored in media 104 (which can be accessed via contactless means by a consumer smartphone), such as NFC tags, QR codes, bluetooth devices, voice, infrared sources, wireless sources, and iBeacon sources (a very accurate micro-location technology by bluetooth low energy technology developed by apple inc.); the wireless source can be a Wi-Fi hotspot, namely merchant information can be obtained through the Wi-Fi hotspot, the merchant information can be stored in a router for creating the Wi-Fi hotspot, and can also be stored in a cloud, and the merchant information is transmitted to a smart phone of a consumer through the Wi-Fi hotspot; and

the server 108 for implementing the physical POS device function.

User registration: the mobile device 102 is configured as a personal payment terminal associated with the user. The mobile device 102 is configured to access one or more authorization cards therein. In operation, a user first downloads an application or module from a dealer. The vendor may be a service provider, an application Store (e.g., Apple Store or Google Play). In order for the module to be able to make a payment, the user needs to perform the following steps:

first register the identity of the mobile device with a server operated by a service provider (e.g., Fujinggui technologies, Inc., hereinafter referred to as RHG, located in the high New Garden North region in the Nanshan region of Shenzhen, China). The module is configured to read and register the International Mobile Equipment Identity (IMEI) of the mobile handset with the server 108.

Allowing the module to register the number of the mobile handset with the server.

Allowing the module to access payment modules or applications installed on one or more Secure Elements (SE), if they exist. In one embodiment, one or more payment applications are installed on both a software and hardware Secure Element (SE) of the mobile device 102. For example, the software SE is Host Card Emulation (HCE). The hardware SE may be the embedded SE or SWP SIM of the device. It should be noted that the installed module is not responsible for installing and personalizing these payment applications. These applications should have been personalized by the user with the respective issuing entity, such as the issuing bank. Details of the installation and personalization of software modules or applications are provided in co-pending U.S. application serial No.11/739,044, which is hereby incorporated by reference.

Register each payment application on the SE (or each secure element). The installed module is configured to access a Payment System Environment (PSE) on the SE to retrieve a payment application installed on the SE. If the SE supports the PSE, the mobile device 102 reads the required information to select an Application Data File (ADF). If there is no PSE, the mobile device 102 SELECTs a payment application installed on the SE using a list of known application IDs by using a SELECT apdu (application protocol data Unit). With respect to the payment application on the SE, the installed module is configured to allow the user to specify a name for it. For example: ABC bank debit cards, ABC bank ECash and XYZ VISA credit cards so that the user can select one of the named methods to make a payment. When conducting a payment transaction, the installed module is configured to cost-store payment options and/or store the payment options on a server for later use.

After registration, the installed module can use the payment options until:

the payment application associated with the option expires or is not allowed by the corresponding issuing entity;

the mobile device 102 is inadvertently suspended by the backend server or intentionally by the user's request after it detects that it has had some anomalous activity.

According to one embodiment, the user uses an external smart card, in which case the mobile device 102 may be used as a reader for reading the external IC card. In operation, the user must register the external IC card. The registering includes the user submitting a payment card to the module for reading via an NFC interface of the mobile device. Similar to registering payment options on the internal SE, the module is now configured to register a payment application on each external IC card. The module stores payment options and identifiers of external IC cards in server 108. If more than one authorized payment option (both internal and external) is present on the mobile device, the user may set a default payment option.

Referring now to FIG. 1B, FIG. 1B illustrates an internal functional block diagram 120 that may be used in the computing device of FIG. 1A. The computing device 120 corresponds to the mobile device 102 of fig. 1A, and includes a microcontroller 122, a memory 124 in which one module 126 resides, a Secure Element (SE)125, an input interface 128, a screen driver 130 for driving a display screen 132, and a network interface 134. The module 126 is in the form of software representing one embodiment of the present invention and is downloadable from a web application library (e.g., Apple Store) or a designated server (e.g., server 108 of FIG. 1A).

It should be noted that the Secure Element (SE) is a tamper-resistant platform (e.g., a single-chip secure microcontroller) that is capable of securely hosting applications and their confidential and cryptographic data (e.g., key management) according to the rules and security requirements set forth by a set of recognized trusted authorities. Common form factors for SE include: universal Integrated Circuit Card (UICC), embedded SE, and microSD. Both UICC and microSD are removable. In one embodiment of the invention, the software module is configured to act as a SE and is upgradeable by overwriting some or all of its components. Regardless of form factor, each form factor links to different business implementations and meets different market needs. To have the required SE functionality, the SE should have been personalized. Details of SE personalization are described in co-pending U.S. application serial No.13/749,696, which is incorporated by reference.

The input interface 128 includes one or more input mechanisms. A user may interact with the device 120 by entering commands into the microcontroller 122 using an input mechanism. One example of an input mechanism includes a microphone or microphone (mic) for receiving audio commands and a keyboard (e.g., a displayed soft keyboard) for receiving text commands. Another example of an input mechanism is to provide a camera for capturing photos or videos, where the data of the photos or videos is stored in the device 120 for immediate or subsequent use by the module 126. Optionally, as part of the input interface 128, the computing device 120 is equipped with NFC capabilities for reading nearby tags.

A screen driver 130 connected to the microcontroller 122 is provided for obtaining instructions therefrom to drive a display screen 132 to display a list of payment methods, allowing a user thereof to select one of the payment methods for payment. A network interface 134 is provided for allowing the device 120 to communicate with other devices via a specified medium (e.g., a data network).

According to one embodiment, the module 126 is loaded in the memory 124 and run by the microcontroller 122 for the user to access the installed payment application 127 that has been provisioned with the secure element in the computing device 120. The module 126 is configured to allow the user to make payment via the server 108 without requiring the merchant furniture to have a POS terminal.

There is no particular requirement for the terminal used by the merchant, although the computing device 120 may be used by the merchant to receive payment messages from a designated server to confirm that payment has been received for the user or purchaser.

Merchant registration: the server 108 is configured to sign up for a merchant and register the merchant in its back-end database. According to one embodiment, the merchant information includes:

a merchant Identifier (ID) issued by the service provider;

a plurality of mesh points and their locations and/or corresponding mesh point IDs;

acceptable payment methods, which, depending on the merchant, typically include credit cards, debit cards, or electronic purses; and

the merchant type, merchant bank information, etc. required to clear the network.

An identification package is issued for each merchant for user reading. The identification packet allows the server 108 to identify the merchant. Depending on the implementation, the identification packet may be an NFC tag, QR code, bluetooth device, or sound, and may be read out via wireless means (e.g., infrared or bluetooth). Typical information embedded in such identification packets includes:

a merchant ID;

the name of the merchant;

a site ID for identifying the merchant's site; and

the digital summary.

The information on the identification package (e.g., tag) is protected by the digital digest, which is signed with a private key provided by the server 108 when the mobile device 102 creates a secure link with the server 108. The digital digest is used by a payment application on the mobile device 102 to verify the authenticity of the tag. The payment application uses the corresponding public key certificate to recover the plain text of the digest and compare the results of the digest calculation.

Referring now to fig. 2, fig. 2 illustrates a data flow between different entities according to one embodiment. As shown in fig. 2, there are four entities: ICC 202, APK204, RHG backend 206 (or backend server), and publishing entity 208. To facilitate the understanding of fig. 2, the ICC 202 corresponds to a payment option registered with the mobile device 102. In general, ICC 202 may be an external or internal IC card that involves a credit card or electronic wallet in mobile device 102. The APK204 representing the android application package corresponds to the installed module (e.g., 126 of fig. 1B) and the RHG backend 206 corresponds to the server 108. The issuing entity 208 is a business issuing or supporting entity for payment options.

Assume that a checkout at a brick and mortar store uses a transaction flow according to fig. 2, which means that the merchant may not have a POS terminal. Consumers carry smartphones with camera or/and NFC capabilities. The consumer purchases the goods or services and is ready to check out with the merchant. In operation, the consumer uses his smartphone to contact the merchant NFC tag or to activate an installed module (also referred to as APK 204) in his smartphone to read the QR code.

In either case, the APK204 is configured to show merchant information on the consumer handset. If the APK204 is allowed access to the consumer's location-based information (it is well known that most smartphones are able to detect their location), then APK204 may contact the RHG backend 206 to verify the merchant. The current GPS location is used to match the store of the registered offline merchant in the NFC tag, and the APK204 provides an indicator to indicate whether there is a match.

The consumer is allowed to pull down from the RHG backend 206 merchant information that includes a list of acceptable payment methods for the registrar's home. Based on the registered payment options available to the consumer and the payment options acceptable to the merchant, the RHG backend 206 determines a list of acceptable payment options. If the default payment method is acceptable to the merchant, the consumer may proceed with the method. Otherwise, the consumer may select an acceptable payment method offered by the merchant. In one embodiment, if the payment options are not acceptable to the merchant, the payment options accessible to the APK204 change to gray.

Upon selecting the payment method, the consumer enters the payment amount and displays a screen to the merchant. After the consumer touches the button for activating payment, if the selected payment application is on an external ICC, the APK204 should prompt the consumer to place the external ICC card for reading. Otherwise, APK204 transacts with the payment application installed on the SE. The APK204 will first send the device identification code, payment type, payment application information, merchant ID and payment amount to the RHG merchant POS server, which is one of the RHG backend.

After verifying that the payment options are acceptable to the merchant, the RHG backend 206 prepares a SELECT apdu and a GET PROCESS GOPTIONS with the appropriate process option data object list (PDOL) based on the bank information obtained by the merchant. The APK204 is configured to select an application on the SE where the transaction is to be conducted and issue GETPROCESSING OPTIONS to activate the transaction to the payment application. Based on the Application File Locator (AFL) in the GPO response, APK204 should issue a sequence of READ RECORD commands to retrieve RECORDs from the application. This information is then sent to the RHG backend 206 to inform the server of the new transaction.

Subsequent processing between the application and the RHG backend 206 is substantially similar to submitting a payment card to a physical POS in a retail store, except that the APK204 acts as a surrogate on the mobile device for relaying the APDU commands and responses between the backend server and the selected payment application.

Operationally, the back-end server is configured to perform offline data authentication using Static Data Authentication (SDA), Dynamic Data Authentication (DDA), or Composite Data Authentication (CDA) based on the capabilities of the payment application. According to one embodiment of the invention, CDA is always the preferred choice unless the ICC application does not support CDA. The back-end server is configured to perform terminal risk management and terminal action analysis to preliminarily decide whether a transaction should be conducted online or offline.

Based on the result, the back-end server prepares a GENERATE APPLICATION CRYPTOGRAM apdu to query the APPLICATION for one of the following ciphertexts:

transaction Certificate (TC) -offline approval

Authorization request cryptogram (ARQC) -Online authorization

Application Authentication Ciphertext (AAC) -offline rejection.

After analyzing the data, the application may accept the proposed action, decline the transaction, or force an online transaction. If a CDA is selected, the application is configured to compute a dynamic signature included in the response. Upon receiving the response, the back-end server is configured to verify the signature prior to any further action. The verification ensures the authenticity and integrity of the response. If the ARQC is received by the back-end server in the first GENERATE AC (generate AC) response, the back-end server will send the ARRC to the publisher.

ARQC is a digital signature of transaction details that can be checked in real time by the issuing entity. The issuer responds to the authorization request with a response code, an authorization response cryptogram (ARPC), and optionally an issuer script (command string to be sent to the application).

If the response message from the publisher includes publisher authentication data and the application interaction feature indicates that the ICC supports publisher authentication, then the publisher authentication data should be sent to the application in the outer authencate command. The second GENERATE AC (generate AC) sends the book to the application to generate TC or AAC. Likewise, if a CDA is used, the back-end server will first verify the response of the second Generation AC command.

During a transaction, a PIN is requested from a user to identify a cardholder. If the transaction has been successfully completed, then the consumer's RHG Payment APK will show that the payment is completed and the merchant's RHG merchant APK, which is an application installed in the merchant's cell phone or computing device for receiving payment notifications, as shown in FIGS. 3A and 3B, will be triggered and show that the payment is received, the RHG payment APK corresponding to APK204 in FIG. 2. The back-end server performs transaction settlement similar to traditional financial clearing of payment transactions.

The network merchant process comprises the following steps: the consumer checks out at the online store and chooses to pay using the payment methods described herein. The consumer is asked to provide his mobile phone number or other identifier (e.g., an email address, or a driver's license number). The merchant backend calls the RHG payment API to request the RHG collect payment. The request includes the merchant ID, the payment amount, and the mobile phone number. The RHG then announces the consumer via its registered mobile payment terminal. The consumer opens the APK and a payment request is shown on the screen. The information includes details of the merchant and the payment amount. The payment flow is substantially similar to most of the offline transactions described above. After accepting the payment, the RHG server will notify the merchant of the payment. The merchant will continue with the consumer with their existing checkout process.

RHG backend 206: the RHG backend server or system includes at least two primary operations, which may be housed in a single server or multiple servers, which represent at least one server 108 in fig. 1 and one POS server herein. The server 108 is used to manipulate merchant information and act as a surrogate to talk to the RHG POS server or other bank POS server. The substitute prepares the message format for sending to the POS server. The POS server is used to manipulate POS operations. Upon receiving the request from the mobile device, the merchant server accesses a merchant database of merchant information and this information is communicated to a POS server, such as the RHG merchant server and RHG POS server shown in FIGS. 3A and 3B, the RHG payment APK corresponding to the module 126 installed in the mobile device 120.

In one embodiment, the POS server supports two modes of operation: an online mode and an offline mode. It should be noted that the HSM includes the credentials required by the POS server for offline card verification, such as SDA and DDA and CDA computations.

And (3) online mode: in the event that the RHG POS server does not have sufficient rights to authorize the transaction, the POS server needs to operate in an online mode to obtain authorization from the issuing entity. Based on the merchant information, collected card information, and card responses, the server may prepare messages according to the specified format requested, which are then forwarded directly to the issuing entity. The RHG backend processes the transaction as an "online" transaction to the issuing entity.

An off-line mode: in the case where both POS and application agree on an offline transaction, the transaction is handled by the RHG POS server with credentials of the respective issuing entity of the application. Thus, the transaction is simply completed between the application and the RHG backend server. The RHG backend processes the transaction as an "offline" transaction.

Alternate deployment: with respect to the publishing entity, a possible deployment between the publishing entity and the RHG server is that the entity runs the POS server with a merchant server hosted by the RHG. In this deployment, the RHG backend server does not have POS functionality of the publishing entity. It only has merchant information. The RHG backend server acts as a substitute for the POS deployed in the entity's premises, as shown in FIG. 3B. Fig. 3A and 3B illustrate two exemplary deployment platforms, one online and the other offline, respectively.

The invention is preferably implemented in software, but can also be implemented in hardware or a combination of hardware and software. The invention may also be embodied as computer readable code in a computer readable medium. The computer readable medium is any data storage device that can store data which can thereafter be read by a computer system. Examples of the computer readable medium include read-only memory, random-access memory, CD-ROMs, DVDs, magnetic tape, optical data storage devices, and carrier waves. The computer readable medium can also be distributed over network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.

The invention has been described in sufficient detail with a certain degree of particularity. It is to be understood by those skilled in the art that the embodiments of the present disclosure have been made by way of example only, and that various changes in the arrangement and combination of parts may be resorted to without departing from the spirit and scope of the claimed invention. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description of the embodiments.

Claims

1. A method for facilitating a payment transaction without a point-of-sale terminal, the method comprising:

issuing an identification package to a merchant, the identification package including at least an identifier of the merchant;

receiving into a server a payment request from a computing device associated with a user who wishes to make a payment to the merchant, the payment request including a payment method selected from a plurality of payment methods on the computing device and a dynamic signature calculated for the payment, wherein the computing device includes a secure element that is a tamper-resistant platform that is capable of securely hosting applications and confidential and encrypted data in accordance with rules and security requirements set forth by an identified set of trusted authorities, the secure element having been personalized, the identification package being obtained by the user from a medium with the computing device, the computing device running a module preinstalled thereon to register with the server, transmitting an identification code of the computing device to the server upon registration, the computing device installing one or more payment applications in a secure element;

sending, by the server, an authorization request to a publishing entity, wherein the authorization request includes the dynamic signature, the payment application published by the publishing entity;

the issuing entity verifying the authorization request based on the dynamic signature;

performing the payment to the merchant when the server receives a response code for the authorization request from the issuing entity; and

sending a confirmation message from the server to a device associated with the merchant to indicate that payment to the merchant has been successfully received.

2. The method of claim 1, wherein the identification package further comprises a digital digest, and wherein the method further comprises:

creating a secure link between the server and the computing device to receive the identification package; and

extracting the digital digest from the received identification packet to determine whether the identification packet is authenticated.

3. The method of claim 2, further comprising:

after the server determines the payment methods acceptable to the merchant and the corresponding merchant bank information needed for a payment clearing network, causing the computing device to show a list of payment methods available to the user;

wherein the list is provided by a secure element in the computing device;

accepting a selection of the user in the list; and

performing the payment to the merchant.

4. The method of claim 2, wherein the identification package further comprises a plurality of network points owned by the merchant, corresponding locations of the network points, and/or corresponding network point identifiers.

5. The method of claim 1, wherein the media is one or more of a label, a printed code, a bluetooth device, sound, an infrared source, a wireless source, and an iBeacon source.

6. The method of claim 5, wherein the medium is located near a checkout counter or is provided electronically when the merchant conducts an online transaction.

7. The method of claim 5, wherein the tag is read by a near field communication interface of the computing device.

8. The method of claim 5, wherein the printed code is read by a camera of the computing device.

9. The method of claim 8, wherein the printed code is a one-dimensional or two-dimensional barcode.

10. The method of claim 1, wherein the computing device is installed with a module for registering the computing device with the server.

11. The method of claim 10, wherein the module installed in the computing device is configured to access payment applications installed on a secure element in the computing device, wherein each payment application has been configured by a publishing entity.

12. The method of claim 1, wherein the user and the merchant conduct a transaction over a data network, the receiving the identification packet from a computing device in a server comprising:

determining that the identification packet is truly from the computing device installed with a module authorized by the server, wherein the module is configured to read a payment application or an external smart card configured by a secure element of the computing device.

13. A mobile device for facilitating a payment transaction without a point-of-sale terminal, the mobile device comprising:

a memory space for storing a module;

a secure element that is a tamper-resistant platform capable of securely hosting applications and confidential and encrypted data according to rules and security requirements set forth by a set of identified trusted authorities, the secure element having been personalized;

a processor connected to the memory space to execute the modules to cause the mobile device to:

operating a pre-installed module to register with a server, and sending the identification code of the mobile device to the server during registration;

installing one or more payment applications in the secure element, wherein each payment application corresponds to a payment method; and

obtaining an identification package for a merchant when a user is ready to make a payment to the merchant, the identification package including a digital digest;

creating a secure link for the mobile device with a server;

sending the identification packet over the secure link, wherein the server is configured to confirm that the merchant is authenticated to be able to receive the payment;

displaying a list of payment methods acceptable to a merchant, each payment method corresponding to one of the payment methods supported by the secure element;

selecting a payment method for payment based on a display on the mobile device;

sending a payment request to the server, wherein the payment request includes a selected one of the payment methods and the dynamic signature; the server sending an authorization request including the dynamic signature to a publishing entity that publishes the payment application, the publishing entity verifying the authorization request based on the dynamic signature, the payment to the merchant being performed when the server receives a response code from the publishing entity for the authorization request;

receiving confirmation that the payment has been successfully executed after the server executes the payment to the merchant, wherein the merchant need not have the point-of-sale terminal and only receives a confirmation message from the server that the payment has been received.

14. The mobile device of claim 13, wherein the identification package further comprises a digital digest, and wherein the server extracts the digital digest from the received identification package to compare the extracted digital digest with digital digests stored in a database associated with the server.

15. The mobile device of claim 14, wherein the identification package further comprises a plurality of sites of the merchant, corresponding locations of the sites, and/or corresponding site identifiers.

16. The mobile device of claim 13, wherein the merchant's identification package is obtained from media when a user is ready to make a payment to the merchant, the media being one or more of a label, a printed code, a bluetooth device, a sound, an infrared, and an iBeacon source.

17. The mobile device of claim 16, further comprising:

a near field communication interface or a camera to read the tag or the printed code.

18. The mobile device of claim 13, wherein the module is further configured to register the mobile device with the server.

19. The mobile device of claim 18, wherein the module installed in the mobile device is configured to access payment applications installed on the secure element in the mobile device, wherein each payment application has been configured by a publishing entity.

20. The mobile device of claim 13, wherein the user and the merchant conduct transactions over a data network, the module configured to read a payment application or an external smart card configured by a secure element of the mobile device.