KR20230137036A - Method and system for proxy payment - Google Patents

Abstract

The proxy payment method according to an embodiment of the present invention is a proxy payment method in which a requester terminal requesting a proxy payment is performed in conjunction with a payer terminal paying for the requested proxy payment, and the proxy payment for the product is performed. requesting step; waiting for a response to the request; And when the response is received, proceeding with the proxy payment; requesting proxy payment for the product includes providing a proxy payment request window for entering proxy payer information for requesting the proxy payment. A step of generating proxy payment request information based on a user input based on the provided proxy payment request window, and providing a proxy payment window or conditional approval window based on the generated proxy payment request information to the payer terminal. do.

Description

Proxy payment method and system {METHOD AND SYSTEM FOR PROXY PAYMENT}

The present invention relates to a proxy payment method and system. More specifically, it relates to a method and system for requesting and performing proxy payment using a communication network.

Recently, with the development of electronic and IT technology, payment methods for purchasing products or services have been diversifying.

After purchasing a product or service at an online and/or offline store, consumers can pay for the purchase using not only cash but also various cards such as credit cards, debit cards, and cash cards.

Additionally, consumers can purchase and pay for products or services online and/or offline through various e-commerce means.

In particular, in recent years, various mobile simple payment services that allow payments to be made using mobile devices such as smartphones have emerged and are being commercialized.

Although consumer payments have become more convenient under the various electronic financial systems or e-commerce systems that are developing in this way, there are still many inconveniences in the consignment purchase of products or services or the process of proxy payment by the consignee, and technological development for this is insufficient.

In this regard, the prior document, Korean Patent Publication No. 2020-0124397, provides a proxy payment service method in which a consumer can request proxy payment from a third party, and the proxy payment trustee can immediately complete payment for the proxy payment request. It is starting.

However, in the conventional case, it is not easy to use when proxy payment is required for purchasing products or services at offline stores.

In addition, in this field of technology, there are no measures in place to prevent cases that cause abusing issues, such as attempts to obtain unfair profits by abusing proxy payment services.

In addition, there is a lack of technological introduction to effectively support situations that require proxy payments for multiple trustees, which makes it difficult to implement services of more practical value, such as split payments for products or services by multiple trustees. I can't do it.

Therefore, it is necessary to develop and introduce a new system to overcome these conventional problems and limitations.

KR 10-2020-0124397 A

The present invention was created to solve the problems described above, and its purpose is to provide a method and system for requesting and performing proxy payment using a communication network.

In detail, the present invention provides a proxy payment system where, even if the proxy payment requester and proxy payer are located remotely from each other, the requester can request proxy payment from the payer and the payer can perform payment for the requested proxy payment. We would like to provide a method and system.

In addition, the present invention seeks to provide a proxy payment method and system including a proxy payment function that can be implemented not only online but also offline.

In addition, the present invention seeks to provide a proxy payment method and system that prevents situations that cause abusing issues, such as attempts to obtain unfair profits by abusing the proxy payment service.

Additionally, the present invention seeks to provide a proxy payment method and system including a split proxy payment function by multiple payers.

In addition, the present invention seeks to provide a proxy payment method and system in which a payer can conditionally allow proxy payments.

However, the technical problems to be achieved by the present invention and embodiments of the present invention are not limited to the technical problems described above, and other technical problems may exist.

The proxy payment method according to an embodiment of the present invention is a proxy payment method in which a requester terminal requesting a proxy payment is performed in conjunction with a payer terminal paying for the requested proxy payment, and the proxy payment for the product is performed. requesting step; waiting for a response to the request; And when the response is received, proceeding with the proxy payment; requesting proxy payment for the product includes providing a proxy payment request window for entering proxy payer information for requesting the proxy payment. A step of generating proxy payment request information based on a user input based on the provided proxy payment request window, and providing a proxy payment window or conditional approval window based on the generated proxy payment request information to the payer terminal. do.

At this time, the proxy payment window is a user interface that determines whether to accept the proxy payment.

Additionally, the conditional approval window is a user interface that determines acceptance conditions for the proxy payment.

Additionally, the conditional approval window determines at least one condition of amount, number of uses, time, place, and product for allowing the proxy payment based on a user input based on the conditional approval window.

In addition, the step of requesting proxy payment for the product includes providing an abusing blocking function that blocks the proxy payment when at least one of a product, affiliated store, and user set in the proxy payment request information is detected.

Additionally, the step of waiting for a response to the request includes providing a waiting screen window that displays proxy payment validity time information and progress information.

Additionally, providing the standby screen window includes providing at least one interface of a proxy payment re-request button and a proxy payment request cancellation button.

In addition, the step of performing the proxy payment includes receiving an acceptance response to the proxy payment based on a user input based on the proxy payment window or the conditional approval window, and linking with the payer terminal when the acceptance response is received. It includes the step of executing a payment process for the product.

In addition, the step of requesting proxy payment for the product further includes providing the proxy payment window or conditional approval window to the plurality of payer terminals.

In addition, the step of performing the proxy payment further includes executing a payment process for the product in conjunction with the plurality of payer terminals when the acceptance response is received from all of the plurality of payer terminals.

In addition, the step of requesting proxy payment for the product further includes requesting the plurality of payer terminals to split the proxy payment amount for the product according to a predetermined method.

In addition, the step of performing the proxy payment includes receiving an acceptance response to the proxy payment based on a user input based on the proxy payment window or the conditional approval window, and when the acceptance response is received, payment according to the user input. It includes providing a temporary payment code that executes the function.

Meanwhile, a proxy payment system according to an embodiment of the present invention includes at least one memory storing a proxy payment application; and at least one processor that reads the proxy payment application stored in the memory and performs a proxy payment method, wherein instructions of the proxy payment application include requesting proxy payment for a product, and a response to the request. A step of waiting, a step of performing the proxy payment when the response is received, a step of providing a proxy payment request window for entering proxy payer information to request the proxy payment, and based on the provided proxy payment request window It includes instructions for generating proxy payment request information based on user input and providing a proxy payment window or conditional approval window based on the generated proxy payment request information to the payer terminal.

On the other hand, the payment service providing server according to an embodiment of the present invention includes at least one memory module; and at least one processor module; wherein the processor module requests proxy payment for a product, waits for a response to the request, and when the response is received, proceeds with the proxy payment, and performs the proxy payment. Providing a proxy payment request window to the requester terminal to input the proxy payment request information to be requested, generating proxy payment request information based on user input based on the provided proxy payment request window, and creating a proxy payment window based on the generated proxy payment request information. Alternatively, a conditional approval window is provided to the payer terminal.

In the proxy payment method and system according to an embodiment of the present invention, even if the proxy payment requester and proxy payer are located remotely from each other, the requester can request proxy payment from the payer, and the payer can respond to the requested proxy payment. By being able to perform payment, you can easily represent the desired payer without restrictions on time and place in various situations where proxy payment is required (e.g., absence of payment method, lack of payment amount, business necessity, and/or simple request, etc.) It has the effect of providing an environment and user interface (UI) that allows payers who request payment and receive the request to easily and conveniently make proxy payments.

In addition, the proxy payment method and system according to an embodiment of the present invention provide a proxy payment function that can be implemented not only online but also offline, so that the proxy payment service can be used in any way without restrictions depending on the online or offline environment. There is an effect that can be supported.

In addition, the proxy payment method and system according to an embodiment of the present invention are safer and more just by preventing situations that cause abusing issues such as attempts to gain unfair advantage by abusing the proxy payment service. It has the effect of establishing and providing a proxy payment service environment.

In addition, the proxy payment method and system according to an embodiment of the present invention provides a split proxy payment function by multiple payers, thereby expanding the scope of use of the proxy payment function and simultaneously making proxy payments by multiple payers. It is possible to provide various types of split payment functions using the advantages of , and it also has the effect of offsetting the burden on proxy payers.

In addition, the proxy payment method and system according to an embodiment of the present invention allow the payer to conditionally allow proxy payment, thereby minimizing the side effects of indiscriminate proxy payment and also reflecting the payer's intention in detail so that both the requester and the payer can It has the effect of implementing a satisfactory proxy payment service.

However, the effects that can be obtained from the present invention are not limited to the effects mentioned above, and other effects not mentioned can be clearly understood from the description below.

1 is a conceptual diagram of a proxy payment system according to an embodiment of the present invention.
Figure 2 is an internal block diagram of a terminal according to an embodiment of the present invention.
Figure 3 is an internal block diagram of a payment service providing server according to an embodiment of the present invention.
Figure 4 is a processing flowchart for explaining a proxy payment method according to an embodiment of the present invention.
Figure 5 is an example of a drawing for explaining a payment bridge page according to an embodiment of the present invention.
Figure 6 is a processing flowchart illustrating a 1:1 proxy payment process according to an embodiment of the present invention.
Figure 7 is an example of a diagram for explaining a proxy payment request window according to an embodiment of the present invention.
Figure 8 is an example of a drawing for explaining a standby screen window according to an embodiment of the present invention.
9 to 11 are examples of drawings for explaining a proxy payment window according to an embodiment of the present invention.
Figure 12 is a processing flowchart for explaining the 1:N proxy payment process according to an embodiment of the present invention.
Figure 13 is a processing flowchart illustrating an offline proxy payment process according to an embodiment of the present invention.
Figure 14 is an example of a diagram for explaining offline payment based on a temporary payment code according to an embodiment of the present invention.

Since the present invention can be modified in various ways and can have various embodiments, specific embodiments will be illustrated in the drawings and described in detail in the detailed description. The effects and features of the present invention and methods for achieving them will become clear by referring to the embodiments described in detail below along with the drawings. However, the present invention is not limited to the embodiments disclosed below and may be implemented in various forms. In the following embodiments, terms such as first and second are used not in a limiting sense but for the purpose of distinguishing one component from another component. Additionally, singular expressions include plural expressions unless the context clearly dictates otherwise. Additionally, terms such as include or have mean that the features or components described in the specification exist, and do not preclude the possibility of adding one or more other features or components. Additionally, in the drawings, the sizes of components may be exaggerated or reduced for convenience of explanation. For example, the size and thickness of each component shown in the drawings are shown arbitrarily for convenience of explanation, so the present invention is not necessarily limited to what is shown.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. When describing with reference to the drawings, identical or corresponding components will be assigned the same reference numerals and redundant description thereof will be omitted. .

