JP7228350B2 - Payment intermediary system and program - Google Patents

Description

TECHNICAL FIELD The present invention relates generally to a settlement system and the like for settlement via a communication line, and more particularly to a settlement intermediation system and the like that supports so-called deferred payment settlement.

Conventionally, there have been provided technologies related to payment systems that perform payment processing with user terminals via communication lines such as the Internet.

For example, a settlement system using mobile phone terminals via the Internet has been proposed (Patent Document 1).

That is, in Patent Document 1, in a payment system using a website and a mobile phone terminal capable of transmitting information via the Internet, a means for accepting registration application data transmitted from the mobile phone terminal and a method for accepting the registration application data A website equipped with means for issuing an ID number and returning it to the mobile phone terminal, an account in a financial institution, and a transfer amount transferred to the account by specifying the ID number as a balance in association with the ID number. a stored balance database, and when there is a request to confirm the balance regarding the payment amount by specifying the ID number in a transaction at the virtual shop, the balance database is referred to based on the ID number, and the result of the balance confirmation is sent to the virtual shop. a payment means for updating said balance database based on said payment amount, transmitting sales data to a credit card company, and executing payment processing for said payment amount in response to a request from said credit card company; A payment system using a mobile phone terminal is disclosed.

In addition, improvements were made in light of the fact that the cardholder was not confirmed when making payments with a postpaid card, and that the prepaid card system and postpaid card system could not be used properly according to the user. A billing system has also been proposed (Patent Document 2).

That is, Patent Document 2 discloses a billing system for updating a payment amount for a postpaid card storing payment amount data, which includes a personal identification card on which personal identification data is recorded, and the personal identification card of the personal identification card. a reader/writer for reading identification data and recording it inside, and recording the personal identification data on the postpaid card; and a card timer for reading the personal identification data on the personal identification card and recording it inside. and the card timer reads the personal identification data from the postpaid card, compares it with the personal identification data recorded therein, and adds the payment amount to the payment amount data only when they match. and the reader/writer displays the payment amount data stored in the postpaid card.

In addition, when allowing users who are not in a situation where credit is granted to use a payment method that can be used in the same system as a credit card, we will propose a device that aims to reduce the risk on the part of the credit card company. (Patent Document 3).

That is, Patent Document 3 discloses an acquisition unit that acquires the prepaid amount that a user paid in advance when applying for use of a credit-based deferred payment service, and a user that has paid the prepaid amount acquired by the acquisition unit. A generating unit that generates a first ID to be specified in a postpaid service, an available amount determined based on the prepaid amount acquired by the acquiring unit, and the first ID generated by the generating unit are associated. a registration unit for registering data, and a prepaid service payment within the range of the available amount corresponding to the first ID generated by the generation unit before the credit examination for the user is completed, a notification unit for notifying the user of the first ID; and a first ID generated by the generation unit from the prepaid service when credit is given to the user by credit examination of the user. Then, by switching to the postpaid service based on the credit, generating a second ID that is a new ID, and associating an amount equal to or less than the balance of the prepaid service with the second ID, An ID management system is disclosed that includes a processing unit that generates a virtual prepaid card and notifies the user of the second ID.

Japanese Patent Application Laid-Open No. 2002-183443 JP 2012-022514 A Patent No. 5667325

On the other hand, the so-called deferred payment business is gradually expanding in recent years in the Internet payment industry. Deferred payment is an operation in which payment is made after the product arrives, and is a payment method mainly used on EC sites.

The following characteristics can be seen in the deferred payment business.
・Credit processing is performed with minimal information (additional information may not be required), making it easy for users to use.
・There is immediacy because the credit processing is done almost in real time.
・There is no need to enter a credit card number in payment processing, which reduces risk.
・Because credit is not strictly enforced like credit cards (for this reason, the maximum amount may be set lower), there are cases where the examination is rejected due to similar information.
・Because it targets customers who use cash on delivery (customers who do not have a credit card or who do not want to enter their credit card number), there is no significant overlap with customers who pay by credit card.

In the industry related to such deferred payment settlement business, (1) we want to accept users who can purchase high-priced products by increasing the maximum amount, and (2) on the other hand, we want to make it possible to pay in installments and revolving payments in addition to lump-sum payments. (We also want to accept customers who wish to pay small amounts), (3) We want to eliminate restrictions on products as much as possible (we want to reduce the loss of sales opportunities on EC sites), (4) We want to reduce additional input work, etc. that users are forced to do as much as possible. (Deterrence of so-called cart abandonment), payment intermediation systems, etc. (not necessarily limited to this, but credit cardless deferred payment payment systems) to improve at least part or all of these hereinafter referred to as "settlement intermediary system" or "credit cardless deferred payment system").

