KR102181317B1 - Method for providing settlement service for payment amount and payment gateway server thereof - Google Patents

Abstract

The present invention relates to a payment settlement service providing method and a payment proxy server performing the same, the method comprising: generating purchase request data including at least one transaction details approved by a card company; Transmitting the generated purchase request data to a card company server; Generating deposit prediction data including an expected deposit amount for transaction details based on the transmitted purchase request data; Receiving, from a card company server, purchase result data including a scheduled payment date and a planned deposit amount for transaction details included in the purchase request data; Processing the generated deposit prediction data and the purchase result data received from the card company server to confirm whether or not they match; Collecting passbook deposit data including deposit details for transaction details included in purchase request data from a bank server; And processing the bankbook deposit data collected from the bank server and the purchase result data received from the credit card company server to confirm whether they match.

Description

Method of providing payment settlement service and payment agency server that performs it {METHOD FOR PROVIDING SETTLEMENT SERVICE FOR PAYMENT AMOUNT AND PAYMENT GATEWAY SERVER THEREOF}

The present invention relates to a method of providing a payment settlement service in a payment proxy server such as a payment gateway (PG).

Mobile payment is a technology that purchases products or services online or offline through mobile devices such as mobile phones, smartphones, and tablet PCs. There are largely a method of using short-range communication such as NFC and a method of using the cloud.

In general, in the mobile payment method, payment is generally made through a payment gateway (PG) between a portable terminal and a card company server.

PG (Payment Gateway) refers to a service that receives commissions from a lower shopping mall after signing a contract with a credit card company and a representative affiliate store on behalf of a small and medium-sized shopping mall where it is difficult to sign a contract with a credit card company, and paying and paying by credit card as an agent.

On the other hand, in recent years, the number of channels for payment by affiliates is rapidly increasing due to the increase in the number of affiliated stores for each purpose such as simple payment by each card company and the emergence of various payment companies.

In particular, large merchants such as PG and open markets, which have to provide various payment methods, must operate a large number of merchant numbers for each purpose for the payment received from each card company, and the deposit channel is complicated. As a result, the difference between the payment schedule and the actual amount deposited in the bankbook frequently occurs, making it very difficult to manage the payment confirmation of the affiliated store.

Patent Document 1: Registered Patent Publication No. 10-1348363 (registered on December 30, 2013)

An object of the present invention is to provide a payment settlement service that enables effective settlement of the transaction price paid through various means, and a payment proxy server performing the same.

A method for providing a payment settlement service according to an embodiment of the present invention includes the steps of: generating purchase request data including at least one transaction details provided by a payment agency server and approved by a card company; Transmitting the generated purchase request data to a card company server; Generating deposit prediction data including an estimated deposit amount for the transaction details based on the transmitted purchase request data; Receiving, from the card company server, purchase result data including a scheduled deposit date and a deposit amount for the transaction details included in the purchase request data; Processing the generated deposit predicted data and the purchase result data received from the card company server to confirm whether or not they match; Collecting, from a bank server, bankbook deposit data including deposit details for transaction details included in the purchase request data; And processing the bankbook deposit data collected from the bank server and the purchase result data received from the card company server to confirm whether they match.

The payment agency server according to an embodiment of the present invention generates purchase request data including at least one transaction details approved by a card company, and calculates an estimated deposit amount for the transaction details based on the transmitted purchase request data. A data generation unit that generates deposit prediction data including; A communication unit that transmits the generated purchase request data to a card company server, and receives purchase result data from the card company server, including a scheduled deposit date and a scheduled deposit amount for transaction details included in the purchase request data; A scraping processing unit collecting passbook deposit data including deposit details for transaction details included in the purchase request data from a bank server; And processing so that it is possible to check whether the generated deposit expected data and the purchase result data received from the card company server match, and whether the passbook deposit data collected from the bank server and the purchase result data received from the card company server match. It includes; a control unit processing to be able to check.

Meanwhile, the method of providing payment settlement service may be implemented as a computer-readable recording medium in which a program for execution on a computer is recorded, and may be provided as a program itself.

According to an embodiment of the present invention, it is possible to settle the payment price by comparing the payment prediction data based on the purchase request data, the purchase result data received from the card company server, and the passbook deposit data collected from the bank server, so that it is more accurate. And quickly verify payments automatically.

