KR101884600B1 - Method, system and service server for non-facing payment - Google Patents

Abstract

A non-facing payment method, system and service server for providing a non-face-to-face transaction service, the non-face payment method comprising the steps of: issuing a payment card issued by a financial company server or the service server to a customer terminal ; Publishing the payment card through a service application running on a customer terminal; Receiving payment request information generated by the customer terminal when the customer terminal performs non-face-to-face payment using the payment card; And processing payment approval using information included in the payment request information.

Description

METHOD, SYSTEM AND SERVICE SERVER FOR NON-FACING PAYMENT,

The present invention relates to a non-face settlement method, system and service server, and more particularly, to a non-face settlement method, system and service server capable of paying without using a payment terminal in an offline store or a non- I suggest.

In recent years, mobile payment using mobile terminals has been popular in the payment market. However, most people still think of plastic cards in real time, and payment terminals in stores also support real card payment. The effectiveness and convenience of real cards can not be ignored.

In addition, although the spread of mobile payment using a mobile card or an application is widespread, there is a limit in that when an existing mobile card makes a payment directly at an offline merchant, payment must be made through the payment terminal as in the real card. That is, since the offline merchant must have a payment terminal such as a POS terminal or a CAT terminal for payment, the user must bear the cost of installing and maintaining the terminal when using the payment service.

As a prior art for solving such a problem, Korean Patent Laid-Open No. 10-2012-0029305 discloses a method and system for providing a school settlement service using a wireless message, and a recording medium for the system. This is a method in which a user accesses the callback URL through a terminal using an SMS message including a callback URL and performs settlement. However, this payment structure has the same structure as general online payment, and operates in conjunction with a financial institution server (credit card company or other financial company) via PG company or VAN company. Therefore, it can not achieve the effect of the fee reduction compared with the existing online settlement, and the merchant and the user have to bear the commission. In addition, since payment request must be obtained through a settlement institution, payment request and approval take time.

Korean Patent Laid-Open No. 10-2012-0029305 (published on Mar. 26, 2012)

It is an object of the present invention to provide a non-face settlement method, system and service server using virtual payment information in order to solve the problems of the prior art and to perform non-face settlement of an affiliate shop.

A non-facing payment method, system and service server for providing a non-face-to-face transaction service, the non-face payment method comprising the steps of: issuing a payment card issued by a financial company server or the service server to a customer terminal ; Publishing the payment card through a service application running on a customer terminal; Receiving payment request information generated by the customer terminal when the customer terminal performs non-face-to-face payment using the payment card; And processing payment approval using information included in the payment request information. At this time, the payment request information may include at least one of a token value of the payment card, merchant information, payment amount information, user input information, and authentication information.

Another aspect of the present invention is a non-face-to-face payment service server for implementing a non-face settlement service, comprising: a payment server for issuing a payment card for non-face-to-face settlement; A card information issuing unit; And a transaction processor for receiving the payment request information generated for the payment card from the customer terminal and processing the payment approval using the information included in the payment request information when the non-face payment is performed.

In another aspect of the present invention, there is provided a non-face-to-face payment system which performs non-face-to-face settlement using a payment card selected through a service application, generates payment request information using the payment card, A customer terminal for transmitting the service request; And a service for providing the service application to issue the settlement card, receiving the settlement request information from the customer terminal when performing non-face-to-face settlement, and processing payment approval using information included in the settlement request information Server. At this time, in the case of using the financial institution payment card which is the payment card issued by the financial institution, the service server can perform non-face-to-face settlement in cooperation with the financial company server.

According to the non-face settlement system of the present invention, payment can be made to an offline merchant without a separate merchant payment terminal. In particular, in the case of a non-store merchant or a street vendor who can not use a payment terminal, since the transaction history can be confirmed and acquired through the mobile phone held by the shop owner, there is no installation and operation cost of the payment terminal, And can contribute to promoting the spread of electronic transaction services.

According to the present invention, a payment service can be implemented without the involvement of a payment gateway (PG) or a value added network (VAN) company by realizing a non-face-to-face payment using a prepaid electronic card unlike the existing online payment. In this way, if there is no intermediary between PG and VAN, it is possible to give an opportunity to save a large payment commission.

In addition, since the prepaid electronic card can be used to make non-face-to-face settlement even without visiting the offline merchant, the user convenience is improved. Furthermore, according to the embodiment, it is possible to perform settlement without complicated approval procedure or authentication procedure in non-face-to-face settlement, thereby realizing quick and convenient settlement.

1 is a schematic diagram illustrating a non-facing payment system according to an embodiment of the present invention.
2 is a block diagram illustrating a service server configuration of a non-facing payment system according to a first embodiment of the present invention.
3 is a flowchart illustrating a non-face settlement and settlement procedure according to the first embodiment of the present invention.
4 is a screen shot on a customer terminal for explaining a settlement procedure of the non-facing settlement system according to the first embodiment of the present invention.
5 is a screen shot on the merchant terminal for explaining the settlement process of the non-facing payment system according to the embodiment of the present invention.
6 is a block diagram illustrating a configuration of a service server of a non-facing payment system according to a second embodiment of the present invention.
7 is a flowchart illustrating a non-face settlement and settlement procedure according to the second embodiment of the present invention.
8 and 9 are screen shots on the customer terminal for explaining the settlement process of the non-face settlement system according to the second embodiment of the present invention.
10 and 11 are screen shots illustrating a non-face settlement proceeding procedure according to another embodiment of the present invention.
Like reference numbers in the several drawings indicate like elements.

It is to be understood that the specific structural or functional description of embodiments of the present invention disclosed herein is for illustrative purposes only and is not intended to limit the scope of the inventive concept But may be embodied in many different forms and is not limited to the embodiments set forth herein.

The embodiments according to the concept of the present invention can make various changes and can take various forms, so that the embodiments are illustrated in the drawings and described in detail herein. It should be understood, however, that it is not intended to limit the embodiments according to the concepts of the present invention to the particular forms disclosed, but includes all modifications, equivalents, or alternatives falling within the spirit and scope of the invention.

The terms first, second, etc. may be used to describe various elements, but the elements should not be limited by the terms. The terms may be named for the purpose of distinguishing one element from another, for example, without departing from the scope of the right according to the concept of the present invention, the first element may be referred to as a second element, The component may also be referred to as a first component.

It is to be understood that when an element is referred to as being "connected" or "connected" to another element, it may be directly connected or connected to the other element, . On the other hand, when an element is referred to as being "directly connected" or "directly connected" to another element, it should be understood that no other element exists in between. Other expressions that describe the relationship between components, such as "between" and "between" or "neighboring to" and "directly adjacent to" should be interpreted as well.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. The singular expressions include plural expressions unless the context clearly dictates otherwise. In this specification, the terms "comprises" or "having" and the like are used to specify that there are features, numbers, steps, operations, elements, parts or combinations thereof described herein, But do not preclude the presence or addition of one or more other features, integers, steps, operations, components, parts, or combinations thereof.

Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Terms such as those defined in commonly used dictionaries are to be interpreted as having a meaning consistent with the meaning of the context in the relevant art and, unless explicitly defined herein, are to be interpreted as ideal or overly formal Do not.