Therefore, a settlement intermediary system according to an embodiment of the present invention is an electronic commerce server that is connected from a user terminal operated by a user and executes electronic commerce processing, and a transaction confirmation including a personal identification process for the owner of the user terminal. and a transaction confirmation server, wherein, when the user terminal is connected to the electronic commerce server, an instruction unit is provided on the user terminal that causes the user terminal to select payment in installments as a payment method for the electronic commerce, When the payment in installments is selected through the instruction unit, the user terminal is connected to the transaction confirmation server, member authentication processing is performed between the user terminal and the transaction confirmation server, and then the The connection of the user terminal is restored to the electronic commerce server.

Further, after the connection of the user terminal is restored to the electronic commerce server, the settlement processing of the electronic commerce is completed.

According to the settlement intermediation system and the like according to one embodiment of the present invention, there is an effect of improving at least part of the above-mentioned industry demand.

1 is an explanatory diagram illustrating an example of the overall configuration of a settlement intermediary system according to an embodiment of the present invention; FIG. FIG. 2 is an explanatory diagram illustrating a functional block configuration of a transaction confirmation server (group) in the settlement intermediary system according to one embodiment of the present invention; It is an explanatory view explaining an example of appearance composition of information processing equipment (user terminal) in a settlement mediation system concerning one embodiment of the present invention. FIG. 2 is an explanatory diagram illustrating the functional block configuration of hardware that constitutes the information processing apparatus according to the embodiment of the present invention; 1 is an explanatory diagram illustrating a functional block configuration of a settlement intermediary system according to one embodiment of the present invention; FIG. FIG. 4 is an explanatory diagram illustrating a processing flow in the settlement intermediation system according to one embodiment of the present invention; FIG. 9 is an explanatory diagram illustrating a processing flow in a settlement intermediary system according to another embodiment of the present invention; FIG. 9 is an explanatory diagram illustrating a processing flow in a settlement intermediary system according to another embodiment of the present invention; FIG. 9 is an explanatory diagram illustrating a processing flow in a settlement intermediary system according to another embodiment of the present invention; FIG. 9 is an explanatory diagram illustrating a processing flow in a settlement intermediary system according to another embodiment of the present invention; FIG. 9 is an explanatory diagram illustrating a processing flow in a settlement intermediary system according to another embodiment of the present invention; FIG. 10 is an explanatory diagram comparing a basic processing flow in a conventional payment intermediation system and a basic processing flow in the payment intermediation system according to one embodiment of the present invention;

A settlement intermediary system and the like according to an embodiment of the present invention will be described in detail below with reference to the drawings.

FIG. 1 shows an example of the overall configuration of a payment intermediary system according to one embodiment of the present invention.

As shown in FIG. 1, the payment intermediation system 10 includes, as a configuration in one embodiment thereof, a transaction confirmation server (group) 11 and various information processing devices used by users (customers). , a mobile information terminal or tablet terminal 12, a mobile phone 13, PCs 14-16, and smartphones 17-18. It is As shown in FIG. 1, the transaction confirmation server (group) 11 and various terminals are connected so as to be mutually communicable via a dedicated line or a public line such as the Internet (wired lines 37 to 39).
The payment intermediation system 10 also includes EC sites (electronic commerce server(s)) 19a and 19b, which realize commercial transactions with terminals. Although EC sites 19a and 19b are shown in FIG. 1, the number of EC sites is not limited in the present invention.

In addition, the line may be wired or wireless, and in the case of wireless, the mobile information terminal or tablet terminal 12, the mobile phone 13, and the smartphone terminals 17 and 18 are wirelessly connected to a base station, access point, etc. (not shown). , and is connected to the transaction confirmation server(s) 11 via a line 38 so as to be able to communicate with each other.

Here, an access point is a wireless device for connecting wireless terminals such as PCs and smartphones to each other and to other networks. Typically, it is a device that operates on the first layer (physical layer) and second layer (data link layer) communication protocols in the OSI reference model.

At the time of filing of this application, mobile phones, personal digital assistants, tablets, and smartphones are often equipped with processing capabilities (communication processing speed, image processing capability, etc.) comparable to personal computers (PCs). It should be said that it is a computer of

Programs or software necessary for carrying out the present invention are usually installed or stored in the HDD, SSD, or the like in the storage section of a PC or a mobile information terminal. All or part of it is read into the memory as a software module, and the CPU executes the calculation.

Alternatively, a browser-based computer or personal digital assistant may be employed. In this case, a program is delivered to the terminal from another server or computer as needed, and the browser on the terminal executes the program.

Also, the hardware configuration of the transaction confirmation server (group) 11 can basically employ one or more PCs (to be sure, it will be described later with reference to FIG. 2). Although the present invention is not limited to this, the transaction confirmation server (group) 11 may use a plurality of PCs (for example, several tens to tens of thousands of ) in parallel, a configuration suitable for large-scale data processing can be obtained. In this case, various functions can be distributed.

FIG. 2 shows a functional block diagram of the transaction confirmation server(s) in the payment intermediation system according to one embodiment of the present invention. Illustratively, the operations of the transaction confirmation server(s) are realized by the individual operations of hardware described below and the coordinated operations of software and these hardware.