1 is a conceptual diagram of a proxy payment system according to an embodiment of the present invention.

Referring to FIG. 1, the proxy payment system 1000 according to an embodiment of the present invention can provide a proxy payment service that requests and performs proxy payment using a communication network.

In an embodiment, the proxy payment system 1000 that provides the above proxy payment service may include a terminal 100, a payment service providing server 200, and a network 300.

At this time, the terminal 100 and the payment service providing server 200 may be connected through the network 300.

Here, the network 300 according to the embodiment refers to a connection structure that allows information exchange between each node, such as the terminal 100 and/or the payment service providing server 200. This network 300 ) Examples include the 3rd Generation Partnership Project (3GPP) network, Long Term Evolution (LTE) network, World Interoperability for Microwave Access (WIMAX) network, Internet, Local Area Network (LAN), and Wireless Local Area Network (Wireless LAN). ), WAN (Wide Area Network), PAN (Personal Area Network), Bluetooth network, satellite broadcasting network, analog broadcasting network, DMB (Digital Multimedia Broadcasting) network, etc., but are not limited thereto.

Hereinafter, the terminal 100 and the payment service providing server 200 that implement the proxy payment system 1000 will be described in detail with reference to the attached drawings.

- Terminal (100: Terminal)

The terminal 100 according to an embodiment of the present invention may be a computing device installed with a proxy payment application that provides the proxy payment service.

At this time, in the embodiment, the proxy payment application may also provide a simple payment service using a predetermined dedicated application and a general payment service using a credit card, bank transfer, bank transfer, mobile phone payment, and/or mobile money.

In an embodiment, these proxy payment applications may be divided into a proxy payment application for the requester, a proxy payment application for the payer, and a proxy payment application for the seller.

At this time, the proxy payment application for the requester, the proxy payment application for the payer, and the proxy payment application for the seller may be intended to perform different functional operations by distinguishing between a single application or a user.

In other words, the proxy payment application for the requester, the proxy payment application for the payer, and the proxy payment application for the seller grant different permissions and operate functions depending on the account of a single application or user (in the embodiment, the requester, payer, or seller). It may be to distinguish the point.

Returning again, in the embodiment, the terminal 100 with the above proxy payment application installed includes a requester terminal 100-1 used by the requester requesting proxy payment, and a payment process for the requested proxy payment. It may include a payer terminal (100-2) used by the payer, and an affiliated store terminal (100-3) used by the seller who sells the product purchased through the proxy payment.

At this time, in the embodiment, the proxy payment application for the requester described above may be installed in the requester terminal 100-1, and the proxy payment application for the payer described above may be installed in the payer terminal 100-2. In addition, the above-described proxy payment application for sellers may be installed in the affiliated store terminal (100-3).

Here, the requester terminal 100-1, the payer terminal 100-2, and the affiliated store terminal 100-3 are used to distinguish users in the embodiment, and their components and functional operations may be the same. .

However, in the embodiment, the affiliated store terminal 100-3 may further include a store order terminal that is installed in an offline store selling products and performs payment for products.

For example, the store order terminal may be a POS (Point Of Sale) terminal 100 placed in an offline store or a personal computer with a payment program installed.

At this time, the store order terminal may be a computing device including a predetermined identification code scanner, Near Field Communication (NFC) communicator, and/or Radio-Frequency Identification (RFID) communicator.

That is, in the embodiment, the affiliated store terminal 100-3 is a POS terminal 100 including a predetermined identification code scanner, NFC (Near Field Communication) communicator, and/or RFID (Radio-Frequency Identification) communicator, or It can be implemented with a personal computer, etc., and the temporary payment code according to an embodiment of the present invention can be recognized using the identification code scanner, NFC communicator, and/or RFID communicator.

Accordingly, the affiliated store terminal 100-3 can proceed with the payment process according to the recognized temporary payment code. A detailed explanation of this will be provided later.

Coming back, from a hardware perspective, the terminal 100 may include a mobile type computing device and/or a desktop type computing device on which a proxy payment application is installed.

Here, the mobile type computing device may be a mobile device such as a smart phone or tablet PC with a proxy payment application installed.

For example, mobile-type computing devices may include smart phones, mobile phones, digital broadcasting devices, personal digital assistants (PDAs), portable multimedia players (PMPs), and tablet PCs.

In addition, a desktop type computing device is a program for executing a proxy payment service based on wired/wireless communication, such as a fixed desktop PC with a proxy payment application installed, a laptop computer, or a personal computer such as an ultrabook. This may include installed devices, etc.

Additionally, depending on the embodiment, the terminal 100 may further include a server computing device that provides a proxy payment service environment.

Figure 2 is an internal block diagram of the terminal 100 according to an embodiment of the present invention.

Meanwhile, referring to FIG. 2, from a functional perspective, the terminal 100 includes a memory 110, a processor assembly 120, a communication processor 130, an interface unit 140, an input system 150, and a sensor system 160. ) and a display system 170. These components may be configured to be included within the housing of the terminal 100.

In detail, the proxy payment application 111 is stored in the memory 110 , and the proxy payment application 111 may store one or more of various applications, data, and commands for providing a proxy payment service environment.

That is, the memory 110 can store commands and data that can be used to create a proxy payment service environment.

Additionally, the memory 110 may include a program area and a data area.

Here, the program area according to the embodiment may be linked between the operating system (OS) and functional elements that boot the terminal 100, and the data area is data generated according to the use of the terminal 100. can be saved.

Additionally, the memory 110 may include at least one non-transitory computer-readable storage medium and a temporary computer-readable storage medium.

For example, the memory 110 may be a variety of storage devices such as ROM, EPROM, flash drive, hard drive, etc., and web storage that performs the storage function of the memory 110 on the Internet. may include.

The processor assembly 120 may include at least one processor capable of executing instructions of the proxy payment application 111 stored in the memory 110 to perform various tasks for creating a proxy payment service environment.

In an embodiment, the processor assembly 120 may control the overall operation of components through the proxy payment application 111 of the memory 110 in order to provide a proxy payment service.

This processor assembly 120 may be a system-on-chip (SOC) suitable for the terminal 100 that includes a central processing unit (CPU) and/or a graphics processing unit (GPU), and the operating system stored in the memory 110. (OS) and/or application programs can be executed, and each component mounted on the terminal 100 can be controlled.

Additionally, the processor assembly 120 may internally communicate with each component through a system bus and may include one or more bus structures, including a local bus.

In addition, the processor assembly 120 includes application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), and controllers. ), micro-controllers, microprocessors, and other electrical units for performing functions.

The communication processor 130 may include one or more devices for communicating with external devices. This communication processor 130 can communicate through a wireless network.

In detail, the communication processor 130 can communicate with the terminal 100 that stores a content source for implementing a proxy payment service environment, and can communicate with various user input components such as a controller that receives user input.

In an embodiment, the communication processor 130 may transmit and receive various data related to the proxy payment service to another terminal 100 and/or an external server.

This communication processor 130 uses technical standards or communication methods for mobile communication (e.g., Long Term Evolution (LTE), Long Term Evolution-Advanced (LTE-A), 5G New Radio (NR), WIFI). Alternatively, data can be transmitted and received wirelessly with at least one of a base station, an external terminal 100, and an arbitrary server on a mobile communication network established through a communication device capable of performing short-distance communication.

The sensor system 160 may include various sensors such as an image sensor 161, a position sensor (IMU) 163, an audio sensor 165, a distance sensor, a proximity sensor, and a contact sensor.

Here, the image sensor 161 may capture images and/or videos of the physical space around the terminal 100.

In an embodiment, the image sensor 161 may capture and obtain images related to proxy payment services (eg, target product images, etc.).

In addition, the image sensor 161 is disposed on the front or/and rear of the terminal 100 and can acquire an image by photographing the direction in which the terminal 100 is placed. You can photograph space.

This image sensor 161 may include an image sensor device and an image processing module. In detail, the image sensor 161 can process still images or moving images obtained by an image sensor device (eg, CMOS or CCD).

Additionally, the image sensor 161 may use an image processing module to process still images or moving images obtained through the image sensor device to extract necessary information and transmit the extracted information to the processor.

This image sensor 161 may be a camera assembly including at least one camera.

At this time, the camera assembly may include a general camera that photographs a visible light band, and may further include a special camera such as an infrared camera or a stereo camera.

In addition, the image sensor 161 as described above may be included and operated in the terminal 100, depending on the embodiment, or may be included in an external device (e.g., an external server, etc.) and may be included in the above-described communication processor 130 and/or Alternatively, it may operate through linkage based on the interface unit 140.

The position sensor (IMU, 163) can detect at least one of the movement and acceleration of the terminal 100. For example, it may consist of a combination of various position sensors such as an accelerometer, gyroscope, or magnetometer.

Additionally, the location sensor (IMU) 163 may recognize spatial information about the physical space around the terminal 100 in conjunction with the location communication processor 130, such as the GPS of the communication processor 130.

The audio sensor 165 can recognize sounds around the terminal 100.

In detail, the audio sensor 165 may include a microphone capable of detecting voice input from a user using the terminal 100.

In an embodiment, the audio sensor 165 may receive voice data required for proxy payment service from the user.

The interface unit 140 can connect the terminal 100 to communicate with one or more other devices.

In detail, the interface unit 140 may include a wired and/or wireless communication device compatible with one or more different communication protocols.

Through this interface unit 140, the terminal 100 can be connected to various input/output devices.

For example, the interface unit 140 may be connected to an audio output device such as a headset port or a speaker to output audio.

As an example, the audio output device is connected through the interface unit 140, but embodiments in which the audio output device is installed inside the terminal 100 may also be included.

Additionally, for example, the interface unit 140 may be connected to an input device such as a keyboard and/or mouse to obtain user input.