In addition, according to another embodiment of the present invention, the purchase of a card company is held by applying a pre-set unpaid offset logic to an unacceptable affiliate store number that has a greater amount of cancellation than the transaction amount, through another affiliate store number. It is possible to prevent such problems in advance, and thereby reduce the difficulty of settlement due to inconsistency of the payment price.

1 is a block diagram showing the configuration of a payment agency system according to an embodiment of the present invention.
2 is a block diagram showing the configuration of a payment proxy server according to an embodiment of the present invention.
3 is a flowchart illustrating an embodiment of a method for providing a payment settlement service according to the present invention.
4 is a timing diagram illustrating an embodiment of a method of calculating a payment amount in a payment agency system according to the present invention.
5 and 6 are diagrams for explaining embodiments of a configuration of a user interface provided for settlement of a payment price.

The following content merely illustrates the principles of the present invention. Therefore, those skilled in the art can implement the principles of the present invention and invent various devices included in the concept and scope of the present invention, although not clearly described or illustrated herein. In addition, it is understood that all conditional terms and examples listed in this specification are, in principle, expressly intended only for the purpose of making the concept of the present invention understood, and are not limited to the embodiments and states specifically listed as such. Should be.

In addition, it is to be understood that all detailed descriptions listing specific embodiments as well as principles, aspects and embodiments of the present invention are intended to include structural and functional equivalents of these matters. In addition, these equivalents should be understood to include not only currently known equivalents, but also equivalents to be developed in the future, that is, all devices invented to perform the same function regardless of structure.

Thus, for example, the block diagrams herein are to be understood as representing a conceptual perspective of exemplary circuits embodying the principles of the invention. Similarly, all flowcharts, state transition diagrams, pseudocodes, etc. are understood to represent various processes performed by a computer or processor, whether or not the computer or processor is clearly depicted and that can be represented substantially in a computer-readable medium. Should be.

The functions of the various elements shown in the figures, including a processor or functional block represented by a similar concept, may be provided by the use of dedicated hardware as well as hardware having the ability to execute software in association with appropriate software. When provided by a processor, the function may be provided by a single dedicated processor, a single shared processor, or a plurality of individual processors, some of which may be shared.

In addition, the explicit use of terms presented as processor, control, or similar concepts should not be interpreted exclusively as quoting hardware capable of executing software, but for storing digital signal processor (DSP) hardware, software without limitation. It should be understood to implicitly include ROM, RAM and non-volatile storage. Other commonly used hardware may also be included.

The above-described objects, features, and advantages will become more apparent through the following detailed description in connection with the accompanying drawings, whereby those of ordinary skill in the technical field to which the present invention pertains can easily implement the technical idea of the present invention. There will be. In addition, in describing the present invention, when it is determined that a detailed description of a known technology related to the present invention may unnecessarily obscure the subject matter of the present invention, a detailed description thereof will be omitted.

Hereinafter, a method of providing a payment settlement service according to an embodiment of the present invention and a payment proxy server performing the same will be described in detail with reference to the accompanying drawings.

1 is a block diagram showing the configuration of a payment agency system according to an embodiment of the present invention, and the system 10 includes a payment agent server 100, a payment terminal 200, and a card company server 300 Can be.

Referring to FIG. 1, the payment agent server 100, the payment terminal 200, and the card company server 300 are connected to each other using a communication network to transmit and receive data, and the communication network is a local area network (LAN), a communication network in a city area. It can be composed of various wired or wireless communication networks such as (MAN: Metropolitan Area Network) and WAN: Wide Area Network.

The payment agency server 100 may play a role of acting as an agent for a card payment service between the payment terminal 200 and the card company server 300, and specifically, a server operated by a PG company that provides a PG (Payment Gateway) service. Can be

Here, the PG service refers to a service that receives a commission from a lower shopping mall after signing a contract with a card company and a representative affiliate store on behalf of a small and medium-sized shopping mall where it is difficult to sign a contract with a credit card company, and paying and paying by credit card as an agent.

To this end, the PG company that operates the payment proxy server 100 may enter into an alliance contract with the card company that operates the card company server 300 to relay the card payment process between its affiliated sub-affiliate store and the card company.

Meanwhile, in the present invention, the term payment by card may mean payment performed using all cards that can be issued to a user by a credit card company or a financial company such as a credit card, a debit card, or a debit card.