In FIG. 2, a transaction confirmation server (group) 200 as a hardware block as a whole is roughly divided into a CPU 201 for performing various comparisons and arithmetic processing, a storage unit 202 such as RAM, ROM, flash memory, etc., a keyboard and so on. An input unit 203 such as a pointing device, an output unit 204 such as a display or a speaker, a control unit 205 for controlling various signals, a communication (interface) unit 206 (whether wireless or wired), and timekeeping. It is composed of a clock unit 207 and a power supply unit 208 for

These modules are appropriately connected as required by a communication bus or a feeder line (in FIG. 2, for convenience, each line is collectively represented as a connection line 299 in which each line is appropriately divided).

In addition, the programs or software executed on the transaction confirmation server (group) 200 necessary for the implementation of the present invention are usually installed or installed in the hard disk, SSD (Solid State Drive), flash memory, etc. that constitute the storage unit 202. When the program or software is executed, all or part of it is read as a software module into the memory in the storage unit 202 as required, and the CPU 201 performs arithmetic operations.

It should be noted that the execution of calculations does not necessarily have to be performed by a central processing unit such as the CPU 201, and an auxiliary calculation unit such as a digital signal processor (DSP) (not shown) can also be used.

FIG. 3 shows an external configuration example of the tablet terminal 12 as an information processing device in the settlement mediation system according to one embodiment of the present invention. In FIG. 3 , an information processing device (tablet terminal) 12 is composed of a housing 121 , a display 122 , and hardware buttons 123 provided in the lower central portion of the housing 121 . The display 122 is typically composed of a liquid crystal display (LCD) or the like, and can display various information such as characters, still images, and moving images. Also, a menu button or a software keyboard can be displayed on the display 122 and can be used as an instruction (command) to the tablet terminal 12 by touching it with a finger or a touch pen (not shown). In this respect, the hardware button 123 is not an essential component, but for convenience of explanation of the present invention, it is implemented as a button that performs a certain function. Of course, these hardware buttons 123 can be replaced by menu buttons displayed on part of the display 122 .

Further, the display 122 includes a multi-touch input panel, and touch input position coordinates on the touch input panel are transmitted to the processing system (CPU) of the tablet terminal 12 via an input device interface (not shown). It is processed. And, the multi-touch input panel is configured to be able to simultaneously sense multiple touch points on the panel. This detection (sensor) can be realized by various methods, and is not necessarily limited to a contact sensor. For example, an optical sensor can be used to extract an indication point on the panel. Further, the sensor may be a contact sensor, an optical sensor, or a capacitive sensor that senses contact with human skin.

Moreover, although not shown in FIG. 3, the tablet terminal 12 can also include a microphone and a speaker. In this case, it is also possible to discriminate the user's voice picked up by a microphone and use it as an input command. Furthermore, although not shown in FIG. 3, a camera device such as CMOS can be mounted on the back surface of the tablet terminal 12 or the like.

FIG. 4 illustrates a functional block diagram of hardware configuring the tablet terminal 12 according to one embodiment of the present invention. The operation of the tablet terminal 12 is realized by individual operations of hardware described below and cooperative operations between software and these hardware.

In FIG. 4, the tablet terminal 400 as a hardware block as a whole is roughly divided into an input unit 401 composed of the hardware buttons 123 in FIG. A storage unit 402 composed of a hard disk, RAM and/or ROM for storing data, etc., a central processing unit 403 composed of a CPU that performs various numerical calculations and logical operations according to programs, a display 122 etc. a display unit 404, a control unit 405 for controlling chips, electrical systems, etc., a slot for accessing the Internet, a port for performing optical communication, and a communication interface composed of a communication interface. A unit 406, an output unit 407 such as a speaker, vibration, and an infrared projector, a timer unit 408 for measuring time, etc., a sensor unit 409 including an image sensor such as a CMOS, an infrared sensor, an inertial sensor, etc., and a device internal and a power supply unit 410 for supplying power to each module, and these modules are appropriately connected to a communication bus or a power supply line as needed (in FIG. ).
Note that the sensor unit 409 may include a GPS sensor module for specifying the position of the tablet terminal 400(12). A signal detected by an image sensor such as a CMOS, an infrared sensor, or the like that constitutes the sensor unit 409 can be processed as input information in the input unit 401 .

Further, the programs or software executed on the tablet terminal 400 necessary for implementing the present invention are usually installed or stored in a hard disk, SSD (Solid State Drive), flash memory, or the like that constitutes the storage unit 402. When the software is executed, all or part of it is read as a software module into the memory in the storage unit 402 as necessary, and the CPU 403 performs calculations.

It should be noted that the execution of calculations does not necessarily have to be performed by the central processing unit 403 such as a CPU, and an auxiliary calculation device such as a digital signal processor (DSP) (not shown) can also be used.

FIG. 5 shows an example of functional block configuration in the settlement mediation system according to one embodiment of the present invention. As an embodiment of the present invention, the figure shows cloud environments 510a and 510b, an authentication/business server 510c, and an EC site 520, which constitute a transaction confirmation server (group). Illustration of user terminals is omitted.