As an example, it has been described that the keyboard and/or mouse are connected through the interface unit 140, but embodiments in which the keyboard and/or mouse are installed inside the terminal 100 may also be included.

This interface unit 140 connects devices equipped with a wired/wireless headset port, an external charger port, a wired/wireless data port, a memory card port, and an identification module. Port, audio I/O (Input/Output) port, video I/O (Input/Output) port, earphone port, power amplifier, RF circuit, transceiver and other communication circuits It may be configured to include at least one of:

The input system 150 may detect a user's input (eg, a gesture, voice command, button operation, or other type of input) related to the proxy payment service.

In detail, the input system 150 may include a predetermined button, a touch sensor, and/or an image sensor 161 that receives a user motion input.

Additionally, the input system 150 is connected to an external controller through the interface unit 140 and can receive user input.

The display system 170 can output various information related to proxy payment services as graphic images.

In an embodiment, the display system 170 may display various user interfaces, including a payment bridge page, a proxy payment request window, a proxy payment information pop-up window, a waiting screen window, a proxy payment window, and/or a conditional approval window, etc. .

These displays include liquid crystal display (LCD), thin film transistor-liquid crystal display (TFT LCD), organic light-emitting diode (OLED), and flexible display. , a 3D display, or an e-ink display.

Here, the above components may be disposed within the housing of the terminal 100, and the user interface may include a touch sensor 173 on the display 171 configured to receive a user touch input.

In detail, the display system 170 may include a display 171 that outputs an image and a touch sensor 173 that detects a user's touch input.

For example, the display 171 may be implemented as a touch screen by forming a mutual layer structure or being integrated with the touch sensor 173.

This touch screen can function as a user input unit that provides an input interface between the terminal 100 and the user, and at the same time, can provide an output interface between the terminal 100 and the user.

Additionally, depending on the embodiment, the terminal 100 may further perform at least part of the functional operations performed by the payment service providing server 200, which will be described later.

- Payment service providing server (200: Payment service providing server)

Meanwhile, the payment service providing server 200 according to an embodiment of the present invention can perform a series of processes to provide a proxy payment service.

In detail, in the embodiment, the payment service providing server 200 can implement the proxy payment service by exchanging the data necessary to run the proxy payment process in an external device such as the terminal 100 with the external device. there is.

In more detail, in the embodiment, the payment service providing server 200 may provide an environment in which a proxy payment service can be implemented in an external device (in the embodiment, a mobile type computing device and/or a desktop type computing device, etc.). there is.

To this end, the payment service providing server 200 may include various application programs, data, and/or commands for implementing a proxy payment service, and may transmit and receive data based thereon with the external device.

In an embodiment, the payment service providing server 200 includes at least one payment information, payment request information, proxy payment request information, proxy payment authorization information, payment completion information, payment history information, proxy payment approval condition information, and temporary payment code. , user account information, offline payment information, and/or various user interfaces, etc. can be stored and managed.

Figure 3 is an internal block diagram of the payment service providing server 200 according to an embodiment of the present invention.

Referring to FIG. 3, the payment service providing server 200 as described above may include at least one proxy payment server 210, a management server 220, a settlement server 230, and a payment processing server 240. .

At this time, the proxy payment server 210, management server 220, settlement server 230, and/or payment processing server 240 may be installed directly on the payment service providing server 200, and may be installed directly on the payment service providing server 200. It may exist externally as a separate device and/or server from 200. Hereinafter, it will be explained that the proxy payment server 210, management server 220, settlement server 230, and/or payment processing server 240 are installed and operated directly on the payment service providing server 200.

In detail, the proxy payment server 210 according to the embodiment may perform various operation management processes related to the proxy payment service.

In an embodiment, the proxy payment server 210 may perform certain functional operations related to a series of processes for implementing a proxy payment service, for example, collecting data such as proxy payment requests and/or performance status for each user. It can be managed by creating a database.

Additionally, the management server 220 according to the embodiment may perform a management process related to purchasing products on a proxy payment service.

For example, the management server 220 may manage partner companies registered on the proxy payment service, manage product orders, and/or manage the sending of product identification codes.

Additionally, the settlement server 230 according to the embodiment may perform a payment settlement process for products purchased through the proxy payment service based on a settlement policy negotiated on the proxy payment service.

In an embodiment, the settlement server 230 may perform a process of settling the price and/or managing the remaining amount in the temporary payment code as proxy payment for the product is approved.

Additionally, the payment processing server 240 according to the embodiment may perform a payment process on a proxy payment service.

In an embodiment, the payment processing server 240 performs payment processing and management for products purchased through a proxy payment service, cash receipt issuance management, payment processing and management of the settled amount and/or commission, etc. You can.

At this time, in the embodiment, the payment processing server 240 inputs the user's payment method information through a predetermined terminal 100 and then conveniently performs a simple authentication process such as a password or fingerprint recognition that identifies the user at the time of payment. A simple payment service that can perform the payment process can also be provided based on the proxy payment service.

Accordingly, the payment service providing server 200 according to the embodiment can implement a proxy payment service that requests and performs proxy payment based on a communication network based on the components described above.

Meanwhile, referring further to FIG. 1, in the embodiment, the payment service providing server 200 as described above includes at least one processor module 260 for data processing and at least one processor module 260 for data exchange with an external device. It is a predetermined computing device including one or more communication modules (270: Communication Module) and at least one memory module (280: Memory Module) that stores various applications, data, and/or instructions for implementing a proxy payment service. It can be implemented.

Here, the memory module 280 may store one or more of an operating system (OS), various application programs, data, and commands for providing proxy payment services.

Additionally, the memory module 280 may include a program area and a data area.

Here, the program area according to the embodiment may be linked between the operating system (OS) that boots the server and functional elements, and the data area may store data generated according to the use of the server.

In an embodiment, the memory module 280 may be a variety of storage devices such as ROM, RAM, EPROM, flash drive, hard drive, etc., and may be a web device that performs the storage function of the memory module 280 on the Internet. It could also be storage (web storage).

Additionally, the memory module 280 may be a recording medium that is removable from the server.

Meanwhile, the processor module 260 can control the overall operation of each unit described above in order to implement a proxy payment service.

This processor module 260 may be a system-on-chip (SOC) suitable for a server that includes a central processing unit (CPU) and/or graphics processing unit (GPU), and the operating system (OS) stored in the memory module 280 ) and/or application programs, etc., and control each component mounted on the server.

Additionally, the processor module 260 may internally communicate with each component through a system bus and may include one or more bus structures, including a local bus.

In addition, the processor module 260 includes application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), and controllers. ), micro-controllers, microprocessors, and other electrical units for performing functions.

In the above description, it has been explained that the payment service providing server 200 according to an embodiment of the present invention performs the functional operations as described above, but at least part of the functional operations performed by the payment service providing server 200 according to the embodiment may be performed by an external device (e.g., terminal 100, etc.), and at least part of the functional operation performed by the external device may be further performed by the payment service providing server 200. It may be possible.

- Proxy payment method

Hereinafter, a method by which the requester terminal 100-1 provides proxy payment according to an embodiment of the present invention will be described in detail with reference to FIGS. 4 to 14 attached.

Figure 4 is a processing flowchart for explaining a proxy payment method according to an embodiment of the present invention.

Referring to FIG. 4, in an embodiment of the present invention, the requester terminal 100-1 may execute a payment request process.

In detail, in the embodiment, the requester terminal 100-1 may execute a proxy payment application 111 stored in the memory 110 to perform a payment request to reserve an order for a certain product.

In more detail, in the embodiment, the requester terminal 100-1 executes the proxy payment application 111 and provides payment request information to reserve an order for a predetermined product to the affiliated store terminal 100-3 selling the product. can be transmitted.

At this time, when transmitting the payment request information, the requester terminal 100-1 may also transmit payment information for the product for which payment is requested (hereinafter referred to as target product).

Here, the payment information according to the embodiment may mean information including basic data (e.g., order number, order amount, product name, and/or affiliated store information, etc.) required to proceed with the payment process for the target product. there is.

At this time, the affiliated store terminal 100-3 may receive the payment information, transmit it to the payment service providing server 200, and proceed with an order reservation for the target product.

Additionally, the affiliated store terminal 100-3 may receive an order sheet URL (orderSheetUrl) for the target product reserved for order from the payment service providing server 200.

Additionally, the affiliated store terminal 100-3 may call the payment bridge page previously created and stored in the memory 110 based on the received order sheet URL and provide the payment bridge page to the requester terminal 100-1.

Figure 5 is an example of a drawing for explaining a payment bridge page according to an embodiment of the present invention.

Here, referring to FIG. 5, the payment bridge page according to the embodiment may be a user interface that determines a payment method for the target product that has been ordered based on user (here, requester) input.

In detail, in the embodiment, the requester terminal 100-1 uses a simple payment method to pay for the target product using the above-described simple payment service based on the payment bridge page, and a simple payment method to pay for the target product using the above-described general payment service. It is possible to obtain a requester input for selecting one of the payment methods among the general payment method and the proxy payment method that performs payment for the target product using the proxy payment service according to an embodiment of the present invention.

At this time, depending on the embodiment, the simple payment method may be implemented by further including the proxy payment method.

That is, in the embodiment, the requester terminal 100-1 receives and outputs the above payment bridge page from the affiliated store terminal 100-3, so that the requester selects a payment method for the target product based on the payment bridge page. You can do it.

Additionally, in the embodiment, the requester terminal 100-1 may execute a proxy payment process.

In detail, referring further to FIG. 5, in the embodiment, the requester terminal 100-1 may execute a proxy payment process based on a user (here, requester) input based on the payment bridge page.

More specifically, in the embodiment, the requester terminal 100-1 is a proxy that processes payment for the target product based on the proxy payment service described above when a requester input for selecting a proxy payment method within the payment bridge page is obtained. You can run the payment process.

Hereinafter, various embodiments of executing the proxy payment process will be described in detail with reference to the attached drawings. For effective explanation, the embodiments will be described separately as described below, but various embodiments may also be possible, such as at least some of the above embodiments operating in organic combination with each other.