FIG. 1 illustrates a non-facing payment system 100 according to an embodiment of the present invention. More specifically, the billing system 100 of the present invention includes a customer terminal 110 for performing non-face-to-face settlement through a service application provided by a service server, a service server for providing a payment card and implementing a non- 200, a merchant terminal 130 that requests payment card issuance through a contract with a service server and provides goods, and a financial institution (card or bank) card provided by a financial company, (300) and an affiliate server (400) operable with the service server. However, the configuration of the non-facing settlement system 100 is not limited thereto and includes all settlement systems and methods that can be inferred according to various embodiments.

The customer terminal 110 is a device carried by or possessed by a customer and includes various terminals capable of driving a service application provided by the service server 200. The customer terminal 110 may be a mobile phone, a smart phone, a smart pad, a notebook computer, a digital broadcasting terminal, a PDA (Personal Digital Assistants), a PMP (Portable Multimedia Player), a navigation device, PCs, and various wearable devices such as smart watches, smart bands, and the like. However, the present invention is not limited to this, and may be various types of devices capable of operating a communication function capable of wireless communication and a separate application capable of executing a payment service.

The customer terminal 110 may install and operate a service application provided by the service server 200. [ The customer terminal 110 can download a service application provided by the service server 200 in an application market (for example, an application store or a Google Play market). In one embodiment, a secure application for payment may be installed together.

In one embodiment, the merchant terminal 130 can use the terminal held by the merchant dealer as the merchant terminal. The merchant terminal may be a cellular phone, a smart phone, a smart pad, a notebook computer, a digital broadcasting terminal, a PDA (personal digital assistant), a portable multimedia device (PMP) Player, Navigation, Tablet PC and SmartWatch, SmartBand, and the like. The merchant terminal may be one or more various types of electronic devices such as a PC or a staff mobile terminal possessed by a shop.

In another embodiment, the merchant terminal 130 may be a point-of-sale (POS) system, a credit authorization terminal (CAT), a near field communication (NFC) terminal, or the like as a separate payment terminal installed to use an existing payment system Various types of settlement terminals can be provided. The non-facing payment method according to an embodiment of the present invention does not use an existing payment terminal such as POS or CAT at the time of payment, but can be implemented so as to be linked with an existing payment terminal for checking settlement or settlement history.

In addition, the merchant-focused merchant terminal 130 can install and operate a service application provided by the service server 200, and can confirm and settle transaction details and the like during non-face-to-face transactions through the service application. The service application can create and manage separate accounts for merchant partners or provide separate service applications for merchants.

The service server 200 refers to a non-face settlement service management server operated by a service provider, and can implement the payment system of the present invention through a service application to a user and an affiliate shop. The service server 200 can exchange transaction information with the customer terminal 110 and the merchant terminal 130 and can operate in cooperation with a financial company server 300 such as a credit card company or a bank and / can do. The specific configuration of the service server 200 will be described later with reference to Fig.

In an embodiment, when the service server 200 performs non-face-to-face settlement through the issuance and settlement of the prepaid card, payment and settlement can be implemented by itself. In the case where the service server 200 issues payment by issuing the prepaid card, the issued prepaid card includes the merchant identification information, the amount information, the merchandise information, and the like, and does not go through authentication (or approval) The payment approval can be processed through the service server 200. In another embodiment, when the service server 200 performs non-face-to-face settlement using a credit card or a check card issued by another institution (for example, the financial company server 300 or the affiliate server 400), the service server 200 200 may relay payments and implement payment systems in cooperation with other institutional servers.

The service server 200 can issue a payment card in response to a request from the merchant terminal 130. [ In one embodiment, the service server 200 may issue a payment card in accordance with a contract with an affiliate shop where the merchant terminal 130 is located, or may issue a payment card when receiving a request from the affiliate shop terminal. When the customer terminal 110 performs the non-face-to-face settlement using the settlement card, the service server 200 can receive and analyze the settlement request information and process payment approval. Thereafter, the service server 200 can notify the merchant account holder of the settlement approval result, and the merchant can confirm the approval details through the merchant terminal or the payment terminal.

In the billing system 100 of the present invention, the service server 200 may include card information and merchant information (or merchandise information) at the same time when a card is issued. . As this payment system is realized, there is no need to go through a Value Added Network (VAN) or a Payment Gateway (PG), which reduces commissions and enables non-face-to-face payments without using existing payment networks.

As an example, the service server 200 may be a HCE (Host Card Emulation) based service server. The service server 200 does not store personal information such as card information in a hardware SE such as a UICC (Universal Integrated Circuit Card) and an embedded SE (Secure Element), but instead stores it in a provider server that performs a cloud SE (or a cloud platform) Stored, and managed. In order to solve the security problem in implementing the HCE technology, a tokenization technique is employed to issue a token corresponding to card information (for example, PAN), and card information or personal information is exposed .

In addition, when the service server 200 is an HCE-based server, it can be implemented to operate in conjunction with a TSP (Token service provider) server. The TSP server may be implemented as a separate server or may be implemented to operate in conjunction with the service server 200 within the service platform. The TSP server issues a token value corresponding to PAN (Primary Account Number) information to the card information received from the customer terminal 110. The token value is the virtual payment information and plays the same role as the PAN at the payment, but unlike the PAN, it can be changed to a new token value at the time of leak. The TSP server can map the issued token value and the PAN information and store it in the form of a table. In another embodiment, the TSP server may be configured to use a predetermined algorithm that can infer a value between the token value and the PAN information, or to store only the path to the token value and PAN value mapping table.

The payment system 100 according to an embodiment of the present invention may issue a payment card containing merchant information, and the payment card may be issued in the form of an HCE card containing a token value instead of the card information. The customer terminal 110 can purchase a payment card to perform non-face-to-face transactions, and can generate payment request information for non-face-to-face transactions and request payment. The service server 200 performs payment approval processing through information extracted from the received payment request information. Thereafter, the service server 200 may transmit the payment notice and the details to the merchant terminal 130.

In addition, the service server 200 may apply a security function to a service application and a communication section. The service server 200 can safely protect the service application itself from hacking or rooting by applying a vaccine, an app forgery prevention function, and a security keypad to detect forgery and falsification of the application itself. For data security, the service server 200 can encrypt and manage card information and key values used for settlement. For example, the card information and the key value used for payment can be encrypted with the storage key and stored in the database in the customer terminal 110. In addition, a key can be embedded in the encryption algorithm itself to prevent leakage of the storage key.

The service server 200 can perform a dual encryption process upon communication between the service application and the service server 200. The service server 200 newly generates an encryption key for each communication, first encrypts all data to be transmitted using a one-time mobile session key, performs secondary encryption using a secure communication protocol during communication, The confidentiality and integrity of the data can be ensured.

In the payment system using the mobile card of the present invention, it is possible to perform payment using the token value which is the virtual payment information, and it is possible to make non-face-to-face settlement for an offline merchant without using a separate terminal.

Also, in the prepaid card payment system, by using the non-face settlement, it is possible to implement non-face settlement such as online settlement by utilizing the information stored in the prepaid card at the time of issuance, thereby maximizing the convenience and practicality of the user.

2 is a block diagram illustrating a configuration of a service server 200 of a non-facing payment system according to the first embodiment of the present invention. In this embodiment, a method of performing settlement through a prepaid electronic card in a non-face-to-face transaction will be mainly described. The service server 200 includes an information transmitting and receiving unit 210, an application managing unit 220, a card information managing unit 230, a card information issuing unit 240, a transaction processing unit 250, a settlement processing unit 260, A merchant information storage medium 270, a customer information storage medium 280, and a card information storage medium 290 as databases. In this specification, the case where the service server 200 performs the non-face-to-face transaction and the settlement is mainly described, but the present invention is not limited thereto, and the service server 200 may operate in conjunction with the settlement server, the electronic receipt issuing server, Settlement can be carried out. The service server 200 may be implemented as a platform for implementing a payment service, and each of the components 210 to 290 constituting the service server 200 may be implemented as a server. Although the present invention has been described with reference to a product payment process, the present invention is not limited thereto, and the present invention can be applied to various non-face settlement areas such as donation settlement, registration fee settlement, and the like.

The information transmitting and receiving unit 210 is a module for transmitting and receiving information (for example, payment data) with the customer terminal 110, the merchant terminal 130, the financial company server 300 or the affiliate server 400. In one embodiment, upon receiving a payment request message from the customer terminal 110, the information transmission / reception unit 210 receives the payment request message and transmits the payment request message to the transaction processing unit 250 to perform approval or rejection processing for the payment request . In addition, the information transmitting and receiving unit 210 performs a response to various transmission messages, such as reading or requesting information from the customer terminal 110 or the merchant terminal through the service application, in cooperation with other configurations 220 to 290 do.

The application management unit 220 is a module for managing a service application to be provided to a user such as a customer or an affiliate shop. The application management unit 220 manages a life cycle of a user and a service, and manages a MAP (Mobile Application Platform) .

The card information management unit 230 is a component for managing the card information issued for the user account, and manages the KOD server for performing stakeholder management and card service management, the prepaid card issuance request, and other service menus for the card A server, and the like.

The card information issuing unit 240 is a component for issuing a non-face-to-face payment card at the request of the merchant, and may be implemented as a processor or a server. In one embodiment, the card information issuing unit 240 may be integrated with the TSP server or may be integrated with the TSP server to issue the HCE card. The TSP server may store the token value by mapping it to the card information (PAN). In addition, the card information issuing unit 240 may include a server for processing a card issuance request, a server for managing PAN information and a key value, and a DCP (Digital Card Platform) for generating a HCE digital card, managing the lifecycle of the card, ) Server.

In one embodiment, the payment card can be issued in a fixed form or in a chargeable form in consultation with the merchant. The card information issuing unit 240 can generate the token value, the card ID, and the PAN information of the new card at the time of issuing the new card, and store the token value, the card ID, and the PAN information in the card information storage medium 290. The card information issuing unit 240 may issue a payment card containing the token value to the customer terminal and output the card list including one or more payment cards to the customer terminal 110 through the service application. The customer terminal 110 can use the card for non-face-to-face settlement after purchasing the card to be paid. For example, when a member school A requests to issue a payment card for payment of a school fee in January, the card information issuing unit 240 can issue a card for payment of the school expenses of the A school, It can be specified up to 31st of month. Also, if the tuition fee is fixed, the amount can be issued on the designated fixed amount card. In one embodiment, when the customer requests extension of the validity period of the payment card, the card information management unit 230 and the card information storage medium 290 may interlock with each other and change the property information of the payment card.

In one embodiment, the payment card may be a one-time card for non-face-to-face payment. That is, after the customer terminal 110 selects the corresponding card and makes a payment, it can be deleted from the held card list of the user. As another example, the non-face-to-face payment card may be managed as a separate list.

In the case where the payment card of the present invention is a prepaid electronic card, the card information issuing unit 240 is issued with not only card information but also merchant information and product information at the time of issuance. For example, in the case of a 5,000-won payment card that can be used at a coffee shop, it may include a token value corresponding to card information, Merchant ID and amount information of A coffee shop. When such information is contained, payment is possible only by selecting a payment card without having to separately receive or generate merchant information and merchandise information at the time of payment. As described above, according to the non-facing payment method according to an embodiment of the present invention, since payment is made using a payment card containing merchant information and product information, payment request information (message) can be generated without a payment terminal, Face settlement can be realized.

The transaction processing unit 250 is a processor (or server) that processes the payment request information received from the customer terminal 110. [ The transaction processing unit 250 may be implemented as one or more servers for payment processing. For example, upon receipt of the payment request information, it may include a payment processor (PP) server for processing payment specialties and an issuer token adapter (ITA) server for processing the cryptogram verification and PAN token conversion requests. In one embodiment, the ITA server may interoperate with a TSP (Token Service Provider) server that stores the PAN value and the token value to convert and verify the token value. Also, the transaction processing unit 250 may include an Issuer Authorization Switch (IAS) server for performing final approval processing, refund processing, and balance management. In addition, it may include a remote payment gateway (RPG) server for relaying transaction authentication and information, and a virtual VAN server for providing a virtual VAN when there is no VAN to provide a transaction interface.

Upon receipt of the payment request information from the customer terminal 110, the transaction processing unit 250 can extract the merchant information included in the payment request information and the input information of the user. The merchant information may be a merchant number, a merchant ID (Merchant ID), or a payment terminal ID. The input information of the user includes information selected or directly written by the user through the service application for a predetermined item. For example, in the case of a card for settlement of a school expenses, user input information may include a name of a student, payment month (for example, a month or three months), a name, a representative, The user input information 450 can be implemented by a method of directly selecting an item to be described or output, and various items can be set according to a request for a merchant or a card for a payment according to a setting of an administrator.

The payment request information may include a token value corresponding to the amount of the payment card and the PAN value in addition to the merchant information and the input information of the user. The payment card according to an embodiment of the present invention is a prepaid card, and since the issuer or the merchant is specified in the card itself, the card itself includes the merchant information, the amount, and the token value. Therefore, non-face-to-face payment using a prepaid card is possible without a separate approval process. In other words, since payment and approval are made through the financial institution in the charging and purchasing procedure of the payment card, payment through the service server 200 is possible without involvement of the VAN company or the PG company in the non-face payment process.

The settlement processing unit 260 can process the settlement for the non-face-to-face settlement details made to the merchant terminal 130. The settlement processing unit 260 manages reports for each transaction, and can manage details of the interested parties (for example, transaction records for each merchant), settlement details (payment of merchant payment, refund payment, etc.). In an exemplary embodiment, the settlement processing unit 260 may arrange the non-face-to-face settlement details performed through the customer terminal 110 according to a method, such as a daily, monthly, or predetermined method so that the settlement can be viewed at the merchant terminal. Also, the merchant terminal can confirm (or approve) or cancel the non-face-to-face payment history received by the merchant terminal.

In one embodiment, the settlement processing unit 260 of the service server 200 can transmit the payment details to the payment terminal of the merchant (for example, a separate POS terminal or a merchant PC other than the merchant terminal 130) have. The merchant can confirm the non-face-to-face settlement details, the settlement details, and the settlement processing result provided by the service server 200 through the merchant terminal 130 as well as other terminals installed at the merchant.

As described above, the components 210 to 260 for performing non-face-to-face settlement include an affiliate store information storage medium 270 for storing and managing merchant store information, a customer information storage medium 280 for storing user information, Face settlement and settlement can be processed in conjunction with the non-face settlement < RTI ID = 0.0 > 290 < / RTI &

According to the present invention, a payment service can be implemented without the involvement of a payment gateway (PG) or a value added network (VAN) company by realizing a non-face-to-face payment using a prepaid electronic card, unlike the existing online payment. Also, even in the case of an offline store, there is no need to visit an affiliate shop to make a settlement at the time of non-face-to-face settlement, and there is no need to install a settlement terminal at an affiliate shop. In this way, the settlement commission can be reduced when there is no intermediary between PG and VAN, and since there is no installation and operation cost of the payment terminal, the economic benefit of the merchant can be maximized.

In addition, since the prepaid electronic card can be used to make non-face-to-face settlement even without visiting the offline merchant, the user convenience is improved. Also, according to the embodiment, it is possible to make settlement without complicated approval procedure or authentication procedure in non-face-to-face settlement, so that quick and convenient settlement can be realized.

3 is a flowchart illustrating a non-face-to-face transaction and a settlement procedure according to the first embodiment of the present invention. The service server 200 may issue a payment card in accordance with a contract with the merchant or a request (step 310). As described above, the payment card can be issued in the form of a flat-type prepaid card or a rechargeable prepaid card. The payment card may also include information about the expiration date (a specified time limit) and may be issued for one time or for one month (e.g., for payment in January 2017).

In one embodiment, the payment card includes card information for payment. If the payment card is a fixed amount, it includes the fixed amount. Further, the payment card may include at least one of a merchant name, a number, an identifier (ID), or a merchant phone number as merchant information. User information such as a user nickname or name may also be included, depending on whether it is an original name or a bearer name. Also, the management server of the present invention can issue card information in the form of a token value by implementing HCE-based mobile settlement. That is, the payment card can be issued including card information (token value), merchant information, amount information, and the like.

As the payment card used by a plurality of merchants is issued, the service server 200 can transmit the payment card in the form of a list. For example, the service server 200 can output a list of payment cards that can be purchased through a service application driven by the customer terminal 110.

In another embodiment, the service server 200 may provide a personalized list by analyzing the purchasing propensity or position of the user. As another embodiment, when requesting to issue a specific payment card from the merchant terminal 130, a payment card of a merchant requesting the customer terminal 110 in the form of a push notification or an SMS is popped up or linked to the customer terminal 110, As shown in FIG.

The customer terminal 110 may select a payment card to be purchased and purchase a payment card within the charged amount (step 320). In one embodiment, if the charged amount is less than the payment card amount, the charging application can guide the charging application to perform the charging process. After purchasing the payment card using the charge amount, the payment card can be displayed on the user's card list (see Fig. 4 (a)). The user can confirm that the purchased card is stored in the list, and perform non-face-to-face transaction using the card. As an example, in the case of a non-face-to-face transaction-only card, other menus (for example, offline payment, gift, etc.) other than the non-face-to-face transaction may be displayed in an inactive state.

The customer terminal 110 may input necessary user information or payment information according to the guidance of the service application (operation 330). As shown in FIG. 4 (b), in the input menu 450, necessary items can be entered or selected, and the inputted information can be confirmed in the next process. The information to be input by the user can be designated according to the request of the merchant, or the management server can designate the information according to the kind of the payment card. For example, in the case of a card for settlement of a school expenses, a payer name (or a nickname), a student name, a payment month, a discount code, and other memos may be input.

When the input of the user is completed, the input information can be confirmed, and the user can input the authentication information (e.g., PIN) after the confirmation (340, 350). In an embodiment, when the authentication information is a PIN, the PIN may be set by the user through the service application, or the PIN may be set to be non-face-only for payment. In another embodiment, the authentication information may include biometric authentication information, fingerprint information, facial recognition information, or iris recognition information. The authentication information may be implemented to perform one authentication, or to perform additional authentication by combining PIN and biometric authentication.

When the user completes the input of the authentication information, the customer terminal 110 generates payment request information to be transmitted to the service server 200 (step 360). The payment request information may include at least one of a token value of the payment card included in the payment card issuance, a token validity period, a token ID generated at each transaction of the token, money information, and merchant information (e.g. Also, when the payment request information has a field for recording a terminal ID value, the payment request information may be provided by the management server or may be replaced with a merchant number. The payment request information may also include a token value and a cryptogram. The Cryptogram is a value generated by using a payment key for payment data used at the time of payment, and the service server 200 performs verification of the cryptogram. At this time, the settlement key is stored in a security area where hacking is not possible, thereby preventing misuse by hacking or copying. In an embodiment, the payment key may be automatically discarded after a certain number of uses. In addition, the payment request information may include user input information. The user input information may be included in the payment request specialist or may be transmitted together with additional information.

In one embodiment, the payment request information may be configured according to the ISO 8583 message specification of the payment message, and the configuration values included in the message may be defined by the management server 200.

In one embodiment, the payment request information may be encrypted through an encryption process. The payment request information may be encrypted using a pre-stored encryption key or an encryption key that is issued in real time from the management server, and may transmit the encrypted payment request information to the service server 200. [

The service server 200 receives the settlement request information and decrypts the settlement request information if it is encrypted (step 370). The service server 200 can extract merchant information and user input information included in the payment request information. In step 375, the service server 200 can approve the payment request without approval or purchase by another financial institution, since it is an approval for the card that has already been purchased. However, in order to confirm whether the settlement is the settlement by the user, the authentication information stored in the service server 200 may be matched with the authentication information input at the time of transaction.

When the authentication information is confirmed, the service server 200 transmits the payment approval information to the customer terminal 110, and the customer terminal 110 can receive and confirm the payment approval information (steps 382 and 384).

Meanwhile, the service server 200 may transmit a notification message to the merchant terminal 130 to notify the occurrence of the non-face-to-face transaction at the time of payment approval. In one embodiment, the notification message may be transmitted in the form of SMS or in the form of a pop-up message upon execution of a service application. According to another embodiment, the merchant terminal 130 may be configured to receive notification on a daily basis, monthly, or the like without receiving a separate notification message according to the setting of the merchant terminal 130.

The merchant terminal 130 can confirm the payment approval information and browse the payment approval details. As described above, the service server 200 can be configured to transmit the collected payment details to the merchant terminal 130 or to transfer the collected payment details to another payment terminal (e.g., a POS terminal of a merchant or a merchant PC).

In one embodiment, the merchant can confirm the non-face-to-face transaction history through the merchant terminal 130 and determine whether to accept the transaction. The merchant terminal 130 can confirm the settlement approval details and select the acceptance or rejection. For example, if the amount or user information is erroneously settled or duplicated, the transaction can be canceled by refusing the purchase of the franchisee's stock price.

As another embodiment, the merchant terminal 130 may be configured to perform additional authentication procedures upon receipt. For example, when the payment approval information is notified, the service server 200 may transmit an approval message to the terminal of the merchant, and the approval message may include a one-time number or an authentication number. The merchant can implement the authentication number included in the approval message to process the argument for the payment. When the additional authentication is performed, the merchant's stock is subjected to the authentication process for the specific payment, so that the risk of the acquisition by the other person can be reduced.

The merchant terminal 130 can request issuance of the electronic receipt to the customer terminal 110 for the acquired transaction details and the service server 200 can receive the issuance request and issue the receipt to the customer terminal 110 (Steps 390 and 392). The receipt may be issued through a service application provided by the service server 200 or may be issued in the form of an SMS.

According to the non-facing payment system of the present invention, settlement at an offline merchant can be performed without a separate merchant payment terminal. In particular, in the case of a street vendor, which is difficult to use a payment terminal, it is possible to facilitate the spread of the electronic transaction service as the transaction history can be confirmed and acquired through the mobile phone possessed by the shop owner.

4 is a screen shot on the customer terminal 110 for explaining the settlement procedure of the non-facing payment system according to the first embodiment of the present invention. 4 (a) shows a screen for outputting a payment card purchased through a service application. For example, when the user purchases a 300,000-won flat-type card issued by a drawing and a school of art (merchant), the drawing and the art academy card 420 can be displayed on the screen 410 of the customer terminal 110 have. The list of remaining cards that the user has can also be displayed at the bottom. As an example, a gift, charge, and non-face-up transaction (settlement) menu may be displayed for the Drawing and AI Art Academy cards. At this time, if the card is a non-face-to-face transaction card, the remaining menu (gift and charge) may be displayed in a disabled state and the non-face-to-face transaction menu 430 may be displayed in an activated form.

When the user selects the non-face-to-face transaction menu 430, the non-face-to-face transaction (payment) procedure is started through data transmission / reception with the service server 200 (FIG. The service server 200 may output the guidance page 440 in response to the non-face-to-face transaction request. The user can confirm the card information and the information to be input displayed on the customer terminal 110, and input the information. The user input information 450 may be directly written or selected in a form of selecting the item.

The service server 200 guides the page 460 for inputting the authentication information when the user presses the OK button after completing the input (FIG. 4 (c)). In one embodiment, the non-face-to-face settlement details 470 can be confirmed before the authentication information is input, and the user can input the authentication information (PIN, 480) after confirming the contents. When the user inputs the authentication information, the customer terminal 110 generates the payment request information using the information of the payment card and the input information. In an embodiment, the customer terminal 110 may implement a payment request information generation procedure to be performed by a separate security application or may encrypt the generated payment request information to improve security.

5 is a screen shot on the merchant terminal for explaining the settlement process of the non-facing payment system according to the first embodiment of the present invention. In one embodiment, a settlement approval notification message may be received on the merchant terminal 130 when the non-face settlement is completed. For example, as shown in FIG. 5 (a), in the form of an SMS message 510. However, the present invention is not limited to this, and it is possible to notify a transaction approval in various forms such as a push message or an application icon notification.

As another embodiment, the transaction notification may be transmitted to the merchant terminal 130 in the form of a bar code or a QR code after the transaction is approved. The service server 200 can transmit the transaction information to the merchant terminal in the form of a two-dimensional code after the approval of the non-face-to-face transaction, and the merchant dealer can receive the transaction information and transmit the transaction information to the merchant terminal 130 or another payment terminal (POS terminal, Code scanner, or the like) to look up the payment history.

When the service application is executed through the merchant's stock merchant terminal 130, the approval details of the non-face-to-face transaction can be confirmed (FIG. 5 (b)). In one embodiment, the non-face-to-face transaction history can be viewed only through a terminal owned by a merchant main account or a person having an administrator account, and the transaction details can be read through a separate authentication procedure (PIN or biometric authentication) It can also be implemented.

The merchant's stock can confirm the transaction approval list 530 through the merchant terminal 130 and can confirm the details of the settlement (acquisition), the details of the reservation waiting for the settlement, and the details of the cancellation (rejection of the acceptance). It is possible to select whether or not to accept a transaction with respect to the history 530 to be acquired. As an example, if the transaction is accepted, the settlement is marked as completed and the electronic receipt sending menu 540 can be output (FIG. 5 (c)).

The merchant may request the service server 200 to issue the electronic receipt by selecting the electronic receipt issuance 550 and may output the electronic receipt to the customer terminal 110 through the management server or a separate receipt issuing server.

By implementing this non-face-to-face transaction service, it is possible to reduce the hassle of existing online and offline transactions, thereby providing convenience to merchant operators and users. In particular, since the merchant does not need to install a payment terminal and does not need a purchase transaction procedure, it does not need to go through a VAN company or a PG company, thereby significantly reducing the transaction fee.

Hereinafter, a second embodiment for performing non-face-to-face settlement using a credit card or a card for which a commodity is not specified, unlike the first embodiment, will be mainly described. In one embodiment, the merchant or the card for which the merchandise is not specified may be a prepaid card issued by the service server 200 for use at one or more merchants, a credit card, a check card, or a debit card issued by another organization And a payment means of the form.

FIG. 6 is a block diagram illustrating a configuration of a service server 200 of a non-facing payment system according to a second embodiment of the present invention. The second embodiment relates to an embodiment of a non-facing payment method based on a mobile payment application provided by a financial institution (for example, a credit card company). The service server 200 itself performs payment approval, ) In order to process payment approval. For example, when a card issued by the service server 200 is used, transaction approval and settlement procedures can be performed through the service server 200 as described with reference to FIG. Meanwhile, when the card issued by the financial company server 300 is used, the financial company server 300 can process transaction approval and settlement through the service server 200. In addition, the second embodiment is an embodiment in which payment is performed using a basic card (for example, the Basic Card shown in Fig. 10), which is a card for which merchant information and / or merchandise information Examples include.

2, the service server 200 includes an information transmitting and receiving unit 210 for transmitting and receiving information from other devices, an application managing unit 220 for managing a service application, a card information managing unit 230 for issuing and managing a card A merchant information storage medium 270 and a customer information storage medium 280. The merchant information storage medium 270 includes a transaction information processing unit 250 and a settlement management unit 260. The merchant information storage medium 270, , And a card information storage medium (290). In addition, the components 210 to 260 of the service server 200 can process and settle the non-face settlement using information stored in the storage media 270 to 290. Also, the service server 200 may be implemented as a platform configured by a plurality of servers, and each of the components 210 to 190 may be implemented as a server or a database. Also, the service server 200 is not limited to the illustrated components, and the service server 200 may further include various components for non-face settlement implementation.

The financial company server 300 refers to a server that can be interlocked with the service server 200, and in this embodiment, a subject issuing a payment card used for non-face-to-face settlement. For example, when non-face-to-face settlement is performed using a credit card of an A-card company, the A-card company serves as a financial company server 300 and can perform non-face-to-face settlement through a service application in cooperation with the service server 200 have. The financial company server 300 includes a transaction approval unit 320 for determining whether a transaction has been approved or not, a transaction settlement unit 330 for calculating a transaction for each predetermined period, a user information storage medium 340 for storing user information, And a card information storage medium 350 for storing card information to be managed.

In one embodiment, when the customer terminal 110 selects a payment card issued by the financial company server 300 and performs non-face-to-face payment, the service server 200 transmits payment request information from the customer terminal 110 And transmits it to the financial company server 300 to process the payment approval or not. As another example, the financial company server 300 may receive the settlement request message directly from the customer terminal 110 and directly transmit the approval result to the customer terminal 110. Thereafter, the financial company server 300 purchases the sales slip of the merchant at a predefined period (for example, every month), pays the merchant for the merchandise, and charges the customer.

In a case where a card issued by the service server 200 is used, the transaction processing unit 250 processes the transaction using the process described in the first embodiment and does not interfere with the financial company server 300, Can be implemented to perform settlement. In the first embodiment, although the payment card itself is a state in which the merchant and the merchandise are specified, in the second embodiment, any card (for example, a basic card or a Basic Card) In this case, the settlement can be implemented through the process of specifying the merchant and payment information through the service application.

When the transaction is completed, the service server 200 or the financial company server 300 may issue an electronic receipt to the customer terminal. In one embodiment, the issuer issuing the payment card can issue an electronic receipt.

7 is a flowchart illustrating a non-face settlement and settlement procedure according to the second embodiment of the present invention. The second embodiment mainly focuses on an embodiment of a non-facing payment method based on a mobile payment application provided by a financial institution (for example, a credit card company). The service server 200 can issue a payment card available at one or more merchants, while a payment card issued by the financial company server 300 can also be issued or available through a service application. In addition, the payment card may contain information on the expiration date (designated time limit) and may be issued for disposable or rechargeable purposes.

In one embodiment, the payment card includes card information for payment. If the payment card is a fixed amount, it includes the fixed amount. Further, the payment card may include at least one of a merchant name, a number, an identifier (ID), or a merchant phone number as merchant information. User information such as a user nickname or name may also be included, depending on whether it is an original name or a bearer name. Also, the management server of the present invention can issue card information in the form of a token value by implementing HCE-based mobile settlement. That is, the payment card can be issued including card information (token value), merchant information, amount information, and the like. As an embodiment, a separate token value may be issued to the card issued through the financial institution 300 to provide it in the form of an HCE card.

As the payment card used by a plurality of merchants is issued, the service server 200 can transmit the payment card in the form of a list. For example, the service server 200 can output a list of payment cards that can be purchased through a service application driven by the customer terminal 110.

In another embodiment, the service server 200 may provide a personalized list by analyzing the purchasing propensity or position of the user. As another embodiment, when requesting to issue a specific payment card from the merchant terminal 130, a payment card of a merchant requesting the customer terminal 110 in the form of a push notification or an SMS is popped up or linked to the customer terminal 110, As shown in FIG.

The customer terminal 110 may select a payment card to be purchased and may select a non-face-to-face payment menu (steps 710 and 720). In this embodiment, a case where the payment card is a basic card (a Basic Card in which a merchant and a product are not specified) or a payment card (e.g., a credit card or a check card) provided by another financial company is mainly described. As an example, in the case of a non-face-to-face transaction-only card, other menus (for example, offline payment, gift, etc.) other than the non-face-to-face transaction may be displayed in an inactive state.

The customer terminal 110 may select a card for non-face-to-face settlement and then specify the merchant or the merchandise (step 730). As shown in FIG. 8 (b), the customer terminal 110 can search for a merchant registered in the service server 200 through the merchant search. Further, when the customer terminal 110 is located at an affiliate shop, the affiliate shop information can be obtained by recognizing a code (for example, a bar code or a QR code) containing the shop information. Alternatively, the customer terminal 110 may select among the pre-stored merchants or use the GPS to find the location of the merchant. In one embodiment, the customer terminal 110 may obtain merchant information (e.g., Merchant ID) through merchant search.

The customer terminal 110 acquires a shop ID (e.g., Merchant ID) to be used for the settlement request information by performing the merchant selection step. 8 and 9, when a mobile payment application provided by a financial institution (for example, a credit card company) is used, when the service server 200 selects an affiliated store or a general affiliated merchant store provided by the service server 200, Can be provided from different servers. For example, in the case of selecting a merchant registered in the service server 200 (e.g., a Kona affiliate merchant in FIG. 8B), the merchant ID can be obtained from the service server 200 (Step 734). As another example, if the general merchant is searched or selected, the shop ID can be acquired from the PG company, VAN company or financial institution (e.g., credit card company) server 300 that manages the general merchant shop (step 732).

10 and 11, even when the service application provided by the service server 200 is used, the shop ID is provided according to whether the shop is registered in the general merchant shop or the service server 200 The server you are using may be different. For example, when the service server 200 selects a merchant registered in the service server 200 through the service application provided by the service server 200, the service server 200 transmits the service to the customer terminal 110, Lt; RTI ID = 0.0 > ID < / RTI > As another example, when a service application is used, but a merchant is selected using a card registered in the service application or a card of another financial company 300, the general merchant receives the merchant ID from the VAN company or the financial company server 300, The merchant registered in the service server 200 can receive the merchant ID from the service server 200. [

As another example, when the service server 200 manages the shop IDs for the general merchants or the merchants registered in the service server 200, the service server 200 can provide the shop IDs when the merchant shop is selected . If there is another brokerage server that manages the shop ID such as a PG company or a VAN company, the brokerage server may provide the shop ID to the customer terminal 110.

The configuration of transmitting the merchant ID through the service server 200 or the financial company server 300 has been described through the embodiments described above. However, the present invention is not limited to this, The terminal, the user terminal, or the other server).

Next, the customer terminal 110 can select one of the offered products when a plurality of products are registered at the selected merchant (see (c) of FIG. 8). As another example, the customer terminal 110 can implement payment so that only the amount to be purchased (to be paid) is entered without selecting a separate product (refer to FIG. 10C).

The customer terminal 110 may input necessary user information or payment information according to the guidance of the service application (step 730). The customer terminal 110 can input necessary items or select among the presented items, and the inputted information can be confirmed in the next process. The information to be input by the user can be specified according to the request of the merchant, or can be designated by the service server according to the type of the payment card or product. For example, in the case of a card for settlement of a school expenses, a payer name (or a nickname), a student name, a payment month, a discount code, and other memos may be input.

When the input of the user is completed, the input information can be confirmed. Optionally, the user may further enter authentication information (e.g., PIN) after verification (steps 750, 760). In an embodiment, when the authentication information is a PIN, the PIN may be set by the user through the service application, or the PIN may be set to be non-face-only for payment. In another embodiment, the authentication information may include biometric authentication information, fingerprint information, facial recognition information, or iris recognition information. The authentication information may be implemented to perform one authentication, or to perform additional authentication by combining PIN and biometric authentication.

When the user completes the input of the authentication information, the customer terminal 110 generates payment request information to be transmitted to the service server 200 (step 770). The payment request information may include at least one of a token value of the payment card included in the payment card issuance, a token validity period, a token ID generated at each transaction of the token, money information, and merchant information (e.g. Also, when the payment request information has a field for recording a terminal ID value, it may be replaced by a service server or a merchant number. The payment request information may also include a token value and a cryptogram. The Cryptogram is a value generated by using a payment key for payment data used at the time of payment, and the service server 200 performs verification of the cryptogram. At this time, the settlement key is stored in a security area where hacking is not possible, thereby preventing misuse by hacking or copying. In an embodiment, the payment key may be automatically discarded after a certain number of uses. In addition, the payment request information may include user input information. The user input information may be included in the payment request specialist or may be transmitted together with additional information.

In one embodiment, the payment request information may be configured according to the ISO 8583 message specification of the payment message, and the configuration values included in the message may be defined by the management server 200.

In one embodiment, the payment request information may be encrypted through an encryption process. The payment request information may be encrypted using a pre-stored encryption key or an encryption key that is issued in real time from the service server, and may transmit the encrypted payment request information to the service server 200. [

The service server 200 receives payment request information and determines whether to approve the transaction by interworking with the financial company server 300 (steps 780 to 790). In one embodiment, the service server 200 acts as a mediating server, receives settlement request information, and transmits a transaction approval request message to the issuer's financial company server 300 according to card issuer information (785 step). The financial company server 300 may determine whether to approve or reject the transaction according to a predefined criterion, and approve the settlement when the transaction approval condition is satisfied. When the transaction is approved, the transaction result may be transmitted to the service server 200 and the customer terminal 110. In addition, it can be implemented to notify the merchant terminal 130 of the approval result.

As another example, the financial company server 300 may receive the transaction approval request message 785 directly from the customer terminal 110 without going through the service server 200. Also in this case, it is determined whether or not the transaction is approved and the transaction approval result is notified to the customer terminal 110, the merchant terminal 130 or the service server 200.

In one embodiment, the payment request information may be decrypted if the transaction request information is encrypted). The service server 200 or the financial company server 300 may extract the merchant information and user input information included in the payment request information. Also, in order to confirm whether or not the settlement by the user is truly performed, the authentication information stored in the service server 200 may be matched with the authentication information input at the time of transaction. When the authentication information is confirmed, the service server 200 or the financial company server 300 transmits the payment approval information to the customer terminal 110, and the customer terminal 110 can receive and confirm the payment approval information through the service application.

Meanwhile, the service server 200 may transmit a notification message to the merchant terminal 130 to notify the occurrence of the non-face-to-face transaction at the time of payment approval. In one embodiment, the notification message may be transmitted in the form of SMS or in the form of a pop-up message upon execution of a service application. According to another embodiment, the merchant terminal 130 may be configured to receive notification on a daily basis, monthly, or the like without receiving a separate notification message according to the setting of the merchant terminal 130. The merchant terminal 130 can confirm the payment approval information and browse the payment approval details. As described above, the service server 200 can be configured to transmit the collected payment details to the merchant terminal 130 or to transfer the collected payment details to another payment terminal (e.g., a POS terminal of a merchant or a merchant PC).

In one embodiment, the merchant can confirm the non-face-to-face transaction history through the merchant terminal 130 and determine whether to accept the transaction. The merchant terminal 130 can confirm the settlement approval details and select the acceptance or rejection. For example, if the amount or user information is erroneously settled or duplicated, the transaction can be canceled by refusing the purchase of the franchisee's stock price.

As another embodiment, the merchant terminal 130 may be configured to perform additional authentication procedures upon receipt. For example, when the payment approval information is notified, the service server 200 may transmit an approval message to the terminal of the merchant, and the approval message may include a one-time number or an authentication number. The merchant can implement the authentication number included in the approval message to process the argument for the payment. When the additional authentication is performed, the merchant's stock is subjected to the authentication process for the specific payment, so that the risk of the acquisition by the other person can be reduced.

The customer terminal 110 or the merchant terminal 130 may request issuance of the electronic receipt for the transaction details that have been completed. Electronic receipts can be issued by transaction approvers. For example, the service server 200 may receive the issuance request and issue a receipt to the customer terminal 110 (step 796). The electronic receipt may be issued through a service application provided by the service server 200 or may be issued in the form of an SMS.

In one embodiment, the financial institution server 300 may process the settlement of accounts at a predefined period (or period) (step 798). The financial company server 300 can perform settlement so as to pay the merchant for the settlement breakdown occurred with respect to the specific merchant shop and charge the user to the money. In the case where the non-face settlement is used through the basic card issued by the service server 200, the service server 200 can be settled in a predetermined period or period as a subject of settlement.

According to the non-facing payment system of the present invention, settlement at an offline merchant can be performed without a separate merchant payment terminal. Particularly, in the case of a non-store street vendor which is difficult to use a payment terminal, it is possible to facilitate the spread of the electronic transaction service as the transaction history can be confirmed and acquired through the mobile phone possessed by the shop owner.

8 and 9 are screen shots on a customer terminal for explaining a settlement procedure of the non-facing settlement system according to the second embodiment of the present invention. The non-face settlement method based on the mobile settlement application provided by the financial company server 300 . 10 and 11 are screen shots illustrating a non-face settlement proceeding procedure according to another embodiment of the present invention, and are related to a non-face settlement method based on a mobile settlement application provided by the service server 200. [

In one embodiment, the customer terminal 110 can check a list of cards held or registered by the service application provided by the financial company server 300 (see FIG. 8A)). For example, the customer terminal 110 may have various types of payment cards such as a credit card, a credit card, and the like, which are issued through a merchant (store) and a prepaid card or a financial company designated with an amount. For example, if a non-face-to-face payment is to be made using a credit card called a "national happiness card", the customer can select the non-face-to-face payment menu 830 after selecting the "national happiness card" 820. In the first embodiment, since payment is performed at the time of selecting the non-face-to-face settlement menu because the merchant and amount information are predetermined, in the second embodiment, since the amount of money with the merchant is not determined in the second embodiment, (Fig. 8 (b), (c)).

As another embodiment, a basic card 1020 provided by the service server 200 may be used in addition to a card provided by a financial institution (see FIG. 10A). The basic card can be implemented as a prepaid card or a rechargeable card, and can be set to be issued by the service server 200 so that the merchant, the commodity, and the amount of money can be settled at various merchant points without being specified.

As an example, the service application of the customer terminal 110 may guide the merchant selection pages 840 and 1040 after card selection (FIG. 8B or FIG. 10B). The merchant selection is for identifying merchant information by acquiring merchant information (e.g., Merchant ID), and may be implemented in various ways such as merchant search, scan, favorite search, and search by location. At this time, the franchisee can be searched in the franchisee registered in the service server 200. The merchant search can be implemented to search through some of the merchant information such as a shop name, a telephone number, or an address. Merchant point scan refers to acquiring the merchant information by recognizing the merchant store information code (for example, bar code or QR code) provided at the merchant store when the customer terminal 110 performs non-face settlement in the merchant store or near the merchant store. Even if it is not installed at an affiliate shop, a merchant shop can be scanned through a leaflet, a billboard, a guide page, a mobile terminal, a merchant code provided by a PC, or a number scan. My franchisee can register a favorite franchisee as a favorite franchisee so that quick selection is possible. In addition, it is possible to use the current position of the customer terminal using the GPS or to specify the franchisee through the map using the franchise location.

In one embodiment, the customer terminal 110 may set and output a priority among various merchant selection methods, or may set the priority order so that only the highest priority method is output first. For example, if the customer mainly uses non-face-to-face payment for the payment of the school expenses of "Painting and Eye Art Academy", only My merchant menu or "Painting and Eye Art School" can be displayed to display first as merchant. In the case where the basic merchant is registered in advance, the non-face settlement can be implemented without outputting the merchant selection page 840. [

The customer terminal 110 acquires a shop ID (e.g., Merchant ID) to be used for the settlement request information by performing the merchant selection step. 8 and 9, when a mobile payment application provided by a financial institution (for example, a credit card company) is used, the merchant 860 provided by the service server 200 or the general affiliate merchant 850 ), Store IDs can be provided from different servers. For example, when selecting a merchant registered in the service server 200 (for example, the Kona affiliate merchant 860 in FIG. 8B), the shop ID can be obtained from the service server 200. As another example, when the general merchant shop 850 is searched or selected, the shop ID can be acquired from the PG company, VAN company or financial institution (e.g., credit card company) server 300 that manages the general merchant shop.

10 and 11, even when the service application provided by the service server 200 is used, the shop ID is provided according to whether the shop is registered in the general merchant shop or the service server 200 The server you are using may be different. For example, when the service server 200 selects a merchant registered in the service server 200 through the service application provided by the service server 200, the service server 200 transmits the service to the customer terminal 110, Lt; RTI ID = 0.0 > ID < / RTI > As another example, when a service application is used, but a merchant is selected using a card registered in the service application or a card of another financial company 300, the general merchant receives the merchant ID from the VAN company or the financial company server 300, The merchant registered in the service server 200 can receive the merchant ID from the service server 200. [

As another example, when the service server 200 manages the shop IDs for the general merchants or the merchants registered in the service server 200, the service server 200 can provide the shop IDs when the merchant shop is selected . If there is another brokerage server that manages the shop ID such as a PG company or a VAN company, the brokerage server may provide the shop ID to the customer terminal 110.

The customer terminal 110 can specify the merchandise or the payment amount after selecting the merchant to perform the non-face settlement (FIG. 8 (c) or FIG. 10 (c)). 8 (c), the customer terminal 110 may select a coffee bean service point as an affiliate shop, and then input goods or money to be paid to the affiliate shop (870). The customer terminal 110 can designate only the amount of money without selecting a separate product (870). For example, after selecting an affiliate shop from the previous page 840, the user can enter the amount to be paid and proceed with the settlement. The service application can be configured to receive input directly from the keypad when inputting the amount, or to output and select items such as 5000 won and 10000 won.

10 (c), when the customer terminal 110 selects a drawing and a school of art as a merchant, the merchant ID is acquired from the service server 200, and the merchandise registered in the merchant (1060). For example, the franchisee can hold a commodity called a fine arts one-month ticket and a medium-art fine one-month ticket, and if the corresponding commodity is not available, the customer can display a free commodity for directly inputting the amount. The user can select one of the items displayed on the customer terminal 110 and perform settlement.

After specifying the card, merchant and merchandise (or amount) as described in FIGS. 8 and 10, the user can confirm the selection and proceed with the non-face-to-face payment (see FIGS. 9 and 11). The customer terminal 110 can confirm the selected card, merchant, and merchandise details (910, 1070) as shown in FIGS. 9 and 11 (a). Optionally, when the authentication information needs to be input, the authentication information can be input according to the guidance of the service application (Figs. 9 and 11 (b)). The authentication information may be PIN number input, fingerprint authentication, other biometric authentication or additional authentication via other authentication means (e.g., IPIN). The customer terminal 110 may transmit settlement request information to the service server 200 or the financial company server 300 when receiving the settlement information and authentication information, and may receive the transaction approval result.

In one embodiment, when the service server 200 issues an electronic receipt, electronic receipts 960 and 1130 may be issued to the customer terminal 110 after payment is completed. The electronic receipts 960 and 1130 may be received through a service application or in the form of separate messages such as SMS.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is to be understood that the invention is not limited to the disclosed embodiments, but, on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims. Accordingly, the true scope of the present invention should be determined by the technical idea of the appended claims.

100: Non-facing payment system 110: Customer terminal
130: Merchant terminal 200: Service server
300: Financial company server 400: Affiliate server
210: information transmitting / receiving unit 220:
230: Card information management unit 240: Card information issuing unit
250: transaction processing unit 260: settlement management unit
270: Merchant store information storage medium 280: Customer information storage medium
290: Card information storage medium

Claims (19)

A non-facing payment method performed by a service server that provides non-face-to-face transaction services,
Issuing, to the customer terminal, a payment card issued by the financial company server or the service server, including the specific merchant information;
Publishing the payment card through a service application running on the customer terminal;
When the customer terminal performs non-face-to-face settlement with the specific merchant using the settlement card, the customer terminal does not communicate with the specific merchant shop and includes the specific merchant shop information read out from the payment card previously issued Receiving the generated payment request information; And
Acquiring merchant information on which settlement is performed using the settlement request information, and processing payment approval without communicating with the specific merchant;
Wherein the payment request information includes the token value of the payment card and the payment amount information, and further comprises user input information or authentication information. The method according to claim 1,
The issuing of the payment card may include generating and storing a token value that is virtual payment information corresponding to a PAN (Primary Account Number) value of the payment card,
Wherein the payment card is issued to include at least one of the token value, the card amount, and the validity period. The method according to claim 1,
Wherein the payment card is a prepaid card and is issued in a flat type or a chargeable type. The method according to claim 1,
Wherein the payment card includes a card which is issued by the service server and which can be paid for a specific commodity for the specific merchant or a card capable of paying a specific amount for the specific merchant. 5. The method of claim 4,
The payment card includes a token value which is virtual payment information corresponding to the PAN value of the payment card,
Wherein the payment request information is generated so as to include price information or merchandise information together with merchant information read from the customer terminal after selecting the payment card. The method according to claim 1,
Wherein the publishing step posts at least one card issued for each merchant in a list or recommendation form according to a predetermined criterion. The method according to claim 1,
Wherein the settlement request information further includes a cryptogram value generated by using a settlement key generated for each transaction. The method according to claim 1,
Wherein the step of processing the payment approval comprises comparing the information stored in the service server with the information included in the payment request information and approving the payment if the information matches the predetermined criteria, Payment Method. The method according to claim 1,
Transmitting payment approval details to the merchant terminal after the payment approval processing; And
Further comprising the step of receiving, from the merchant terminal, whether to accept or reject the payment approval details. 10. The method of claim 9,
Outputting an electronic receipt issuing menu for the received payment approval details;
Receiving an electronic receipt issuing request message from the merchant terminal; And
Further comprising the step of issuing and transmitting an electronic receipt to the customer terminal for the settlement approval history of receiving the request message. 10. The method of claim 9,
The step of transmitting the payment approval details may be performed by a payment terminal installed at an affiliated store or a computer (PC)
Wherein the payment terminal comprises a point of sale (POS) terminal or a credit authorization terminal (CAT) terminal. As a non-facing payment service server that implements a non-facing payment service,
A card information issuing unit for issuing a payment card including specific merchant information for non-face-to-face settlement and posting the payment card through a service application running on the customer terminal;
When the non-face settlement is performed for the specific merchant, receiving the settlement request information including the specific merchant point information read from the payment card previously issued from the customer terminal without communicating with the specific merchant, And a transaction processor for acquiring merchant information on which settlement is performed using the settlement request information and processing payment approval,
Wherein the payment request information includes the token value of the payment card and the payment amount information, and further comprises user input information or authentication information. 13. The method of claim 12,
The card information issuing unit generates and stores a token value which is virtual payment information corresponding to the PAN value of the payment card,
Wherein the payment card is issued to include at least one of the token value, the card amount, and the validity period. 13. The method of claim 12,
Wherein the payment card is a prepaid card and is issued in a flat type or a chargeable type. 13. The method of claim 12,
Wherein the payment card includes a card which can be issued by the service server and can be paid for a specific commodity for the specific merchant, or a card capable of paying a specific amount for a specific merchant. 16. The method of claim 15,
The payment card includes a token value which is virtual payment information corresponding to the PAN value of the payment card,
Wherein the payment request information is generated so as to include price information or product information together with merchant information read from the customer terminal after selecting the payment card. 13. The method of claim 12,
Wherein the settlement request information further includes a cryptogram value generated by using the settlement key generated for each transaction. As a non-facing payment system,
Face payment to a specific merchant through the service application, performs non-face-to-face settlement with the merchant, and transmits the settlement request information including the specific merchant information read from the payment card without communicating with the specific merchant And transmits a payment request message to the service server; And
The service application may be provided to issue the payment card including the specific merchant information, receive the payment request information from the customer terminal when performing non-face-to-face payment, use the merchant information included in the payment request information And a service server for processing whether or not to approve the payment,
Wherein the payment request information includes the token value of the payment card and the payment amount information, and further comprises user input information or authentication information. delete

Images