The cloud environment 510a mainly constitutes a deferred payment system, is connected from the API 521 of the EC site 520 via a gateway, and executes various deferred payment processes.

The cloud environment 520b constitutes a web reception system that provides an application reception screen or the like to a user terminal (not shown in FIG. 5) in response to a request from the EC site 520. FIG. The authentication/business system server 510c is a processing system that performs authentication processing and business processing with the EC site (and/or user terminal) via the cloud environment 520b. The authentication/business system server 510 c further includes a fraud detection function 511 , a payment slip notification function 512 , a receiving agency function 513 , a contract sending function 514 , and an SMS authentication function 515 .

Here, the fraud detection function 511 detects fraudulent use from IP addresses and device information. In addition, the payment slip notification function 512 transmits to the user information such as a bar code that enables payment at each receiving agency. As an example, processing (preparation for printing, etc.) for sending a convenience store payment slip attached with a bar code is performed. The collection agency function 513 is a function for carrying out collection agency of contract price by each collection agency business operator. The contract sending function 514 is a function for sending the contract document to the registered address by non-forwarding mail when applying for deferred payment according to one embodiment of the present invention.

Further, the SMS authentication function 515 is a function for performing OTP notification by SMS (Short Message Service) or voice as personal authentication when applying for deferred payment according to one embodiment of the present invention.

The Web reception system (cloud environment 520b) has a function of providing a pop-up page for the user to input various information when applying for deferred payment according to an embodiment of the present invention.

Furthermore, in one embodiment of the present invention, when the user wishes to make a deferred payment on an EC site, a so-called modal window (a child screen connected to an authentication/business server) can be accessed via a script (simple program) or the like. ) can be implemented to launch In that case, the user can input and register the necessary information in the modal window, and link it with the authentication/operation system server via the EC site and the deferred payment system.
At the linking timing, in one embodiment of the present invention, payment information such as the item, unit price, and quantity of the purchased product is linked from the EC site to the deferred payment system. Furthermore, the examination result information can be linked from the authentication/operation system server to the deferred payment system. Linkage of detailed information such as items, unit prices, and quantities may be real-time linkage in practice or linkage by batch processing.

FIG. 6 is an explanatory diagram illustrating the processing flow (from applying for deferred payment to obtaining approval) in the settlement intermediation system according to one embodiment of the present invention. Although not strictly defined, the EC site in FIG. 6 roughly corresponds to the EC site in FIG. 5, and the post-payment processing system server (group) in FIG. 6 roughly corresponds to the cloud environment 510a in FIG. 6 generally correspond to the cloud environment 510b and the authentication/business server(s) in FIG. FIG. 6 clearly shows the operation of the user (user terminal).
Note that steps S601, S603, S606, S607, S609, and S616 in FIG. 6 indicate user input processing and the like from the user terminal. In one embodiment, step S611 is a manual confirmation process, but the present invention is not limited to this, and can be an automated process.
The processing flow will be described below with reference to FIG.

In step S601, the user terminal (user terminal) connected to the EC site performs product purchase selection and the like. The EC site in one embodiment of the present invention is a site that supports so-called deferred payment processing (the characteristics of which will be described sequentially).

In step S602, the total price of the purchased products selected by the user terminal is calculated and displayed or presented on the user terminal. In step S603, the user selects "postpay" as a payment method through input on a user terminal screen (not shown) (hereinafter also referred to as "pocket postpay" as a characteristic postpayment method in one embodiment of the present invention). ).

In step S604, in order to continue the deferred payment processing specified by the user in the previous step, the EC site calls a registration screen for deferred payment to the authentication/business server(s) (the EC site itself displays the registration screen). The lack of preparation is one of the features of the present invention). In step S605, a screen for deferred payment registration is prepared in the authentication/business server(s) and transmitted to the user terminal. In one embodiment of the invention, this registration screen is prepared and sent as a modal window (in FIG. 6, an arrow from step S604 to step S606, but the invention is so limited). (It can also be an arrow from step S605 to step S606 instead of a thing).

In step S606, necessary information (attribute information of the person, etc. In one embodiment, the ID and password requested by the person, the address of the person, contact e-mail address, mobile phone number, etc. are included) is input to the user terminal. will be In step S607, the verification document of the user himself/herself (identity verification document) is uploaded to the authentication/operation system server(s). In one embodiment of the present invention, an image of the authentication document containing the user's own facial image may be uploaded.

In step S608, the authentication/business server (group) sends an SMS for personal authentication. For example, an authentication number (authentication code) temporarily generated as a short message to the mobile phone number of the user's own terminal is sent to the user's own terminal.
Note that this authentication number (authentication code) may have an expiration date, and in one embodiment, this expiration date is managed by the transaction confirmation server(s).

In step S609, in the user terminal, the authentication number sent by SMS from the authentication/business server(s) is input to a reception screen (not shown) on the terminal and returned to the authentication/business server(s).