In addition, the payment proxy server 100 may provide a payment settlement service according to an embodiment of the present invention in addition to the payment proxy service for a lower affiliated store as described above.

The payment proxy server 100 may include information on a corresponding lower affiliated store in the card payment request signal received from the payment terminal 200 and then transmit it to the card company server 300, thereby allowing the card company server 300 to It is possible to determine whether or not to approve the card payment request based on the information of the lower affiliated store.

Meanwhile, the payment terminal 200 may be a terminal that transmits a card payment request signal for goods and services sold by a lower affiliated store to the payment proxy server 100.

For example, the payment terminal 200 is a mobile phone, a smart phone, a personal digital assistant (PDA), a portable multimedia player (PMP), a tablet PC, a desktop PC, a tablet PC, a laptop PC, an IPTV including a set-top box, and a card payment terminal. And the like, but the present invention is not limited thereto, and may be various types of devices that can be connected to an external server such as the payment proxy server 100 through a communication network.

The payment terminal 100 may be installed with a card payment application capable of performing card payment for products and services sold by lower affiliates. At this time, the card payment application is a program module capable of communicating with an external server and an external device, and may be included in the payment terminal 100 or another device capable of communicating with the payment terminal 100 in the form of an operating system, an application program module, and other program modules, Physically, it can be stored on various known storage devices.

On the other hand, such a program module includes, but is not limited to, routines, subroutines, programs, objects, components, data structures, etc. that perform specific tasks to be described later or execute specific abstract data types according to the present invention.

The card company server 300 may be a server operated by a card company that performs a process of finally accepting a card payment requested by a PG (Payment Gateway) company, which is its affiliated store, and settling a payment amount.

The card company server 300 may receive a signal from the payment agency server 100 to request approval of a card payment occurring at a lower affiliated store contracted with the corresponding PG company.

Here, the card payment request signal is information on lower affiliate stores such as ID information, address information, business operator information, representative information, deposit account information, payment request transmission location information, existing payment details information, and payment item information of the corresponding card payment. It may be a full text of a card payment approval request including payment request details information such as payment amount information, use card information, and the like.

The card company server 300 responds to the full card payment approval request received from the payment proxy server 100, determines whether or not to approve the card payment for the transaction details, and then sends the full card payment approval result including information on the approval result. It can be generated and transmitted to the payment agency server 100.

As described above, the transaction details information requested by the lower affiliated store and approved by the credit card company is stored in the database of the payment agent server 100, and purchase request data including transaction details stored in the database is sent to the payment agent server 100 at regular intervals. ) May be generated and transmitted to the card company server 200.

For example, the payment agency server 100 generates purchase request data including transaction details approved by the card company on a daily basis and transmits it to the card company server 300, and the card company server 300 is included in the purchase request data. It is possible to determine whether to normally purchase or refuse to purchase for each transaction details, and calculate the expected deposit date and the estimated deposit amount for the normally purchased transaction details.

The card company server 300 generates purchase result data including a scheduled deposit date and a planned deposit amount for the calculated transaction details, along with a normal purchase or refusal result for the transaction details included in the purchase request data, and make payment. It can be transmitted to the proxy server 100.

According to an embodiment of the present invention, the payment agency server 100 compares the payment prediction data based on the purchase request data, the purchase result data received from the card company server, and the passbook deposit data collected from the bank server to compare the payment price. By enabling settlement, it is possible to automatically verify payments more accurately and quickly.

Hereinafter, a method for providing a payment settlement service according to an embodiment of the present invention and a payment proxy server performing the same will be described in more detail with reference to FIGS. 2 to 6.

2 is a block diagram showing the configuration of a payment proxy server according to an embodiment of the present invention, and the illustrated payment proxy server 100 includes a data generating unit 110, a communication unit 120, a scraping processing unit 130, It may be configured to include the control unit 140 and the storage unit 150.

Referring to FIG. 2, the data generation unit 110 generates purchase request data including at least one transaction details approved by a card company, and calculates an estimated deposit amount for the transaction details based on the transmitted purchase request data. Generate deposit prediction data including.

Here, the data generation unit 110 may generate purchase request data including information on each of the transaction details generated on a daily basis by aggregating transaction details approved for card payment on a daily basis.