<1:1 proxy payment process>

Figure 6 is a processing flowchart illustrating a 1:1 proxy payment process according to an embodiment of the present invention.

Referring to FIG. 6, in an embodiment of the present invention, the requester terminal 100-1 provides a 1:1 proxy payment process in which a requester can request a proxy payment from one payer and proceed with the payment process. You can.

In detail, in the embodiment, the requester terminal 100-1 may perform step 1) proxy payment request .

More specifically, in the embodiment, the requester terminal 100-1 may request proxy payment for the target product in conjunction with the payment service providing server 200.

Figure 7 is an example of a diagram for explaining a proxy payment request window according to an embodiment of the present invention.

Specifically, referring to (a) of FIG. 7, in the embodiment, the requester terminal 100-1 may provide a proxy payment request window.

Here, the proxy payment request window according to an embodiment of the present invention may be a user interface through which information on the person requesting proxy payment (i.e., payer in the embodiment) and/or a requester message, etc. can be input.

In an embodiment, the requester terminal 100-1 may display the proxy payment request window and provide it to a user (here, the requester), and based on the requester's input, the payer information (in the embodiment, the proxy The payment recipient's name and/or mobile phone number, etc.) and/or the requester's message, etc. can be obtained.

Meanwhile, depending on the embodiment, the proxy payment request window may display and provide payment information for the corresponding target product.

Additionally, in the embodiment, the requester terminal 100-1 may generate proxy payment request information including the payer information, requester message, payment information, and/or requester information (in the embodiment, requester name, etc.). .

And, when a payment request input based on the proxy payment request window is obtained, the requester terminal 100-1 may transmit the generated proxy payment request information to the payment service providing server 200.

At this time, in the embodiment, the requester terminal 100-1 may provide an abusing blocking function in the proxy payment process.

Here, the abusing blocking function according to the embodiment is a function to prevent the occurrence of unfair profits based on the proxy payment process, and may be a function to filter products, affiliated stores, and/or users that are concerned about abusing issues.

In detail, in the embodiment, the requester terminal 100-1 may: 1> filter products for which abusing issues are a concern.

More specifically, in the embodiment, the requester terminal 100-1 may pre-register at least one product name excluded from proxy payment on the proxy payment service.

Additionally, the requester terminal 100-1 may block the proxy payment process from proceeding when the product name excluded from proxy payment is searched on the proxy payment request information described above.

For example, when the requester terminal 100-1 searches for words related to cash products such as 'gift certificate', 'gold', and/or 'cash' in the product name in the payment information included in the proxy payment request information, The progress of the corresponding proxy payment process can be blocked.

Additionally, in the embodiment, the requester terminal 100-1 may 2> perform filtering of affiliated stores where abusing issues are a concern.

In detail, in the embodiment, the requester terminal 100-1 selects at least one affiliated store excluded from proxy payment that is judged to have an abusing risk depending on some industries and/or sales products, such as game companies and/or cash product handling companies. You can already register on the proxy payment service.

And in the embodiment, the requester terminal 100-1 may block the proxy payment process from proceeding when the name of the affiliated store excluded from the proxy payment is searched on the proxy payment request information described above.

Alternatively, the requester terminal 100-1 may pre-register on the proxy payment service the affiliated stores eligible for proxy payment, excluding at least one affiliated store excluded from proxy payment that is determined to have the above-described abusing risk.

Additionally, the requester terminal 100-1 may block the proxy payment process from proceeding when an affiliated store name other than the name of the affiliated store eligible for proxy payment is searched on the proxy payment request information described above.

Additionally, in the embodiment, the requester terminal 100-1 may 3> perform filtering of users who are concerned about abusing issues.

In detail, in the embodiment, the requester terminal 100-1 may set a user who has accumulated more than a predetermined number of reports by other users on the proxy payment service as a blacklisted user.

For example, when a specific requester maliciously repeatedly requests a specific user to make proxy payments, the specific user can report the specific requester, and the number of reports for the specific requester can be counted. And if the number of reports accumulates more than a predetermined number, the specific requester may be set as a blacklist user.

Additionally, the requester terminal 100-1 may pre-register at least one blacklist user name set as the blacklist user on the proxy payment service.

And in the embodiment, the requester terminal 100-1 may block the proxy payment process from proceeding when the blacklisted user name is searched on the proxy payment request information described above.

That is, the requester terminal 100-1 may block the proxy payment process related to the blacklisted user and restrict the blacklisted user's use of the proxy payment service.

In this way, the requester terminal 100-1 filters products, merchants, and/or users that are concerned about abusing issues when executing the proxy payment process in advance and restricts the use of the proxy payment service, thereby preventing unfair use of the proxy payment function. Various abusing actions, such as taking advantage or causing cyber terrorism by excessive proxy payment requests for specific users, can be prevented in advance, and through this, a safer and more just proxy payment service environment can be established.

Meanwhile, referring to (b) of FIG. 7, according to the embodiment, when a payment request input based on the proxy payment request window is obtained, the requester terminal 100-1 displays a proxy payment information pop-up window. There may be more to offer.

Here, the proxy payment information pop-up window according to the embodiment may be a push notification interface that provides guidance text related to the processing completion/waiting/failure status of the proxy payment.

For example, the requester terminal 100-1 may provide a proxy payment information pop-up window that provides information such as “The other party must proceed with the payment within 20 minutes after the proxy payment request.”

Depending on the embodiment, if the function for automatically providing the proxy payment information pop-up window as described above is not set when obtaining the payment request input, the requester terminal 100-1 may respond to the proxy payment information pop-up window. It may also provide a push settings pop-up window where you can perform activation settings.

At this time, in the embodiment, the processing status for the proxy payment can be set based on predetermined conditions at the requester terminal 100-1 and/or the payment service providing server 200, and can be set in detail as completed status, waiting status, and failure. Can include status.

Here, the predetermined conditions according to the embodiment may include whether a predetermined time has elapsed since the request for proxy payment, whether the payer accepts the proxy payment, whether the requester cancels the proxy payment, and/or whether the payment is approved, etc.

As an example, the processing completion status for the proxy payment may be within 20 minutes after the proxy payment request and payment approval is completed. Additionally, the processing waiting state for the proxy payment may be within 20 minutes after the proxy payment request and payment approval has not yet been completed. Continuing, the processing failure status for the proxy payment is when the payer rejects it within 20 minutes after the proxy payment request, when the requester cancels within 20 minutes after the proxy payment request, and/or after 20 minutes after the proxy payment request. This may be a case where payment approval is not completed (timeout).

Figure 8 is an example of a drawing for explaining a standby screen window according to an embodiment of the present invention.

Returning again, referring to FIG. 8, the requester terminal 100-1, which has transmitted the generated proxy payment request information to the payment service providing server 200, may provide a standby screen window.

Here, the waiting screen window according to the embodiment refers to the payment service providing server 200, the payer terminal 100-2, and/or the affiliated store terminal 100 after the requester terminal 100-1 performs a proxy payment request. Based on -3), it may refer to a user interface output on the requester terminal 100-1 while the proxy payment process for the target product is in progress (i.e., during the response waiting time).

In an embodiment, this waiting screen window may include validity time countdown information indicating the effective time of the proxy payment and/or progress information indicating the progress of the proxy payment process.

Additionally, in the embodiment, the standby screen window may further include a proxy payment re-request button and/or a proxy payment request cancellation button.

In detail, in the embodiment, when the requester terminal (100-1) obtains a user (here, requester) input based on the proxy payment re-request button in the standby screen window, the payer terminal (100-2) is detected as described later. You can additionally send a proxy payment request notification.

Here, the proxy payment request notification is a user interface that informs the user (here, the payer) that a proxy payment has been requested based on the proxy payment request information, and is a push notification through a simple payment application, a social network service (SNS), etc. ) may be in the form of an instant message and/or text message (SMS).

However, in the embodiment, the requester terminal 100-1 may block additional proxy payment request notifications based on the re-request button when the payment process for the target product is started in the corresponding payer terminal 100-2. .

For example, the requester terminal 100-1 may block the additional proxy payment request notification by deactivating the proxy payment re-request button.

In this way, the requester terminal 100-1 enables additional transmission of a separate proxy payment request notification to the person requesting proxy payment (in the embodiment, the payer), so that the payer cannot confirm the proxy payment request notification. Even if a situation occurs where the payment is made or forgotten, the payer can be reminded to enable smooth incoming calls.

At this time, depending on the embodiment, the requester terminal 100-1 may prevent the problem of excessive sending of proxy payment request notifications by placing a predetermined limit (e.g., a maximum of two times, etc.) on the number of additional transmissions. .

In addition, in the embodiment, when the requester terminal 100-1 obtains a user (here, requester) input based on the proxy payment request cancellation button in the waiting screen window, it may proceed with the proxy payment cancellation process to stop the corresponding proxy payment process. You can.

In detail, in the embodiment, the requester terminal 100-1 may transmit proxy payment request cancellation information according to the requester input to the payment service providing server 200, and the payment service providing server 200 may transmit proxy payment request cancellation information according to the requester input. You can stop the payment process.

Additionally, the payment service providing server 200 may provide a push notification informing of cancellation of the corresponding proxy payment to the corresponding payer terminal 100-2.

At this time, the requester terminal 100-1 may move to the previous screen, that is, the proxy payment request window, when obtaining the requester's input for the proxy payment request cancellation button.

However, in the embodiment, the requester terminal 100-1 may block the proxy payment cancellation process when the payment process for the target product is started in the corresponding payer terminal 100-2.

For example, the requester terminal 100-1 may block the proxy payment cancellation process by deactivating the proxy payment request cancellation button.

In the embodiment, when the proxy payment cancellation process proceeds as described above, the progress of the proxy payment process in the payer terminal 100-2 that has received the proxy payment request notification is restricted, and a push notification is sent to guide the proxy payment cancellation. A notification may be output.