In step S610, the authentication/business server(s) collate the authentication number sent from the user terminal, and if no problem occurs in the collation, an e-mail or the like indicating acceptance completion is sent to the user terminal.

On the other hand, in step S611, in the post-payment processing system server (group), the matching of the authentication number in step S610 triggers confirmation of the data including the identification document (in one embodiment of the present invention, this confirmation is Although this is done manually, the present invention is not limited to this, and part or all of it can be automated by checking with an authentication database (not shown). If there is no problem in step S611, the process proceeds to step S612.

In step S612, P-SYS (a server system that performs authentication processing among authentication/business servers (group)) performs other necessary automatic examinations. If there is no problem in this step, the process proceeds to step S613.

In step S613, the examination result by P-SYS in the previous step is received as being good, so based on this examination result (good), cooperation between the post-payment processing system server (group) and the EC site is re-established. be done.

In step S614, according to the instructions of the post-payment processing system server (group), when the examination is completed, the product purchased by the user is shipped (after this, the product is delivered to the user, but not shown in FIG. 6). ).

On the other hand, in step S615, in response to the result (good) of the examination in step S612, a contract (contract information) including authentication information such as an ID and password is sent (in one embodiment of the present invention, (Although it is described as mailing, the present invention is not limited to this, and it can also be electronically transmitted as electronic information).
The ID may be one applied by the user himself/herself or one automatically numbered by the system side.

In step S616, by the processing in the previous step, the contract (contract information) including authentication information such as ID and password is received or received, and business processing is performed by NC/NS (authentication/business system server (group)). server system) and change the payment method, etc. as necessary.

Next, with reference to FIGS. 7A to 7C, and FIGS. 8A and 8B, the processing flow in the settlement intermediation system according to another embodiment of the present invention will be explained. The processing flow described with reference to these drawings partially overlaps with the processing flow described with reference to FIG. 6, but includes many further improvements. For better understanding, the description will be superimposed.

As for the "pocket payment after delivery" in another embodiment of the present invention, it is expected that the user will use it repeatedly, and the main aim is to reduce the difficulty of use from the second time onwards. More specifically, an application process, etc. is required for the first use, but for the second and subsequent uses, an environment is realized in which services such as electronic commerce can be used with only an ID, password, and SMS authentication.

That is, FIGS. 7A to 7C show an example of the processing flow for the first use, and FIGS. 8A and 8B show the processing flow for the second and subsequent uses.
Hereinafter, regarding the processing flow in the settlement intermediation system according to one embodiment of the present invention, the exchange of processing requests, data, etc. among the user terminal, the EC site, and the transaction confirmation server (group) will be described along an exemplary time series. While showing the technical idea of the present invention.

At time t700 in FIG. 7A, a user who is connected to an EC site and is shopping selects a product via a purchase screen D700 (not shown) on his user terminal (also referred to as a "user terminal") ( step S700). The selected product is sent to the EC site. Thereafter, similarly, another product is selected at time t701 (step S701). The selected product is sent to the EC site. In this embodiment, purchase selection (accounting instruction) is made at time t702 (step S702).
Then, the screen on the user terminal switches to a settlement screen D701 (not shown).

At time t703, information about the payment method and the like is transmitted from the EC site to the user terminal (step S703). Next, at time t704, the user terminal transmits a transaction request to the transaction confirmation server(s) to proceed with the "deferred payment" (step S704). In one embodiment, "pay later" is selected as the payment method by pressing a selection button or the like (not shown) provided on the screen provided by the EC site.

The transaction confirmation server (group) that receives the transaction request from the user terminal at time t704 executes a transaction confirmation sequence (step S705). In one embodiment, this sequence includes simple name identification processing, initial screen determination processing, setting of script tags for fraud detection, numbering of request IDs, and the like, and is broadly defined as member authentication processing.
The request ID may be determined by the user's request or automatically assigned by the system (transaction confirmation server). Hereinafter, the request ID will also simply be referred to as an ID.

At time t705, the transaction confirmation server(s) prepares the agreement agreement screen (step S706) and transmits it to the user terminal. An application agreement screen D702 (not shown) is displayed on the user terminal.

At time t706, the user terminal sends a notice of agreement to the terms to the transaction confirmation server(s). The transaction confirmation server (group) prepares an ID registration screen and transmits it to the user terminal (time t707, step S708). An ID registration screen D703 (not shown) is displayed on the user terminal.

At time t708, the user terminal transmits the ID desired by the user (and the password desired by the user if necessary) (step S709). The transaction confirmation server(s) checks whether or not there is duplication of the IDs sent from the user terminals. In this check, the existence or non-existence of ID duplication is confirmed by an inquiry from the gateway in the transaction confirmation server (group) to the FEP.
In the above-described embodiment of the present invention, the user applies for an ID (desired ID) during ID registration from t707 to t708, but the present invention is not limited to this. For example, the transaction confirmation server side may automatically assign a number. In this case, steps S708 and S709 from t707 to t708 and the screen D703 (dotted rectangular portion in FIG. 7) are omitted.