For example, the data generation unit 110, for each of the transaction details that occurred from 0 o'clock to 24 o'clock on the day, part (or all) of the card number from the transaction details database, the payment approval date and time, the payment approval amount, the lower affiliated store Purchase request data including the above information may be generated by reading information, payment approval information, and slip identification information.

In addition, the data generation unit 110, for each of the transaction details included in the purchase request data, applies a preset contract fee rate for each transaction to the purchase amount, calculates an amount deducting the fee, and generates the deposit prediction data. I can.

For example, the payment fee applied for each transaction may be different depending on the business type of the lower affiliated store using PG, the product or service to be traded, the amount purchased, the payment method, the credit card company, etc., and accordingly, the data generator 110 The deposit prediction data may be generated by calculating an actual deposit amount from a credit card company obtained by subtracting a commission from the purchase amount for each of the transaction details that are aggregated in units and included in the purchase request data.

The communication unit 120 transmits the purchase request data generated by the data generation unit 110 to the card company server 300, and purchases including a scheduled deposit date and a scheduled deposit amount for each of the transaction details included in the purchase request data. The result data is received from the card company server 300.

The purchase result data received from the card company server 300 may include a normal purchase or purchase refusal result for each of the transaction details included in the purchase request data, for example, a plurality of affiliate store numbers used for card payment. If an unacceptable occurrence is expected for a specific affiliated store number, the purchase of at least some of the transaction details approved for payment with the affiliated store number may be rejected by the card company server 300, due to various reasons other than the possibility of the occurrence Purchase of some transaction details may be rejected.

The scraping processing unit 130 collects passbook deposit data including deposit details for transaction details included in the purchase request data from a bank server (not shown).

The scraping processing unit 130 may directly access the bank server through the communication unit 120 to collect the bankbook deposit data, but the present invention is not limited thereto, and the scraping processing unit 130 is an external scraping server (not shown). Through the passbook deposit data may be collected.

Meanwhile, the scraping processing unit 130 may use a method such as web scraping or screen scraping to obtain the bankbook deposit data, but the present invention is not limited thereto, and various known scraping methods Can be used.

Here, scraping refers to a technology for receiving arbitrary services provided on a web basis without the user's web browsing. Therefore, a user receiving a service to which web scraping technology is applied can obtain desired data without repetitive web browsing, and in some cases, distributed web services can be integrated and provided. In other words, the user can collect and receive various information provided from various types of services through the service to which the web scraping technology as described above is applied.

As described above, the data extracted by web scraping can be stored in other programs or databases and then viewed or used whenever necessary, and the extracted data are used as comparative analysis data.

These web scraping programs are based on the technology that collects necessary information from the website, the technology that converts it to a certain format, and the scraping driving technology, and these web scraping programs are installed and run on the server or installed on the client. Or, it takes a method that is installed and operated in a mixture of server and client.

This web scraping technology is mainly used to collectively search information on personal financial assets or to manage transaction details, or to collect information such as travel agencies, airlines, hotels and logistics services, weather, news, etc. It is also used for purposes.

The control unit 140 processes the payment prediction data generated by the data generation unit 110 and the purchase result data received from the card company server 300 to be able to check whether or not, and the passbook deposit data collected through web scraping and the card company It may be processed to be able to confirm whether the purchase result data received from the server 300 matches.

The transaction details in which the above confirmation result, deposit expected data, bankbook deposit data, and purchase result data match each other are automatically settled, and for the transaction details where the deposit expected data, bankbook deposit data, and purchase result data match each other, the user A user interface (UI) may be provided to allow direct confirmation of the user.

Meanwhile, the storage unit 150 of the payment proxy server 100 may include a transaction history database as described above, but the present invention is not limited thereto, and the transaction history database is separately provided outside the payment proxy server 100 It could be.

3 is a flowchart illustrating an embodiment of a method for providing a payment settlement service according to the present invention. A description of the same as described with reference to FIGS. 1 and 2 among the illustrated payment settlement service providing method will be described below. I will omit it.

Referring to FIG. 3, the data generation unit 110 of the payment agency server 100 generates purchase request data including at least one transaction details approved by the card company (step S310), and the communication unit 120 performs the S310 The purchase request data generated in step is transmitted to the card company server 300 (step S320).

As described above, the data generation unit 110 checks information on each of the transaction details approved for card payment from 0 o'clock to 24 o'clock on a daily basis from the transaction details database, Purchase request data including a number (part or all), payment approval date and time, payment approval amount, lower affiliated store information, payment approval information, and slip identification information may be generated.