In this way, the requester terminal 100-1 allows the proxy payment request to be canceled only after requesting proxy payment and before the payer's payment is performed, due to unavoidable reasons, unexpected circumstances, negligence or change of mind of the requester, etc. It can meet the needs and convenience of requesters who wish to cancel proxy payment requests.

Additionally, in the embodiment, the requester terminal 100-1 may perform step 2) proxy payment progress and completion .

In detail, the payment service providing server 200, which has received proxy payment request information from the requester terminal 100-1, receives the proxy payment request information from the payer terminal 100-1 corresponding to the payer information. 2) can be detected.

For example, the payment service providing server 200 may detect the mobile communication terminal 100 matching the name and mobile phone number included in the payer information as the payer terminal 100-2.

Additionally, the payment service providing server 200 may provide a proxy payment window based on the proxy payment request information to the detected payer terminal 100-2.

9 to 11 are examples of drawings for explaining a proxy payment window according to an embodiment of the present invention.

Here, referring to FIG. 9, the proxy payment window according to the embodiment may be a user interface that can perform a payment or payment rejection process for the target product for which proxy payment has been requested.

In an embodiment, this proxy payment window may include a requester message, payment information, requester information, a proxy payment button and/or a proxy payment rejection button, etc.

In detail, in the embodiment, the payment service providing server 200 may create a proxy payment window as described above based on the received proxy payment request information and provide it to the detected payer terminal 100-2. .

In more detail, the payment service providing server 200, which has received proxy payment request information from the requester terminal 100-1, may generate a proxy payment request notification based on the received proxy payment request information.

Here, in other words, in the embodiment, the proxy payment request notification is a user interface that informs the user (here, the payer) that proxy payment has been requested based on the proxy payment request information, and is a push notification through a simple payment application, It may be in the form of an instant message and/or text message (SMS) through a social network service (SNS).

At this time, the proxy payment request notification may further include a make payment button that provides movement (link) to the proxy payment window. Depending on the embodiment, the proxy payment request notification may further include a proxy payment rejection button that can proceed with the proxy payment rejection process on the corresponding interface.

Additionally, the payment service providing server 200 may transmit the generated proxy payment request notification to the detected payer terminal 100-2 as described above.

At this time, the payer terminal 100-2, which has received the proxy payment request notification, may obtain a user (here, payer) input for selecting a payment button in the received proxy payment request notification.

Then, the payer terminal 100-2 can display and output a proxy payment window corresponding to the proxy payment request notification and provide it to the corresponding payer.

At this time, the payer provided with the proxy payment window can check the requester message, payment information, and/or requester information included in the proxy payment window and then decide whether to proceed or reject the proxy payment.

In addition, the payer may perform a user input to select either a proxy payment button or a proxy payment rejection button in the proxy payment window depending on whether the proxy payment proceeds or is rejected.

Subsequently, the payer terminal 100-2 may generate proxy payment authorization information based on the performed payer input.

At this time, the proxy payment authorization information according to the embodiment may include payment authentication request information indicating the payer's proxy payment acceptance or payment rejection request information indicating the payer's proxy payment rejection.

In detail, referring to FIG. 10, in the embodiment, the payer terminal 100-2 performs a payment process to proceed with payment for the target product when the payer input for the proxy payment button in the proxy payment window is obtained. You can proceed.

In an embodiment, the payer terminal 100-2 may execute an online payment process in which a payment method is selected and a payment password is entered according to the payment process.

Additionally, the payer terminal 100-2 may generate payment authentication request information indicating acceptance of the proxy payment upon completion of payment through the payment process and transmit it to the payment service providing server 200.

At this time, the payment service providing server 200, which has received the payment authentication request information, may transmit and provide the received payment authentication request information to the corresponding affiliated store terminal 100-3.

And the affiliated store terminal (100-3) sends the received payment authentication request information in a predetermined manner (e.g., push notification through a simple payment application, instant message and/or text message through a social network service (SNS)) It can be displayed and output via SMS, etc. and provided to the seller.

At this time, the affiliated store terminal 100-3 may provide a payment authorization user interface that can obtain a payment approval or rejection input from the seller based on the payment authentication request information.

Here, the seller may perform an approval input to approve the payment or a rejection input to reject the payment based on the payment authorization user interface.

And when the affiliated store terminal 100-3 obtains the seller's approval input based on the authorization user interface, it can transmit payment approval request information to the payment service providing server 200.

Then, the payment service providing server 200 can perform payment approval processing for the corresponding target product according to the received payment approval request information.

Additionally, when the payment approval process is completed, the payment service providing server 200 may transmit and provide payment completion information to the corresponding payer terminal 100-2 and affiliated store terminal 100-3.

As such, the proxy payment service according to an embodiment of the present invention requests a remote payer to pay for a product to be purchased using a communication network, and if the request is accepted, the payment process by the payer is performed. By implementing the proxy payment function for the above products, you can make the desired payment without restrictions on time and place in various situations where proxy payment is necessary (e.g., absence of payment method, lack of payment amount, business necessity, and/or simple request, etc.) You can easily request a proxy payment from a person and provide an environment and user interface that allows the payer who receives the request to easily and conveniently make the proxy payment.

Meanwhile, referring to FIG. 11, in the embodiment, when the payer terminal 100-2 obtains the payer input for the proxy payment rejection button in the proxy payment window, it can proceed with the payment rejection process for the target product. there is.

In detail, in the embodiment, when the payer terminal 100-2 obtains the payer input of selecting the payment rejection button, it may generate payment rejection request information and transmit it to the payment service providing server 200.

At this time, the payment service providing server 200 may transmit and provide the received payment rejection request information to the corresponding requester terminal 100-1.

Then, the requester terminal 100-1 sends the received payment rejection request information in a predetermined manner (e.g., push notification through a simple payment application, instant message through social network service (SNS), and/or text message ( It can be displayed and output via SMS, etc. and provided to the requester.

At this time, the requester terminal 100-1 may provide a page movement user interface that allows the user to move back to the payment bridge page described above by providing the payment rejection request information.

In addition, the requester terminal 100-1 can move to the payment bridge page by obtaining the requester's input for the page movement user interface, and then re-determine the payment method for the target product and proceed with the payment process accordingly. .

As such, the proxy payment service according to an embodiment of the present invention allows the payer who has been requested to make a proxy payment to convey his or her refusal to do so to the requester through a simple procedure, thereby facilitating communication between the requester and the payer regarding whether or not the proxy payment is approved. We can provide support quickly and easily.

Additionally, in the embodiment, the requester terminal 100-1 may perform step 3) proxy payment-based order completion processing .

In detail, in the embodiment, the requester terminal 100-1 may obtain the above-described payment completion information by receiving it from the corresponding affiliated store terminal 100-3.

At this time, the requester terminal 100-1 sends the received payment completion information in a predetermined manner (e.g., push notification through a simple payment application, instant message through social network service (SNS), and/or text message (SMS). ), etc.) can be displayed and output to the requester.

Additionally, in the embodiment, the requester terminal 100-1 may perform order completion processing based on proxy payment for the target product upon obtaining the payment completion information.

In detail, the requester terminal 100-1 may add payment history information based on proxy payment for the target product on the payment history page where accumulated payment history information can be viewed.

Here, by way of example, the payment history information may include the cumulative total payment amount, payment details by date, and/or payment method information used.

At this time, in the embodiment, the requester terminal 100-1 may exclude the payment amount for the target product paid through proxy payment according to the embodiment of the present invention when calculating the cumulative total payment amount.

Additionally, in the embodiment, the requester terminal 100-1 may indicate and provide the payment method by setting it to 'proxy payment'.

On the other hand, in the embodiment, the payer terminal 100-2 also sends the payment completion information received from the payment service providing server 200 in a predetermined manner (e.g., push notification through a simple payment application, social network service). It can be displayed and output as an instant message (via SNS) and/or text message (SMS) and provided to the payer.

Additionally, in the embodiment, the payer terminal 100-2 may perform proxy payment-based order completion processing for the target product upon obtaining the payment completion information.

At this time, when calculating the cumulative total payment amount based on the payment history information, the payer terminal 100-2 may also add up the payment amount for the target product paid through proxy payment.

In this way, the proxy payment service according to an embodiment of the present invention can systematically check and manage payment details related to proxy payments.

<1:N proxy payment process>

Figure 12 is a processing flowchart for explaining the 1:N proxy payment process according to an embodiment of the present invention.

Referring to FIG. 12, in an embodiment of the present invention, the requester terminal 100-1 provides a 1:N proxy payment process through which the requester can request proxy payment from multiple payers and proceed with the payment process. can do.

In the following, descriptions that overlap with the content disclosed in the 1:1 proxy payment process described above may be summarized or omitted, and the description will focus on differentiated content.

In detail, in the embodiment, the requester terminal 100-1 may perform step 1) proxy payment request .

More specifically, in the embodiment, the requester terminal 100-1 may provide a proxy payment request window through which proxy payment for the target product can be requested in conjunction with the payment service providing server 200.