Subsequently, at time t720 in FIG. 7B, a user (customer) attribute input screen is generated in the transaction confirmation server(s) and transmitted to the user terminal (step S720). An attribute input screen D710 (not shown) is displayed on the user terminal.

At time t721, the information such as the address input at the user terminal is transmitted to the transaction confirmation server(s) (step S721). In one embodiment, the transaction confirmation server(s) performs an address master search, etc., and retrieves information such as street address from prefectures as needed.
At time t722, the transaction confirmation server(s) responds to the user terminal with address information (step S722).
At time t723, other attribute information is input at the user terminal and transmitted to the transaction confirmation server(s). Other attribute information sent from the user terminal is also registered in the transaction confirmation server(s).

At time t724, the transaction confirmation server(s) generates a personal identification document upload screen and transmits it to the user terminal (step S724). On the user terminal, a personal identification document upload screen D711 (not shown) is displayed.
At time t725, document information (including character information such as name and address) including an image of the person in question is uploaded from the user terminal to the transaction confirmation server(s) as data for identity confirmation (step S725). In the transaction confirmation server (group), OCR reading processing is performed based on the data uploaded from the user terminal, and information such as the personal identification number is primarily obtained.
Then, at time t726, the reading result is transmitted to the user terminal and displayed on the user terminal (step S726). At time t727, information such as the personal identification number displayed on the user terminal is confirmed, and if necessary, the information is added and/or corrected, and a registration application is submitted to the transaction confirmation server(s) (step S727). ).

At time t728, a confirmation screen is generated in the transaction confirmation server(s) and sent to the user terminal (step S728). A confirmation screen D712 (not shown) is displayed on the user terminal.
At time t729, the user terminal makes a final application to the transaction confirmation server(s) (step S729), and the transaction confirmation server(s) accepts or registers the contents of the application.

At time t730, the transaction confirmation server(s) prepares an application acceptance mail containing the user's ID (step S730) and sends it to the user terminal. Further, at time t731, the transaction confirmation server (group) prepares a reception completion screen (step S731) and transmits it to the user terminal. A reception completion screen D713 (not shown) is displayed on the user terminal. In another embodiment of the present invention, posting of the user ID in the application acceptance mail at time t730 can be omitted. Furthermore, in another embodiment of the present invention, it is possible to omit the transmission of the application receipt mail.
Then, after receiving the confirmation screen from the transaction confirmation server(s) (step S740 to be described later), the user terminal finishes communication with the transaction confirmation server(s) for the time being, and returns to settlement processing with the EC site.

Subsequently, at time t740 in FIG. 7C, a transaction confirmation screen is generated in the transaction confirmation server(s) (step S740) and transmitted to the user terminal. An AS (pay later) transaction confirmation screen D720 (not shown) is displayed on the user terminal.

Thereafter, in one embodiment of the present invention, the user terminal switches to a payment screen D721 (not shown), and at time t741, the user terminal issues a payment request to the EC site (step S741).
At time t742, a settlement completion screen is generated on the EC site (step S742. settlement processing is also completed at this time) and transmitted to the user terminal. A completion screen D722 (not shown) is displayed on the user terminal.

At time t743, the EC site completes the purchase request acceptance process (step S743), and an EC acceptance mail is sent to the user terminal.

During this period (from time t740 to time t744), the transaction core confirmation server (group) performs examination cooperation (step S760), automatic examination (step S761), official registration (step S762), internal inquiry (step S763), Then, authorization (step S764) and the like are carried out as appropriate, and an examination result notification is sent to the EC site by time t744 (step S744).

After that, the EC site receives the inspection result notification at time t744 and prepares for shipment of the product (step S745). Further, a shipping report is made from the EC site to the transaction confirmation server(s) via the API (step S746). In one embodiment, this shipping report includes ID, authorization KEY, transaction details, and the like. The transaction confirmation server(s) then executes the transaction confirmation sequence. In one embodiment, authorization key checks, ID/card number conversion, etc. are performed, and further authorization for authorization key verification is performed within the transaction confirmation server(s), which is broadly defined as member authentication processing.
Then, the transaction confirmation server (group) notifies the EC site of transaction information update completion via API (step S747).

At time t745, a transaction confirmation notice is generated at the EC site (step S748) and sent to the user terminal as an EC confirmation mail.
At time t746, the transaction confirmation server(s) generates a deferred payment use confirmation notice (step S749) and notifies the user terminal.

Subsequently, at time t747, the EC site is ready to ship the product, and a shipping notification is transmitted to the user terminal (step S750). Thereafter, the EC site side ships the product to the user's home, and notifies the user terminal to that effect (time t748, step S751).