The data generation unit 110 calculates an estimated deposit amount for each transaction details generated on a daily basis based on the purchase request data generated on a daily basis and transmitted to the card company server 300 to generate the expected deposit data. Generate (S330 step).

For example, the data generation unit 110 checks the fee rate applied for each transaction by referring to the contract fee data stored in the storage unit 150, and applies the fee rate to the purchase amount according to the transaction details, so that the fee is deducted. The actual amount of credit card companies can be calculated.

The communication unit 120 receives purchase result data from the card company server 300 including a normal purchase or refusal result for each of the transaction details included in the purchase request data, a scheduled deposit date, and a planned deposit amount (step S340). .

Thereafter, the control unit 140 checks whether the deposit prediction data generated in the step S330 and the purchase result data received from the card company server 300 in the step S340 match (step S350).

For example, the control unit 140 of the payment agency server 100 is approved for card payment on a daily basis, so that the expected deposit data and the purchase result data are connected and displayed for each of the transaction details included in the purchase request data. Processing, and accordingly, the payment prediction data and the purchase result data connected to each other in a terminal (not shown) capable of communicating with the payment proxy server 100 may be displayed.

The terminal capable of communicating with the payment proxy server 100 may be a dedicated terminal for settlement of PG, which operates the payment proxy server 100, but the present invention is not limited thereto, and the right to check whether the expected payment data and the purchase result data match. It may be a terminal of a user with.

Meanwhile, the control unit 140 may process the transaction details in which the deposit prediction data and the purchase result data do not match each other so that the user can be checked and displayed.

Accordingly, the user in charge of the settlement of the PG company can easily check whether the deposit prediction data calculated internally and the purchase result data received from the card company server 300 are identical to each other, and whether the deposit date and deposit amount are the same for each transaction. , For transaction details in which the deposit date or deposit amount do not match each other, it is possible to easily determine the cause of the discrepancy through a separate follow-up check.

The scraping processing unit 130 collects passbook deposit data including deposit details for transaction details included in the purchase request data from the bank server (step S360).

As described above, the scraping processing unit 130 may obtain the bankbook deposit data by collecting details deposited to one or more card company settlement accounts on a daily basis or a shorter period, either directly or through an external separate scraping server. have.

The control unit 140 processes the passbook deposit data collected from the bank server and the purchase result data received from the card company server 300 to be able to check whether or not they match (step S370).

For example, the control unit 140 of the payment agency server 100 is approved for card payment on a daily basis so that for each of the transaction details included in the purchase request data, the passbook deposit data and the purchase result data are connected and displayed. Processing, and accordingly, passbook deposit data and purchase result data connected to each other in a terminal (not shown) capable of communicating with the payment proxy server 100 may be displayed.

The terminal capable of communicating with the payment proxy server 100 may be a terminal dedicated to settlement of PG that operates the payment proxy server 100, but the present invention is not limited thereto, and the right to check whether the bankbook deposit data and the purchase result data match It may be a terminal of a user with.

Meanwhile, the control unit 140 may process the transaction details in which the passbook deposit data and the purchase result data do not match each other so that the user can be identified and displayed.

Accordingly, the user in charge of settlement of the PG company can easily check whether the deposit date and amount of each transaction are actually the same as the bankbook deposit data actually deposited in the bankbook and the purchase result data received from the card company server 300 are identical. In addition, for transaction details in which the deposit date or deposit amount does not coincide with each other, it is possible to easily determine the cause of the discrepancy through a separate follow-up confirmation.

The payment agency server 100 may use a plurality of affiliated store numbers to approve card payment for transactions occurring in lower affiliated stores, and credit card payment approval to the card company server 300 using any one of the plurality of affiliated store numbers Can be requested.

For example, the payment agency server 100 selects any one of a plurality of affiliate store numbers according to the business type of the lower affiliate store in which the transaction occurs, the product or service to be traded, the amount purchased, the payment method, the card company, etc., and the corresponding affiliate store number and Together, a full copy of the card payment approval request including information on the transaction details may be generated and transmitted to the card company server 300.

Accordingly, the purchase request data, the deposit prediction data, the purchase result data, and the bankbook deposit data as described above may be aggregated, generated, and verified for each affiliate store number.