Additionally, in the embodiment, the requester terminal 100-1 may obtain a plurality of payer information (in the embodiment, the payer's name and/or mobile phone number, etc.) based on the proxy payment request window.

For example, the requester terminal 100-1 may obtain first to Nth payer information about the first to Nth payers according to the requester's input based on the proxy payment request window.

Hereinafter, for effective explanation, the description will be based on an embodiment in which a proxy payment is requested from a plurality of payers including a first payer and a second payer, but is not limited thereto.

At this time, in the embodiment, the requester terminal 100-1 may provide a split payment management function to request split proxy payment to a plurality of payers.

Here, the split payment management function according to the embodiment may mean additional functions that can assist split proxy payments by multiple payers.

In an embodiment, this installment payment management function may include a function of selecting a person who pays in installments, a function of selecting an order amount division method, and/or a sequential request function.

In detail, in the embodiment, the requester terminal 100-1 may provide a function of 1> selecting a partial payment party.

Here, the partial payer selection function according to the embodiment may mean a function of selecting and entering a plurality of payers on the proxy payment request window.

More specifically, in the embodiment, the requester terminal 100-1 may read at least one piece of contact information (e.g., information including name and mobile phone number data, etc.) stored in the memory 110 and provide it as a contact list. .

Additionally, the requester terminal 100-1 may determine a plurality of payers who wish to request the split proxy payment according to the requester's input of selecting a plurality of contact information in the contact list.

Alternatively, in an embodiment, the requester terminal 100-1 may provide a payer multi-input form in which multiple payers can be entered based on the proxy payment request window.

And the requester terminal 100-1 may determine the plurality of payers according to the requester's input on the provided payer multiple input form.

Alternatively, in the embodiment, the requester terminal 100-1 uses the user identification number (e.g., user ID and/or identification code, etc.) registered in the simple payment application based on the proxy payment request window to obtain the plurality of A user interface that allows multiple payment inputs can be provided.

Additionally, the requester terminal 100-1 may determine the plurality of payers based on the requester's input into the provided payer multiple input interface.

Accordingly, the requester terminal 100-1 can provide a convenient UI without the hassle of having to manually enter all information one by one when entering multiple payers.

Additionally, in the embodiment, the requester terminal 100-1 may provide the function of 2> selecting an order amount division method.

Here, the order amount division method selection function according to the embodiment may mean a function of dividing the order amount of the corresponding target product and selecting how a plurality of payers will perform the divided proxy payment.

In detail, in the embodiment, the requester terminal 100-1 may provide an order amount division method selection function that can select any one of the equal division method, manual input division method, and/or random division method.

Here, the equal division method according to the embodiment may be a method in which a plurality of input payers divide the order amount for the target product by the same ratio.

For example, when the first payer and the second payer are entered and the equal division method is set, the requester terminal 100-1 sends the order amount (e.g., 20,000 won) for the target product to the first payment. The first payer and the second payer can split the payment in equal proportions and make a proxy payment (for example, the first payer and the second payer each make a proxy payment of 10,000 won).

Depending on the embodiment, the requester terminal 100-1 may set this equal division method as the default method for dividing the order amount.

In addition, the manual input splitting method according to the embodiment may be a method in which the requester directly inputs and determines the proxy payment amount for each of the plurality of payers, and performs the split proxy payment based on this.

For example, when the first payer and the second payer are entered and the manual input splitting method is set, the requester terminal 100-1 requests proxy payment for each of the first payer and the second payer. A user interface that allows manual input of an amount can be provided, and the proxy payment amount for each payer can be determined according to the requester's input using this.

In addition, the random division method according to the embodiment may be a method in which a plurality of input payers divide the order amount for the target product by a randomly set ratio.

In the embodiment of the present invention, the method of dividing the order amount for the target product has been described based on the above-described embodiments, but it is not limited thereto, and various embodiments in which the order amount can be divided by multiple payers are provided. It may be further included in embodiments of the invention.

Through this, the requester terminal 100-1 can provide various types of split payment functions that take advantage of proxy payments by multiple payers.

Additionally, in the embodiment, the requester terminal 100-1 may provide a 3> sequential request function.

Here, the sequential request function according to the embodiment refers to a function that sets priorities for a plurality of payers entered based on the multiple payment request window and sequentially requests proxy payments according to the set priorities. can do.

If the sequential request function is deactivated, in the embodiment, the requester terminal 100-1 may request a batch proxy payment from a plurality of payers selected based on the proxy payment request window.

Conversely, when the sequential request function is activated, in an embodiment, the requester terminal 100-1 may provide a user interface for setting priorities for each of a plurality of input payers.

Additionally, in the embodiment, the requester terminal 100-1 may determine the priority of each of the plurality of payers based on the requester's input based on the provided priority setting user interface.

For example, the requester terminal 100-1 ranks the first payer as 1st priority, the second payer as 2nd priority, etc. according to the requester input. , the Nth payer can be determined in N rank.

Additionally, in the embodiment, the requester terminal 100-1 may request proxy payment sequentially according to the determined priority.

At this time, in the embodiment, the requester terminal 100-1 requests a proxy payment from a senior payer with a higher priority, and then the proxy payment by the senior payer fails (in the embodiment, the payer's proxy payment If there is a rejection, timeout, and/or cancellation of the requester's request, etc.), the proxy payment request can be automatically handed over to the next-highest payer.

For example, the requester terminal 100-1 preferentially performs a proxy payment request to the first payer, which is the first priority, and then, if the proxy payment by the first payer fails, the second payer is the second priority. You can proceed sequentially by requesting proxy payment.

Therefore, the requester terminal 100-1 performs a proxy payment request one by one for each of the proxy payer candidates considered by the requester and receives a reply as to whether or not it is approved. If it is rejected, the request is made again to another proxy payer candidate one by one. and the inconvenience of having to repeat the reply process can be resolved through the automated sequential request function.

At this time, depending on the embodiment, the requester terminal 100-1 may create a plurality of installment payment groups, assign priorities to each installment payment group, and perform the sequential request function as described above.

Illustratively, the requester terminal 100-1 includes a first partial payer group including a first payer and a second payer, and a second partial payer group including a third payer and a fourth payer. can be created.

Additionally, the requester terminal 100-1 may assign priority to each of the first partial payment group and the second partial payment group.

In addition, the requester terminal 100-1 may also assign priorities to a plurality of payers within each partial payer group.

Accordingly, the requester terminal 100-1 can perform the proxy payment sequential request function as described above according to the priority of each group of partial payers and each payer within the group of partial payers.

Accordingly, the requester terminal 100-1 can sequentially request proxy payment in accordance with the payer candidate list and priority established more systematically and in detail according to the requester settings.

Returning again, in another embodiment, the requester terminal 100-1 may generate proxy payment request information including the obtained plurality of payer information.

And, when a payment request input based on the proxy payment request window is obtained, the requester terminal 100-1 may transmit the generated proxy payment request information to the payment service providing server 200.

Additionally, in the embodiment, the requester terminal 100-1 may perform step 2) proxy payment progress and completion .

In detail, the payment service providing server 200, which has received proxy payment request information from the requester terminal 100-1, selects a plurality of payers corresponding to the plurality of payer information based on the received proxy payment request information. The terminal 100-2 can be detected.

For example, the payment service providing server 200 connects the first payer terminal 100-2 of the first payer and the second payer terminal 100-2 of the second payer based on the plurality of payer information. 2) can be detected.

Additionally, the payment service providing server 200 may provide a proxy payment window based on the proxy payment request information to the plurality of detected payer terminals 100-2.

In addition, each of the plurality of payer terminals 100-2 provided with the proxy payment window provides information on the corresponding proxy payment according to the input of the payer who confirmed the requester message, payment information, and/or requester information included in the proxy payment window. You can decide whether to proceed or reject.

In detail, when each of the plurality of payer terminals 100-2 obtains the payer's input for the proxy payment button in the proxy payment window, it can proceed with a payment process to make payment for the corresponding target product.

At this time, each of the plurality of payer terminals 100-2 uses the order amount division method determined as described above (in the embodiment, any one of the equal division method, manual input division method, and/or random division method). Based on this, each proxy payment process can be performed.

On the other hand, when each of the plurality of payer terminals 100-2 obtains the payer's input for the proxy payment rejection button in the proxy payment window, it can proceed with the payment rejection process for the corresponding target product.

At this time, the payment service providing server 200 according to an embodiment of the present invention makes a split proxy payment for the target product only when all N proxy payments performed at each of the plurality of payer terminals 100-2 are approved. It can be finally completed.

As such, the proxy payment service according to an embodiment of the present invention implements a split proxy payment function by multiple payers, thereby expanding the scope of use of the proxy payment function and simultaneously offsetting the burden on the proxy payer.

Additionally, in the embodiment, the requester terminal 100-1 may perform step 3) proxy payment-based order completion processing .

In detail, in the embodiment, each of the requester terminal 100-1 and the plurality of payer terminals 100-2 can perform order completion processing based on proxy payment for the target product upon obtaining the payment completion information. .

More specifically, in the embodiment, each of the requester terminal 100-1 and the plurality of payer terminals 100-2 sends the obtained payment completion information in a predetermined manner (e.g., push notification through a simple payment application, It can be displayed and output as an instant message and/or text message (SMS) through a social network service (SNS) and provided to each of the requester and multiple payers.

Additionally, in the embodiment, each of the requester terminal 100-1 and the plurality of payer terminals 100-2 may update the above-described payment history page based on the obtained payment completion information.

<Offline proxy payment process>

Figure 13 is a processing flowchart illustrating an offline proxy payment process according to an embodiment of the present invention.

Referring to FIG. 13, in an embodiment of the present invention, the requester terminal 100-1 can provide an offline proxy payment process that allows the requester to proceed with a payment process based on proxy payment when purchasing a product offline.

Hereinafter, descriptions that overlap with the content disclosed in the 1:1 proxy payment process and/or 1:N proxy payment process may be summarized or omitted, and the description will focus on differentiated content.

In detail, in the embodiment, the requester terminal 100-1 may perform an offline proxy payment request step. (S101)

In the embodiment, the requester terminal 100-1 may request an offline proxy payment from a predetermined payer terminal 100-2 in conjunction with the payment service providing server 200.

In detail, in the embodiment, the requester terminal 100-1 may provide a proxy payment request window to a predetermined payer terminal 100-2 in conjunction with the payment service providing server 200.

Here, in other words, the proxy payment request window may be a user interface through which information on the person requesting proxy payment (i.e., the payer in the embodiment) and/or a requester message can be input.

Additionally, in the embodiment, the requester terminal 100-1 may generate proxy payment request information as described above based on the requester input based on the proxy payment request window, and transmit this to the payment service providing server 200. can do.

Then, the payment service providing server 200 can detect at least one payer terminal 100-2 corresponding to the payer information based on the received proxy payment request information.

Additionally, the payment service providing server 200 may generate a proxy payment request notification based on the proxy payment request information to the detected at least one payer terminal 100-2.

Here, in other words, in the embodiment, the proxy payment request notification is a user interface that informs the user (here, the payer) that proxy payment has been requested based on the proxy payment request information, and is a push notification through a simple payment application, It may be in the form of an instant message and/or text message (SMS) through a social network service (SNS).

At this time, the proxy payment request notification may further include a make payment button that provides movement (link) to the proxy payment window. Depending on the embodiment, the proxy payment request notification may further include a proxy payment rejection button that can proceed with the proxy payment rejection process on the corresponding interface.

In addition, the payment service providing server 200 transmits the generated proxy payment request notification to the at least one payer terminal 100-2 detected as described above, thereby You can request offline proxy payment through -2).