At time t749, the transaction confirmation server(s) generates an e-mail notification of the examination result and transmits it to the user terminal (step S752).
Also, at time t750, the transaction confirmation server (group) carries out a sending procedure process for the contract, etc. (step S753), and sends it to the user terminal (or sends it to the user's home).

8A and 8B show the processing flow for the second and subsequent uses. Hereinafter, the exchange of processing requests, data, etc. among the user terminal, the EC site, and the transaction confirmation server (group) will be described along an exemplary time series.

At time t800 in FIG. 8A, a user who is connected to an EC site and is shopping selects a product via a purchase screen D800 (not shown) on his user terminal (also referred to as "user terminal") ( step S800). The selected product is sent to the EC site. Thereafter, similarly, another product is selected at time t801 (step S801). The selected product is sent to the EC site. In this embodiment, purchase selection (accounting instruction) is made at time t802 (step S802).
Then, the screen on the user terminal switches to a settlement screen D801 (not shown).

At time t803, information about the payment method and the like is transmitted from the EC site to the user terminal (step S803). Next, at time t804, the user terminal transmits a transaction request for proceeding with the "deferred payment" to the transaction confirmation server(s) (step S804).

In one embodiment of the present invention, "pay later" is selected as the payment method by pressing a selection button or the like (not shown) mounted on the screen provided by the EC site.
Furthermore, in one embodiment of the present invention, in addition to or alternatively to the selection of "payment in installments", a selection button or the like that allows selection of "payment in installments" can be provided.
In the following embodiments, the description will continue assuming that at least "payment in installments" has been selected.

The transaction confirmation server (group) that receives the transaction request from the user terminal at time t804 executes a transaction confirmation sequence (step S805). In one embodiment, this sequence includes simple name identification processing, initial screen determination processing, fraud detection script tag setting, ID numbering, and the like.

After time t804, the user terminal switches to an AS (postpaid) authentication screen D802 (not shown), and at time t805, an authentication request is transmitted to the transaction confirmation server(s) (step S806). The transaction confirmation server(s) performs member authentication processing (step S805b). This member processing includes ID authentication and authorization determination.

At time t806, an SMS notification is prepared (step) in the transaction confirmation server(s) and sent to the user terminal. The user terminal switches to a PIN input screen D803 (not shown).
Subsequently, at time t807, the transaction confirmation server(s) generates an SMS authentication screen and transmits it to the user terminal. At time t808, a PIN is transmitted from the user terminal (step S809). At the transaction confirmation server(s), PIN verification is done.

At time t809, the transaction confirmation server (group) generates an installment payment simulation screen and transmits it to the user terminal. An AS payment confirmation screen D804 (not shown) is displayed on the user terminal.
It should be noted that the installment payment simulation can employ a publicly known one related to installment payment.

At time t810, the user terminal applies for the number of divisions to the transaction confirmation server (group) (step S811), and the transaction confirmation server (group) generates an approval key linked to the TokenNo and ID. After that, at time t811, the confirmation screen is generated in the transaction confirmation server(s) and transmitted to the user terminal. An AS transaction confirmation screen D805 (not shown) is displayed on the user terminal.

Subsequently, at time t820 in FIG. 8B, an AS transaction confirmation screen D820 (similar to D805) is displayed, and by a predetermined operation (such as pressing a confirm button), the screen switches to a settlement screen D821 (not shown).

At time t821, the user terminal issues a payment request to the EC site (step S820), and the EC site starts payment processing. In one embodiment, the transaction verification server(s) are asked to check the transaction via the API as shown (step S821), and the transaction verification server(s) check the transaction (step S822), detect fraud, (Step S823) and approval KEY verification (step S824) are performed. After that, a completion notification such as transaction check is sent via API (step S825).

At time t822, the EC site that has received the completion notification from the transaction confirmation server(s) generates a payment completion screen (step S826) and transmits it to the user terminal. A completion screen D822 (not shown) is displayed on the user terminal.

In one embodiment of the present invention, at time t823, the EC site prepares for receiving the purchase request (step S827), and an EC receipt mail is sent to the user terminal.

After that, the EC site confirms the inventory of the purchase desired product requested by the user (step S828), and exchanges the following with the transaction confirmation server(s).
(1) Request to execute transaction confirmation sequence via API (step S829). In one embodiment, the transaction confirmation sequence (step S830) includes a customer data update process, a transaction data registration process, and an authorization request from a gateway in the transaction confirmation server(s) to the FEP (and Confirmation processing is executed by an inquiry to the P-SYS).
(2) Notification of confirmation results via API (step S831).

At time t824, the EC site prepares for notification of transaction confirmation (step S832), and notifies the user terminal as an EC confirmation mail.
At time t825, the transaction confirmation server (group) prepares for a deferred payment use confirmation notice (step S833), and notifies the user terminal as an AS confirmation mail.

At time t826, the EC site prepares to ship the product, and a shipping notification is sent at the time of shipping (step S834). The user terminal is notified as an EC dispatch mail.

At time t827, the product is shipped from the EC site to the user's home (step S835).

(Characteristics of the present invention, etc.)
It will be apparent from the above embodiments that the present invention has the following features. That is, in the relationship with the conventional settlement intermediary system, as shown in FIG. Processing including the initial application processing is performed (P902), and registration processing and the like are required at the settlement center that performs payment on behalf of the customer (P903). Only after completing this registration process, etc., can the payment agent service (P904) be entered. In other words, in the conventional system, the user was troubled by the point that the payment could not be performed unless the registration process and the notification of the confirmation documents and the like were completed at the settlement center.

On the other hand, in the payment intermediation system according to one embodiment of the present invention, as shown in FIG. 9B, when shopping on an EC site from a user terminal (P911), At the same time as switching from the EC site to the transaction confirmation server (group), the transaction confirmation server (group) provides a modal window to the user terminal to process the application process etc. between the two parties and perform the necessary confirmation. After that, the user is returned to the EC site, and the transaction business is continued without waiting for the notification of confirmation documents, etc. (P913-P914). In this respect, from the user's point of view, if a deferred payment application is made, the product settlement can be completed and the purchased product can be shipped without waiting for the confirmation document of the registered contents, so the complexity of deferred payment in electronic commerce can be reduced. be able to.

The embodiments of the payment intermediation system and the like have been described above based on specific examples, but as the embodiments of the present invention, in addition to the method or program for implementing the system or device, a storage medium in which the program is recorded (an example as optical disk, magneto-optical disk, CD-ROM, CD-R, CD-RW, magnetic tape, hard disk, memory card, etc.).

Moreover, the implementation form of the program is not limited to an application program such as an object code compiled by a compiler or a program code executed by an interpreter. good.

Furthermore, the program does not necessarily have to be executed entirely by the CPU on the control board. ) can also be configured to implement a part or all of it.