On the other hand, for some of the plurality of affiliated store numbers, there may be a possibility of an unreceived occurrence at the time of purchase request.For example, for an affiliated store number with a cancellation amount greater than the transaction amount, the card company server 300 may display at least some of the corresponding transaction details. There is a possibility that an attempt may occur due to refusal to purchase.

According to another embodiment of the present invention, by applying a preset unpaid offset logic for an unacceptable affiliate store number that has a higher cancellation amount than the transaction amount, the purchase settlement is made through another affiliate store number, thereby preventing the purchase of a card company. This can be prevented in advance, and the difficulty of settlement due to inconsistency of payments can be reduced.

4 is a timing diagram illustrating an embodiment of a method of calculating payment in a payment agency system according to the present invention, and a description of the same as described with reference to FIGS. 1 to 3 among the illustrated methods will be omitted below. I will do it.

Referring to FIG. 4, the PG company server 100, which is a payment proxy server, receives a card payment request for a transaction occurring in a lower affiliated store from the payment terminal 100, and generates a full card payment approval request for the transaction It transmits to the server 300 (step S401), and receives the full text of the card payment approval result transmitted from the card company server 300 in response thereto (step S402)

In the step S401, the PG company server 100 selects an affiliate store number to be settled for the transaction according to a preset criterion from among a plurality of affiliate store numbers contracted with a card company, and stores the selected affiliate store number and corresponding transaction details information. It is possible to generate a full copy of the card payment approval request including.

The information on the transaction details approved for the card payment is stored in the transaction details database of the PG company server 100 and can be managed for each affiliate store number.

On the other hand, as of 24 o'clock (midnight), the PG company server 100 checks the transaction details approved for card payment on the day from the transaction details database, and generates purchase request data including information on the transaction details on the day (S403 Step), the generated purchase request data is transmitted to the card company server 300 (step S404).

As described above, the purchase request data may be configured for each affiliate store number used for card payment approval, and accordingly, the PG company server 100 checks whether or not an attempt has occurred for each affiliate store number (step 405).

For example, there may be a case in which the total purchase amount of transactions approved for card payment with a specific merchant number on the day of the day is less than the total amount of transactions canceled by card payment with the corresponding merchant number. As a result, it can be determined as an affiliate store number that is likely to be unsuccessful.

As described above, the PG company server 100 generates deposit prediction data by applying a pre-set unaccepted processing logic to the affiliate store number that may be unacceptable as described above (step S406).

Meanwhile, the card company server 300 generates purchase result data based on the purchase request data and transmits it to the PG company server 100 (step S407).

Here, the unaccepted processing logic may have been previously negotiated with the credit card company for the object and method to be applied, and accordingly, the same unaccepted processing logic is generated by the PG company server 100 and the purchase request data of the card company server 300 It is applied to the creation process so that there are no errors in the process of confirming whether the data matches later.

For example, when it is said that the unaccepted processing logic is applied to a first affiliate store number that has a greater cancellation amount than the transaction amount approved for card payment on the same day, the first affiliate store number selected from among a plurality of affiliate store numbers according to a preset condition With respect to the transaction details approved by the card company by using, the expected deposit amount for the corresponding transaction details may be calculated as the expected deposit amount corresponding to the second merchant number different from the first merchant number.

That is, in the process of calculating the estimated deposit amount, the difference between the transaction amount for the first merchant number and the cancellation amount is processed to be deducted from the estimated amount for deposit for the second merchant number, so that no attempts at the first merchant number occur. And, accordingly, it is possible to eliminate the possibility of a settlement error due to the occurrence of an attempt.

According to an embodiment of the present invention, the second affiliate store number is an affiliate store number set in advance between a card company, and more specifically, a representative affiliate store number that is unlikely to occur due to the most transactions among a plurality of affiliate store numbers. Can be

Taking this case as an example and explaining in more detail about the unaccepted processing logic according to an embodiment of the present invention, if it is determined that there is a possibility of an unrequested occurrence in data from a specific affiliate store number, the PG company server 100 By deducting the difference between the transaction amount based on the day and the cancellation amount identified in the number from the total purchase amount based on the day of the card company and the representative affiliate store number set in advance, the offset processing between the affiliated store numbers can be automatically performed.

Accordingly, the estimated amount of deposit for the unaccounted affiliate store number is '0 won', and the actual unaccounted amount for the unaccepted affiliate store number may be deducted from the representative affiliate store number.