That is, the requester terminal 100-1 can perform an offline proxy payment request by linking with the payment service providing server 200 and transmitting a proxy payment request notification to the at least one payer terminal 100-2. there is.

Additionally, in the embodiment, the requester terminal 100-1 may perform a conditional proxy payment approval step. (S103)

In detail, in the embodiment, the requester terminal 100-1 may perform a conditional proxy payment approval process in conjunction with the payer terminal 100-2 that has received the proxy payment request notification.

Here, the conditional proxy payment approval process according to the embodiment may mean a process that designates payment to be approved according to specific conditions for the proxy payment requested by the payer.

In more detail, the payer terminal 100-2 that has received the proxy payment request notification may obtain a payer input for selecting a payment button in the received proxy payment request notification.

Then, the payer terminal 100-2 can display and provide a conditional approval window.

Here, the conditional approval window according to an embodiment of the present invention may be a user interface that determines the proxy payment allowable range (i.e. proxy payment approval conditions) based on user (here, payer) input.

In an embodiment, this conditional approval window may include a conditional interface such as a limit amount setting interface and/or a usage limit interface.

At this time, in the embodiment, the conditional approval window may support easy approval of proxy payment within the proxy payment allowable range set based on the conditional interface without requiring the payment process to authenticate the payer (e.g., entering payment password, etc.).

More specifically, in the embodiment, the payer terminal 100-2 may determine the limit amount allowed for the proxy payment according to the payer's input into the limit amount setting interface of the conditional approval window.

For example, the payer terminal 100-2 may determine the limit amount for the proxy payment based on the payer inputting a predetermined amount (eg, 100,000 won, etc.).

Additionally, in the embodiment, the payer terminal 100-2 may determine the number of uses allowed for the corresponding proxy payment based on the payer's input based on the use count limit interface of the conditional approval window.

For example, the payer terminal 100-2 may determine the number of uses allowed for the proxy payment based on the payer inputting a predetermined number of times (eg, once, etc.).

At this time, depending on the embodiment, the conditional approval window may further include an allowable time setting interface, an allowable location setting interface, and/or an allowable product setting interface as conditional interfaces.

When the conditional approval window further includes conditional interfaces as described above, the payer terminal (100-2) responds to the payer's input based on the allowable time setting interface, the allowable place setting interface, and/or the allowable product setting interface. Accordingly, it is possible to determine the time (eg, within 10 p.m., etc.), location (eg, within a specific area, etc.), and/or product (eg, food excluding alcohol, etc.) allowed for the corresponding proxy payment.

In this way, the payer terminal (100-2) provides a user interface that allows the payer to easily set conditions such as amount, number of uses, time, place, and/or product allowed, and makes proxy payments under the permissible conditions. By allowing this to proceed, it is possible to minimize the side effects of indiscriminate proxy payments and provide a proxy payment function that satisfies both the requester and the payer by reflecting the payer's wishes in detail.

In addition, depending on the embodiment, the conditional approval window may provide a basic condition form for each category in which the limit amount, number of uses, time, place, and/or product allowed for proxy payment are preset according to the predetermined category.

For example, the conditional approval window may provide the first limit amount, first number of uses, first time, first location, and/or first product pre-designated as the dinner category in the dinner category basic conditions form, As an equipment purchase category, a pre-designated second limit amount, a second number of uses, a second time, a second location, and/or a second product can be provided in the basic condition form for the equipment purchase category.

In an embodiment, the payer terminal 100-2, which provides the basic condition form for each category as described above based on the conditional approval window, may obtain a payer input for selecting at least one of the basic condition forms for each category. there is.

And the payer terminal (100-2) determines the limit amount, number of uses, time, place and/or limit amount used for the corresponding proxy payment, which is pre-specified in the category basic condition form selected according to the payer input. , can determine the frequency, time, location and/or product of use.

Through this, the payer terminal (100-2) allows the payer to make a proxy payment optimized for that category (e.g., company dinner, etc.) by simply selecting a pre-designated condition setting value for a specific category without having to manually set various conditions one by one. Convenience can be improved by automatically setting approval conditions.

At this time, depending on the embodiment, it is obvious that the conditional proxy payment approval step as described above can be applied in the same way not only in the offline proxy payment process, but also in the above-described 1:1 proxy payment process and/or 1:N proxy payment process. do.

Additionally, in the embodiment, the requester terminal 100-1 may perform a temporary payment code provision step. (S105)

Here, the temporary payment code according to the embodiment is within the range that complies with the limit amount, number of uses, time, place, and/or product conditions (i.e., proxy payment approval conditions in the embodiment) determined based on the conditional approval window. It may mean a predetermined identification code that can perform a payment function.

In an embodiment, this temporary payment code may be implemented using a barcode, QR code, Near Field Communication (NFC), and/or Radio-Frequency Identification (RFID).

Depending on the embodiment, the temporary payment code may be a predetermined identification code that can perform a payment function according to user (here, payer) input based on the proxy payment window described above. Hereinafter, the temporary payment code will be explained on the basis of performing a payment function according to user (here, payer) input based on the conditional approval window, but is not limited thereto.

In detail, the payer terminal 100-2, which has determined the proxy payment approval conditions as described above, may generate the temporary payment code that allows only payments according to the determined proxy payment approval conditions.

At this time, in the embodiment of the present invention, the method of generating the temporary payment code itself is not limited or limited, and the process of generating the temporary payment code can be implemented based on various known algorithms.

Additionally, in the embodiment, the payer terminal 100-2 may provide a proxy payment method registration interface for registering a payment method to be used in the payment process using the generated temporary payment code.

And the payer terminal 100-2 may obtain information on a predetermined payment method (e.g., credit card, etc.) based on user (here, payer) input based on the provided proxy payment method registration interface, This can be registered and stored by matching it to the temporary payment code.

Therefore, when performing an offline payment using the temporary payment code, the payer terminal 100-2 allows a payment process that follows the proxy payment approval conditions to proceed using the payment method matched to the temporary payment code. You can.

Additionally, in the embodiment, the payer terminal 100-2 may transmit and provide a temporary payment code with the payment method registered as above to the requester terminal 100-1 that has requested the proxy payment.

Thus, in the embodiment, the requester terminal 100-1 may obtain a temporary payment code that provides a payment function using the registered payment method as described above within the scope of meeting the proxy payment approval conditions specified as described above. there is.

Additionally, in the embodiment, the requester terminal 100-1 may display and output the obtained temporary payment code and provide it to the requester.

Figure 14 is an example of a diagram for explaining offline payment based on a temporary payment code according to an embodiment of the present invention.

Additionally, referring to FIG. 14, in the embodiment, the requester terminal 100-1 may perform an offline payment execution step based on a temporary payment code. (S107)

In detail, the requester terminal 100-1 that provided the temporary payment code can execute an offline payment process based on the temporary payment code.

More specifically, in the embodiment, the requester terminal 100-1 may execute an offline payment process based on the temporary payment code in conjunction with an affiliated store terminal 100-3 deployed in an offline store.

Specifically, the affiliated store terminal 100-3 of the offline store uses a predetermined identification code scanner 10 in which the affiliated store terminal 100-3 includes a temporary payment code displayed on the requester terminal 100-1. , it can be recognized using an NFC communicator and/or an RFID communicator.

When the affiliated store terminal 100-3 recognizes the temporary payment code, the requester terminal 100-1 can proceed with a payment process according to the recognized temporary payment code.

At this time, the affiliated store terminal 100-3 may provide a payment information input interface for entering payment information for the target product for which proxy payment is to be performed.

And the affiliated store terminal (100-3) makes a payment including the order number, order amount, product name, and/or affiliated store information for the target product based on the user (here, seller) input into the payment information input interface. Information can be obtained.

Accordingly, the affiliated store terminal 100-3 can perform a payment process based on the payment information obtained as above and the recognized temporary payment code.

In a specific embodiment, the affiliated store terminal 100-3 may execute the payment process and subtract the order amount of the payment information from the limit amount according to the temporary payment code.

Additionally, in an embodiment, the affiliated store terminal 100-3 may execute the payment process and deduct the number of uses according to the temporary payment code by one time.

Additionally, in the embodiment, when executing the payment process, the affiliated store terminal 100-3 may compare the allowed time according to the temporary payment code with the current time to determine whether the allowed time conditions are complied with. And, the affiliated store terminal 100-3 may execute the payment process if the allowable time condition is complied with, and may not perform the payment process otherwise.

In addition, in the embodiment, when executing the payment process, the affiliated store terminal 100-3 determines whether the permitted location conditions are met based on the permitted location according to the temporary payment code and the current location, that is, the location of the offline store. You can. Additionally, the affiliated store terminal 100-3 may execute the payment process if the permitted location conditions are met, and may not perform the payment process otherwise.

Additionally, in an embodiment, the affiliated store terminal 100-3 may execute the payment process to determine whether the allowable product according to the temporary payment code accepts the target product of the payment information. Additionally, the affiliated store terminal 100-3 may execute a payment process if the permitted product accepts the target product, and may not perform the payment process otherwise.

As such, the proxy payment service according to an embodiment of the present invention proceeds with the payment process for the target product online by using a temporary payment code that provides a payment function based on the payment method of the proxy payer during offline payment. It is possible to support easy use of the proxy payment service according to an embodiment of the present invention not only in proxy payments but also offline.

At this time, depending on the embodiment, when the requester terminal (100-1) proceeds with the payment process in conjunction with the affiliated store terminal (100-3) of the offline store, the limit amount according to the temporary payment code is set to the order amount of the target product. If this is exceeded, the excess amount can be paid on behalf of the customer based on the 1:1 proxy payment process or 1:N proxy payment process described above.