For all elements described in this specification (including the claims, abstract, and drawings) and/or for any method or process step disclosed, these features are mutually exclusive. Any combination can be used except for the combination of

Moreover, each of the features disclosed in this specification (including the claims, abstract, and drawings) may serve the same, equivalent, or similar purpose unless expressly contradicted Alternate features may be substituted. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of identical or equivalent features.

Furthermore, the invention is not limited to any specific configuration of the embodiments described above. The present invention resides in any novel feature or combination thereof, or any novel method or process step, or method described in this specification (including claims, abstract, and drawings). can be extended to combinations of

10 settlement intermediation system 11 transaction confirmation server (group)
12 Tablet terminal (a form of user terminal device)
13 Mobile phones (a form of user terminal equipment)
14-16 PC (a form of user terminal equipment)
17-18 Smartphone (a form of user terminal device)
19a, 19b EC site (e-commerce server, etc.)
37, 38 Communication line 39 Public line (dedicated line, Internet, etc.)

Claims (8)

A payment intermediation system comprising: an electronic commerce server connected from a user terminal operated by a user and executing electronic commerce processing;
When the user terminal is connected to the electronic commerce server, an instruction unit is provided on the user terminal for selecting payment in installments as a settlement method for the electronic commerce, and when the payment in installments is selected via the instruction unit. connects the user terminal to the transaction confirmation server;
After performing member authentication processing between the user terminal and the transaction confirmation server, the connection of the user terminal is restored to the electronic commerce server,
After the member authentication process, the transaction confirmation server examines the user's transaction based on the installment payment and notifies the electronic commerce server of the result, and
The electronic commerce server completes the settlement of the electronic commerce before the result of the examination is notified to the user terminal.
A settlement intermediation system characterized by: 2. The system according to claim 1, wherein after the connection of said user terminal is restored to said electronic commerce server, said electronic commerce payment processing is completed. 3. The system according to claim 1 or 2, further comprising performing a simulation regarding said installment payment after performing said member authentication. 3. The member authentication includes authentication using an ID and password assigned to the user, and authentication using an authentication code with an expiration date sent from the transaction confirmation server to the user terminal. 4. The system according to any one of 1-3. Executed on a payment intermediation system comprising an electronic commerce server connected from a user terminal operated by a user and executing electronic commerce processing, and a transaction confirmation server performing transaction confirmation including identification processing of the owner of the user terminal A program, when executed on said system,
When the user terminal is connected to the electronic commerce server, the user terminal is provided with an instruction unit for selecting payment in installments as a settlement method for the electronic commerce, and when the payment in installments is selected via the instruction unit. connecting the user terminal to the transaction confirmation server;
a step of restoring connection of the user terminal to the electronic commerce server after performing member authentication processing between the user terminal and the transaction confirmation server ;
a step of causing the transaction confirmation server to examine the user's transaction based on the installment payment after the member authentication process, and notifying the electronic commerce server of the result;
a step of causing the electronic commerce server to complete settlement of the electronic commerce before the result of the examination is notified to the user terminal;
A program characterized by executing 6. The program according to claim 5, wherein after the connection of the user terminal is restored to the electronic commerce server, settlement processing of the electronic commerce is completed. 7. The program according to claim 5 or 6, further executing a simulation regarding said installment payment after performing said member authentication. 3. The member authentication includes authentication using an ID and password assigned to the user, and authentication using an authentication code with an expiration date sent from the transaction confirmation server to the user terminal. 8. The program according to any one of 5-7.

Images