As described above, the unaccepted processing logic using the representative affiliate store number is the process of generating the expected deposit data by calculating the expected deposit date and the estimated amount of the deposit by the PG company server 100 in the PG company server 100 as described above, and the affiliate store in the card company server 300 The same is applied in the process of generating the purchase result data by determining whether to purchase the transaction details for each number, so that it is possible to easily check whether or not the data are matched during the subsequent settlement.

According to another embodiment of the present invention, the second affiliated store number to which the receivable is automatically offset may be included in purchase request data along with transaction details and transmitted to the card company server 300 in step S404.

Taking the above case as an example and explaining in more detail the unrequested processing logic according to another embodiment of the present invention, if it is determined that there is a possibility of an unrequested occurrence in data from a specific affiliate store number, the PG company server 100 Among the affiliated store numbers, check the affiliate store number (more preferably, the affiliate store number with the largest total purchase amount on the day of the day), and select it as the unaccepted offset affiliate store number, and the selected unaccounted offset affiliate store number. The information about the transaction may be included in the purchase request data for the transaction details and transmitted to the card company server 300.

In this case, the difference between the transaction amount based on the day and the cancellation amount identified in the unreceived affiliate number is deducted from the total purchase amount based on the day of the unreceived offsetting affiliate number selected as above, and offset processing between the affiliated store numbers is automatically performed. The server 300 may also deduct the actual unaccounted amount for the unaccounted affiliate store number from the total purchase amount of the unaccepted offset affiliate store number transmitted together with the purchase request data.

Thereafter, the PG company server 100 compares whether the deposit prediction data generated in the step S406 matches the purchase result data received in the step S407, and displays them by connecting them according to the comparison result (step S408).

The PG company server 100 requests the bank server 400 to collect bankbook deposit data including details deposited to the deposit account for a specific period (step S409), and the bankbook deposit data is collected through web scraping (step S410 ).

Thereafter, the PG company server 100 compares whether the bankbook deposit data collected in step S410 and the purchase result data received in step S407 are matched, and displays them by connecting them according to the comparison result (step S411).

According to the display result, the transaction details that do not match each other among the expected deposit data, the bankbook deposit data, and the purchase result data are processed to enable user confirmation (step S412).

5 and 6 are diagrams illustrating exemplary embodiments of the configuration of a user interface provided for settlement of payment.

Referring to FIG. 5, a user interface 500 provided for settlement of payments may be provided through a screen of a terminal capable of communicating with the PG company server 100.

The user selects "inquire deposit date" using the first selection window 510, sets the deposit date using the second selection windows 520 and 521, and selects each payment method through the third selection window 530. After selecting a deposit account, selecting a payment company through the fourth selection window 540, and selecting an affiliate number or CP ID for each purpose through the fifth selection window 550, and then pressing the "Inquiry" button 580 Data metabolism for each transaction can be performed.

On the other hand, the sixth selection window 560 is selected to be displayed on the screen only for the transaction details for which settlement has been completed, or through the check box 570, it is coincident with each other among the expected deposit data, the bankbook deposit data, and the purchase result data. You can also choose to display only transactions that have not been made.

When the user selection as described above is completed, as shown in FIG. 6, the expected deposit data, the bankbook deposit data, and the purchase result data on the screen of the terminal may be compared by transaction details and provided to the user.

As shown in FIG. 6, for each transaction details, a deposit date and time, an expected deposit date, and an actual deposit date may be displayed, and the deposit amount and the expected deposit amount may be compared and displayed.

On the other hand, if the estimated deposit date and the actual deposit date, and the deposit amount and the expected deposit amount coincide with each other, the deposit registration is completed, and a confirmation button 610 is displayed on the screen so that the user's detailed information can be checked only for transactions that do not match each other. Can be displayed.

At least some of the above-described methods according to an embodiment of the present invention may be produced as a program for execution in a computer and stored in a computer-readable recording medium. Examples of computer-readable recording media include ROM, There may be RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc.

The computer-readable recording medium is distributed over a computer system connected through a network, so that computer-readable codes can be stored and executed in a distributed manner. In addition, functional programs, codes and code segments for implementing the method can be easily deduced by programmers in the art to which the present invention belongs.