In addition, depending on the embodiment, when the requester terminal 100-1 performs a 1:1 proxy payment process or 1:N proxy payment process for the excess amount, the requester pays at least a portion of the excess amount. You can also perform a burden payment process.

At this time, the requester terminal 100-1 may determine the payment amount for each of the principal and at least one payer according to any one of the above-described equal division method, manual input division method, and/or random division method. .

In this way, the requester terminal 100-1 makes it possible to easily perform additional proxy payment and/or installment payment for the portion exceeding the amount allowed by the payer (i.e., the limit amount), thereby exceeding the limit amount. Payment for products can be effectively supported only through a series of proxy payment processes.

Meanwhile, in the embodiment, if payment according to the proxy payment approval conditions of the temporary payment code is no longer possible and there is a remaining amount on the temporary payment code, the requester terminal 100-1 collects the remaining amount. A residual amount management process may be executed to deposit money into the account of a given user (in an embodiment, the requester and/or at least one payer).

In detail, in the embodiment, the requester terminal 100-1 provides an account input interface for entering at least one account information (eg, bank name, account number, and/or account holder name, etc.) into which the remaining amount is to be deposited. can do.

Additionally, the requester terminal 100-1 may obtain at least one account information according to the requester input based on the account input interface.

Additionally, the requester terminal 100-1 may deposit the above-mentioned remaining amount into at least one account based on the obtained account information.

At this time, in the embodiment, when there is a plurality of account information, the requester terminal 100-1 distributes the remaining amount according to any one of the equal division method, manual input division method, and/or random division method to divide the remaining amount into multiple accounts. Deposits can be processed into the account.

Alternatively, depending on the embodiment, the payer terminal (100-2) that issued the temporary payment code is no longer able to make payment according to the proxy payment approval conditions of the temporary payment code and at the same time, the remaining amount on the temporary payment code is no longer possible. If present, the remaining amount may be automatically deposited into the corresponding payer's account.

In this way, the proxy payment service according to an embodiment of the present invention can prevent cash loss due to the use of temporary payment codes by paying the remaining amount in the temporary payment code that can no longer be used to the relevant users.

Additionally, in the embodiment, the requester terminal 100-1 may perform the step of providing offline payment information. (S109)

That is, in the embodiment, the requester terminal 100-1 may provide offline payment information to the requester and at least one payer when the offline payment based on the temporary payment code is completed as described above.

Here, the offline payment information according to the embodiment is information indicating the result of performing an offline proxy payment based on a temporary payment code, including payment information for the target product, payment affiliated store information, payment completion status, remaining amount, and/or remaining amount. It may include usage frequency information, etc.

In detail, in the embodiment, the requester terminal 100-1 may generate the above offline payment information when the offline payment process based on the temporary payment code is completed.

Additionally, in the embodiment, the requester terminal 100-1 may display and output the generated offline payment information and provide it to the requester.

Additionally, in the embodiment, the requester terminal 100-1 may transmit the generated offline payment information to the corresponding at least one payer terminal 100-2.

Then, the payer terminal 100-2 can provide the offline payment information to at least one payer by outputting and displaying the received offline payment information on the display.

Therefore, the proxy payment service according to an embodiment of the present invention can provide an offline proxy payment function that is more transparent, reliable, and easier to manage the payment.

As described above, in the proxy payment method and system according to an embodiment of the present invention, even if the proxy payment requester and proxy payer are located remotely from each other, the requester can request proxy payment from the payer, and the payer can make the requested proxy payment. By being able to perform payment on behalf of a person, it is possible to reach the desired payer without restrictions on time and place in various situations where proxy payment is required (e.g., absence of payment method, lack of payment amount, business necessity, and/or simple request, etc.) It has the effect of providing an environment and user interface (UI) that allows easy proxy payment requests and the payer who receives the request to easily and conveniently make proxy payments.

In addition, the proxy payment method and system according to an embodiment of the present invention provide a proxy payment function that can be implemented not only online but also offline, so that the proxy payment service can be used in any way without restrictions depending on the online or offline environment. There is an effect that can be supported.

In addition, the proxy payment method and system according to an embodiment of the present invention are safer and more just by preventing situations that cause abusing issues such as attempts to gain unfair advantage by abusing the proxy payment service. It has the effect of establishing and providing a proxy payment service environment.

In addition, the proxy payment method and system according to an embodiment of the present invention provides a split proxy payment function by multiple payers, thereby expanding the scope of use of the proxy payment function and simultaneously making proxy payments by multiple payers. It is possible to provide various types of split payment functions using the advantages of , and it also has the effect of offsetting the burden on proxy payers.

In addition, the proxy payment method and system according to an embodiment of the present invention allow the payer to conditionally allow proxy payment, thereby minimizing the side effects of indiscriminate proxy payment and also reflecting the payer's intention in detail so that both the requester and the payer can It has the effect of implementing a satisfactory proxy payment service.

Meanwhile, the embodiments according to the present invention described above can be implemented in the form of program instructions that can be executed through various computer components and recorded on a computer-readable recording medium. The computer-readable recording medium may include program instructions, data files, data structures, etc., singly or in combination. Program instructions recorded on the computer-readable recording medium may be specially designed and configured for the present invention, or may be known and usable by those skilled in the computer software field. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical recording media such as CD-ROMs and DVDs, and magneto-optical media such as floptical disks. medium), and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory 110, etc. Examples of program instructions include not only machine language code such as that created by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like. A hardware device can be converted into one or more software modules to perform processing according to the invention and vice versa.

The specific implementations described in the present invention are examples and do not limit the scope of the present invention in any way. For the sake of brevity of the specification, descriptions of conventional electronic components, control systems, software, and other functional aspects of the systems may be omitted. In addition, the connections or connection members of lines between components shown in the drawings exemplify functional connections and/or physical or circuit connections, and in actual devices, various functional connections or physical connections may be replaced or added. Can be represented as connections, or circuit connections. Additionally, if there is no specific mention such as “essential,” “important,” etc., it may not be a necessary component for the application of the present invention.

In addition, although the detailed description of the present invention has been described with reference to preferred embodiments of the present invention, those skilled in the art or those skilled in the art will understand the spirit of the present invention as described in the patent claims to be described later. It will be understood that the present invention can be modified and changed in various ways without departing from the technical scope. Therefore, the technical scope of the present invention should not be limited to what is described in the detailed description of the specification, but should be defined by the scope of the patent claims.

Claims (14)

A proxy payment method performed by a requester terminal requesting proxy payment in conjunction with a payer terminal paying for the requested proxy payment,
Requesting proxy payment for a product;
waiting for a response to the request; and
When the response is received, proceeding with the proxy payment;
The step of requesting proxy payment for the product is,
Providing a proxy payment request window for entering proxy payer information to request the proxy payment;
generating proxy payment request information based on user input based on the provided proxy payment request window;
Comprising the step of providing a proxy payment window or conditional approval window based on the generated proxy payment request information to the payer terminal.
Agent payment method. According to claim 1,
The proxy payment window is,
A user interface that determines whether to accept the proxy payment.
Agent payment method. According to claim 1,
The conditional approval window is,
A user interface that determines the acceptance conditions for the proxy payment
Agent payment method. According to clause 3,
The conditional approval window is,
Determining at least one condition among the amount, number of uses, time, place, and product to allow the proxy payment based on the user input based on the conditional approval window.
Agent payment method. According to claim 1,
The step of requesting proxy payment for the product is,
Comprising the step of providing an abusing blocking function that blocks the proxy payment when at least one of a product, affiliated store, and user set in the proxy payment request information is detected.
Agent payment method. According to claim 1,
The step of waiting for a response to the request is,
Including the step of providing a waiting screen window that displays proxy payment validity time information and progress information.
Agent payment method. According to clause 6,
The step of providing the standby screen window is,
Including providing at least one interface of a proxy payment re-request button and a proxy payment request cancellation button.
Agent payment method. According to claim 1,
The steps to proceed with the proxy payment are:
Receiving an acceptance response for the proxy payment based on a user input based on the proxy payment window or the conditional approval window;
Comprising the step of executing a payment process for the product in conjunction with the payer terminal when the acceptance response is received.
Agent payment method. According to clause 8,
The step of requesting proxy payment for the product is,
Further comprising providing the proxy payment window or conditional approval window to a plurality of the payer terminals.
Agent payment method. According to clause 9,
The steps to proceed with the proxy payment are:
When the acceptance response is received from all of the plurality of payer terminals, further comprising executing a payment process for the product in conjunction with the plurality of payer terminals.
Agent payment method. According to claim 10,
The step of requesting proxy payment for the product is,
Further comprising requesting the plurality of payer terminals to split the proxy payment amount for the product according to a predetermined method.
Agent payment method. According to claim 1,
The steps to proceed with the proxy payment are:
Receiving an acceptance response for the proxy payment based on a user input based on the proxy payment window or the conditional approval window;
When the acceptance response is received, comprising providing a temporary payment code that executes a payment function according to the user input.
Agent payment method. at least one memory storing a proxy payment application; and
At least one processor that reads the proxy payment application stored in the memory and performs a proxy payment method,
The command of the proxy payment application is,
A step of requesting proxy payment for the product,
waiting for a response to the request;
When the response is received, proceeding with the proxy payment;
Providing a proxy payment request window for entering proxy payer information to request the proxy payment;
generating proxy payment request information based on user input based on the provided proxy payment request window;
Including a command for performing the step of providing a proxy payment window or a conditional approval window based on the generated proxy payment request information to the payer terminal.
Agent payment system. at least one memory module; and
At least one processor module;
The processor module is,
Request proxy payment for the product,
Wait for a response to the above request,
When the response is received, the proxy payment is made,
Providing a proxy payment request window to the requester terminal to input the proxy payer information requesting the proxy payment,
Generate proxy payment request information based on user input based on the proxy payment request window provided above,
Providing a proxy payment window or conditional approval window based on the generated proxy payment request information to the payer terminal.
Payment service provider server.