In addition, although the preferred embodiments of the present invention have been illustrated and described above, the present invention is not limited to the specific embodiments described above, and the technical field to which the present invention belongs without departing from the gist of the present invention claimed in the claims. In addition, various modifications can be implemented by those of ordinary skill in the art, and these modifications should not be individually understood from the technical spirit or prospect of the present invention.

Claims (14)

In the method of providing a payment settlement service in a payment agency server,
Generating purchase request data including at least one transaction details approved by the card company and transmitting it to the card company server;
Generating deposit prediction data including an estimated deposit amount for the transaction details, based on the purchase request data;
Receiving, from the card company server, purchase result data including a scheduled deposit date and a scheduled deposit amount for the transaction details included in the purchase request data;
Processing the generated deposit predicted data and the purchase result data received from the card company server to confirm whether or not they match;
Collecting, from a bank server, bankbook deposit data including deposit details for transaction details included in the purchase request data; And
Processing the bankbook deposit data collected from the bank server and the purchase result data received from the card company server so that it is possible to check whether or not match is possible; and
The transaction details are approved by the card company using the first affiliated store number selected from among a plurality of affiliated store numbers according to a preset condition,
The expected deposit amount for the transaction details is calculated as the expected deposit amount corresponding to the second affiliated store number different from the first affiliated store number,
The purchase request data includes the second affiliate store number along with the transaction details
How to provide payment settlement service. The method of claim 1, wherein generating the deposit prediction data comprises:
A method for providing a payment settlement service comprising: calculating an amount obtained by subtracting the commission by applying a preset contract fee rate for each transaction to the purchase amount according to the transaction details. The method of claim 1, wherein the purchase result data is
A method of providing a payment settlement service including a result of normal purchase or refusal of purchase for the transaction details included in the purchase request data. The method of claim 1,
For each of the approved transaction details, the deposit prediction data and the purchase result data are connected to each other and displayed,
A method of providing a payment settlement service in which the transaction details in which the expected payment data and the purchase result data do not match each other are distinguished and displayed to enable user confirmation. delete The method of claim 1, wherein the first affiliate store number is
A method of providing payment settlement service, which is an affiliate store number with a higher cancellation amount than the approved transaction amount using the affiliate store number. The method of claim 6,
Processing the difference between the transaction amount and the cancellation amount for the first affiliated store number to be deducted from the estimated amount of deposit for the second affiliated store number; and further comprising a. The method of claim 1, wherein the second affiliate store number is
A method of providing a payment settlement service, which is an affiliate store number set in advance between the card company. delete The method of claim 1,
For each of the approved transaction details, the bankbook deposit data and the purchase result data are processed to be connected and displayed,
Completion of settlement processing for the transaction details in which the deposit prediction data, the purchase result data, and the bankbook deposit data match each other; and a payment settlement service providing method further comprising. In the payment agency server for providing a payment settlement service,
A data generator for generating purchase request data including at least one transaction details approved by a credit card company, and generating deposit prediction data including an estimated deposit amount for the transaction details based on the purchase request data;
A communication unit that transmits the generated purchase request data to a card company server, and receives purchase result data from the card company server, including a scheduled deposit date and a scheduled deposit amount for transaction details included in the purchase request data;
A scraping processing unit collecting passbook deposit data including deposit details for transaction details included in the purchase request data from a bank server; And
Process so that it is possible to check whether the generated deposit prediction data matches the purchase result data received from the card company server, and check whether the passbook deposit data collected from the bank server and the purchase result data received from the card company server match. Includes; a control unit processing to be possible,
The transaction details are approved by the card company using the first affiliated store number selected from among a plurality of affiliated store numbers according to a preset condition,
The expected deposit amount for the transaction details is calculated as the expected deposit amount corresponding to the second affiliated store number different from the first affiliated store number,
The purchase request data includes the second affiliate store number along with the transaction details
Payment proxy server. delete The method of claim 11, wherein the first affiliate store number is
It is an affiliate store number with more cancellation amount than the approved transaction amount using the affiliate store number,
The control unit
A payment agency server that processes so that the difference between the transaction amount and the cancellation amount for the first affiliated store number is deducted from the estimated amount of deposit for the second affiliated store number. The method of claim 11, wherein the second affiliate store number is
A payment agency server that is an affiliate store number set in advance between the card company, or is included in the purchase request data together with the transaction details and transmitted to the card company server.

Images