JP2021144643A - Charge method for electronic money and electronic money support system - Google Patents

Abstract

To provide a method for instantly remitting from a saving account of a user to an electronic money provider by using open API provided by a financial institution.SOLUTION: A charging method for electronic money includes: a first step for creating a transfer API which is an open API by using an access token in a charge support server 100 and transmitting; a second step for executing the transfer API in an API base 40, withdrawing a same amount as a charge amount from a saving account by an account system 52, and transmitting to a transfer destination account; a third step for transmitting a "success code" to the charge support server 100 in the API base 40 after simultaneous execution of withdrawal and transfer; a fourth step for transmitting a telegraphic message to which normal process data is added to an electronic money server 30 in the charge support server 100; and a fifth step for adding the charge amount to money balance of the electronic money in the electronic money server 30.SELECTED DRAWING: Figure 16

Description

The present invention relates to an electronic money charging method and an electronic money support system so that an open API provided by a financial institution can be used to immediately transfer money from a user's deposit / savings account to an electronic money business operator. It is the one that was made.

Conventionally, when a debit card is used, there is a time when the accounting host stops, and a "settlement processing system, a settlement processing method, and a settlement processing program" are known regarding the correspondence during that time (see Patent Document 1).
Specifically, first, before the bank's accounting system is stopped, the required amount determined for the electronic money function is charged, payment is made with electronic money, and then the remaining balance is returned to the account. Second, when the core banking system is stopped, a fixed credit amount is defined and paid, and the amount of the credit amount paid is paid after the core banking system is restarted.

Japanese Patent No. 6491372

However, the conventional system described above relates to a temporary response to the time when the bank's core banking host is stopped, and does not correspond to a continuous charge to electronic money.
As a mechanism for continuous charging of electronic money, it is also possible to use direct debit at a bank. For example, it is possible for the user to collect the charge amount and deposit it into the account of the electronic money company using the bank accounting system. However, there is a problem that the payment to the account of the electronic commerce payment system is the next business day, the monetization of the electronic commerce payment system is delayed, and the payment to the member store tends to be delayed.
Therefore, each of the inventions described in each claim has been made in view of the problems of the above-mentioned prior art, and the purpose thereof is as follows.

(Claims 1 to 6)
The inventions according to claims 1 to 6 aim at the following points with respect to the "method of charging electronic money".
That is, each of the inventions according to claims 1 to 6 uses an open API to immediately transfer money from the user's deposit / savings account to the electronic money business operator in response to the electronic money charge. This is to speed up the monetization of funds and to speed up payments to member stores.

(Claim 7)
The invention according to claim 7 aims at the same points as the invention according to claim 1 above with respect to the "electronic money support system".

Each of the inventions described in each claim has been made in order to achieve the above-mentioned object, and will be described below.

(Claim 1)
The invention according to claim 1 is characterized by the following points with respect to the "method of charging electronic money".
First, the electronic money charging method is premised on the following configuration.
(1) Electronic Money Server An electronic money server manages electronic money owned by a user.

(2) Charge Support Server The charge support server is capable of communicating with the electronic money server, and communicates using a telegram unique to the electronic money server.
(3) API platform The API platform can communicate with the electronic money server and manages an open API opened to the charge support server.

(4) Core banking system The core banking system is connected to the API platform, and deposits and withdrawals to the deposit and savings account owned by the user, and to the transfer destination account owned by the management entity that manages the electronic money server. It is possible to transfer money.

Secondly, the method of charging electronic commerce includes the following steps.
(5) First Step The first step is to receive the message sent from the electronic money server based on the intention of the user and including at least the electronic money number unique to the electronic money and the charge amount. As a condition, the charge support server creates the transfer API, which is the open API, using the access token unique to the service, and transmits the transfer API to the API platform.

(6) Second Step In the second step, on the condition that the transfer API is received, the transfer API is executed on the API base, and the same amount as the charge amount determined by the user is set in the accounting system. It is deducted from the deposit and savings account by the system.
In addition to this, the second step is to transfer the same amount as the charge amount to the transfer destination account by the accounting system at the same time.

(7) Third Step The third step is to transmit a "success code" to the charge support server on the API platform after simultaneous execution of withdrawal and transfer.
(8) Fourth Step The fourth step is to transmit the telegram to which the data of normal processing is added to the electronic money server in the charge support server on condition that the "success code" is received. be.
(9) Fifth Step The fifth step is to add the charge amount to the money balance of the electronic money owned by the user on the electronic money server on condition that the telegram is received.

(Claim 2)
The invention according to claim 2 is characterized by the following points in addition to the feature points of the invention according to claim 1 described above with respect to the "method of charging electronic money".
First, the telegram includes the following configuration.
(1) First Telegram The first telegram includes at least the electronic money number unique to the electronic money and the charge amount.
(2) Second telegram The second telegram is a set of the data of the normal processing.
Secondly, in the first step, the first telegram, which is a fixed long telegram, is converted into the transfer API and then transmitted to the API board.
Third, in the fourth step, the transfer API is converted into the second telegram, which is the fixed long telegram, and transmitted to the electronic money server.

(Claim 3)
The invention according to claim 3 is characterized by the following points in addition to the feature points of the invention according to claim 1 described above with respect to the "method of charging electronic money".
First, the telegram is a general-purpose telegram.
Secondly, in the first step, the transfer API is created using the general-purpose telegram.
Third, in the fourth step, the "success code" is set in the general-purpose telegram and transmitted to the electronic money server.

(Claim 4)
The invention according to claim 4 is characterized by the following points in addition to the feature points of the invention according to claim 1 described above with respect to the "method of charging electronic money".
First, the charge support server includes a linking database that links the electronic money number and the deposit / savings account.
Secondly, in the first step, the deposit / savings account information related to the deposit / savings account is added to the transfer API based on the electronic money number included in the telegram using the linking database.

(Claim 5)
The invention according to claim 5 is characterized by the following points in addition to the feature points of the invention according to claim 4 described above with respect to the "method of charging electronic money".
First, the access token is stored in the association database.
Secondly, in the first step, the access token stored in the association database is read, and the transfer API is created using the read access token.

(Claim 6)
The invention according to claim 6 is characterized in the following points in addition to the feature points of the invention according to claim 4 described above with respect to the "method of charging electronic money".
First, the telegram includes the following configuration.
(1) First Telegram The first telegram includes at least the electronic money number unique to the electronic money and the charge amount.
(2) Second telegram The second telegram is a set of the data of the normal processing.
Secondly, the transfer API includes the following configuration.
(3) Transfer instruction API
The transfer instruction API is the open API.
(4) Transfer execution API
The transfer execution API is the open API.

Third, the first step includes the following steps.
(5) 10th step In the 10th step, on the condition that the first message is received, the transfer instruction API, which is the open API, is used in the charge support server by using the access token registered in advance by the user. It is created and the transfer instruction API is transmitted to the API base.
(6) Eleventh Step The eleventh step is to respond the settlement processing number to the charge support server on the condition that the transfer instruction API is received on the API platform.
(7) 12th step In the 12th step, the transfer execution API is created by using the payment processing number set in the response portion of the transfer instruction API on the charge support server, and the service-specific access prepared in advance is used. The transfer execution API is transmitted to the API base using the token.

Fourth, in the second step, the transfer execution API is executed on the API base on condition that the transfer execution API is received.
Fifth, in the fourth step, on condition that the "success code" is received, the charge support server transmits the second telegram to which the data of the normal processing is added to the electronic money server.
Sixth, in the fifth step, on condition that the second telegram is received, the charge amount is added to the money balance of the electronic money owned by the user on the electronic money server.

(Claim 7)
The invention according to claim 7 is characterized by the following points with respect to the "electronic money support system".
First, the electronic money support system is premised on the following configuration.
(1) Electronic Money Server An electronic money server manages electronic money owned by a user.
(2) Charge Support Server The charge support server is capable of communicating with the electronic money server, and communicates using a telegram unique to the electronic money server.

(3) API platform The API platform can communicate with the electronic money server and manages an open API opened to the charge support server.
(4) Core banking system The core banking system is connected to the API platform, and deposits and withdrawals to the deposit and savings account owned by the user, and to the transfer destination account owned by the management entity that manages the electronic money server. It is possible to transfer money.

Secondly, the charge support server is subject to the reception of the message transmitted from the electronic money server based on the intention of the user and including at least the electronic money number unique to the electronic money and the charge amount. The transfer API, which is the open API, is created using the access token unique to the service, and the transfer API is transmitted to the API platform.

Third, the API platform executes the transfer API on condition that the transfer API is received, and withdraws the same amount as the charge amount determined by the user from the deposit / savings account by the accounting system. At the same time, the same amount as the charge amount is transferred to the transfer destination account by the accounting system.
Fourth, the API platform transmits a "success code" to the charge support server after simultaneous execution of withdrawal and transfer.

Fifth, the charge support server transmits the telegram to which the data of normal processing is added to the electronic money server on condition that the "success code" is received, and the electronic money server receives the telegram. On the condition that the charge amount is added to the money balance of the electronic money owned by the user.

Since the present invention is configured as described above, the present invention has the effects described below.
(Claims 1 to 6)
The inventions according to claims 1 to 6 have the following effects with respect to the "method of charging electronic money".
That is, according to the inventions of claims 1 to 6, the electronic commerce business is carried out by immediately transferring money from the user's deposit / savings account to the electronic commerce business operator by using the open API for the electronic commerce payment. It is possible to accelerate the monetization of the person and the payment to the member stores.
In addition to this, according to the inventions of claims 1 to 6, by adding the charge support server, it is possible to quickly process the telegram peculiar to the electronic money server.

(Claim 7)
The invention according to claim 7 has the same effect as the invention according to claim 1 with respect to the "electronic money support system".

It is explanatory drawing for demonstrating the outline of an electronic money support system. It is explanatory drawing for demonstrating the detail of an electronic money support system. It is a flowchart for demonstrating the charge process of electronic money. It is a flowchart for demonstrating the auto charge process of electronic money. It is a flowchart of an example of registration of an account number for charge. It is explanatory drawing for demonstrating an example of the screen of a communication terminal. It is explanatory drawing for demonstrating an example of the screen of the communication terminal of a user regarding charge processing. It is explanatory drawing for demonstrating an example of a user's account details. It is explanatory drawing for demonstrating an example of the account details of an electronic money business operator. It is explanatory drawing which excerpted a part of the list for explaining the list of the response code to the request of API. It is explanatory drawing for demonstrating the use example of an IC card. It is explanatory drawing for demonstrating the use example of a smartphone. It is explanatory drawing for demonstrating the use example of a prepaid card or a smartphone. This is a flow chart for explaining the auto charge process using an IC card. It is explanatory drawing for demonstrating the charge process of electronic money. It is explanatory drawing for demonstrating the charge processing of electronic money which concerns on 2nd Embodiment of this invention. It is explanatory drawing for demonstrating the charge processing of electronic money which concerns on 3rd Embodiment of this invention. It is explanatory drawing for demonstrating the outline of the electronic money support system which concerns on 2nd and 3rd Embodiment of this invention. FIG. 18 is an explanatory diagram for explaining the processing of the first telegram in the fixed length format according to FIG. Following FIG. 19, it is an explanatory diagram for explaining the flow of the second telegram of the fixed length format. It is explanatory drawing for demonstrating the processing of the 1st telegram of a general-purpose form which concerns on 4th Embodiment of this invention. Following FIG. 21, it is an explanatory diagram for explaining the processing of the same first telegram.

(Electronic money support system 10)
In FIG. 1, reference numeral 10 denotes an electronic money support system.
As shown in FIG. 1, the electronic money support system 10 is premised on the following configuration and "things" (hereinafter referred to as "preconditions").
(1) Electronic money server 30
The electronic money server 30 manages electronic money owned by the user. The electronic money server 30 is managed by an electronic money business operator.
Here, "electronic money" refers to an electronic record balance exchanged in the same manner as money paid by the user.

(2) API platform 40
The API platform 40 can communicate with the electronic money server 30 and manages an open API opened to the electronic money server 30. The electronic money server 30 is managed by a financial institution such as a bank, but is not limited to the bank.
Here, the "open API" refers to an interface that provides the functions of a financial institution to an external business operator.
Here, "communication" uses, for example, the Internet.

(3) Core banking system 52
The accounting system 52 is connected to the API platform 40 and is owned by the management entity that manages the deposit / withdrawal to the deposit / savings account owned by the user (user deposit / savings account 53, see FIG. 2) and the electronic money server 30. It is possible to transfer money to the transfer destination account (electronic money business deposit and savings account 54, see Fig. 2).
Here, the "connection" is connected using, for example, a dedicated line, but is not limited to the dedicated line.

(Features of the present invention)
The features of the present invention are the following two points.
(1) Electronic money charge processing (2) Electronic money auto charge processing

(Electronic money charge processing)
The above-mentioned "(1) Electronic money charge processing" enables a user to charge the electronic money owned by the user by using the deposit / savings account (user deposit / savings account 53) owned by the user.

The electronic commerce support system 10 uses the open API of a financial institution such as a bank based on the user's intention, and the same amount as the charge amount determined by the user is set in the deposit / savings account (user deposit / savings account 53, see FIG. 2). ), And at the same time, transfer the same amount as the charge amount to the transfer destination account of the electronic money business operator (electronic money business deposit and savings account 54, see Fig. 2).
After simultaneous execution of withdrawal and transfer, the API platform 40 of the electronic money support system 10 sends a "success code" to the electronic money server 30 of the electronic money operator, and the electronic money server 30 that receives this sends the "success". When the "code" is received, the charge amount is added to the money balance of the electronic money owned by the user.

Here, "based on the will of the user" includes the following cases in the case of "charge processing".
(1) When a "charge request" is triggered from the user's communication terminal 21 (2) When a "charge request" is transmitted via the electronic terminal 60 (see FIG. 1) of the store.

Further, in the case of the "auto-charge processing" described later, the determination result that the money balance is insufficient in the electronic terminal 60 of the store or the electronic money server 30 of the electronic money operator is triggered.
In the case of "auto charge", the user asks the user to specify the charge request in the consent form, terms of use, etc., and a fixed amount or shortage amount is specified, and it is recognized as "the charge amount decided by the user". NS.

This makes it possible to charge the electronic money owned by the user. That is, when the balance of money owned by the user is "2,000 yen" and the user requests a charge of "3,000 yen", the electronic money support system 10 operates and the electronic money server 30 of the electronic money operator is a bank or the like. Upon receiving the "success code" from the API platform 40 of the financial institution, the charge amount "3,000 yen" is added to the money balance "2,000 yen" of the electronic money owned by the user, and the money balance is "5,000 yen". It becomes "yen".
The electronic money support system 10 accelerates the monetization of the electronic money business operator by simultaneously executing the withdrawal and the transfer and transmitting the "success code" to the electronic money server 30 of the electronic money business operator, and the member store. It is also possible to accelerate the payment to.

(Auto-charge processing of electronic money)
The above "(2) Electronic money auto-charge processing" is an advanced system of "(1) Electronic money charge processing", and the shortfall amount for the money balance owned by the user can be automatically charged. It is a thing.
The electronic money support system 10 operates when the user's planned usage amount of electronic money is received from the electronic terminal 60 of the store.

When the electronic money server 30 of the electronic money business operator determines whether or not the planned usage amount has reached the money balance owned by the user, and as a result of the determination, the money balance is insufficient. The API base 40 uses the account system 52 to set a deposit account ( It is required to withdraw from the user deposit and savings account 53) and at the same time transfer the determined amount or shortage amount to the transfer destination account (electronic money business deposit and savings account 54).

As a result, the electronic money owned by the user can be automatically charged. That is, when the money balance owned by the user is "2,000 yen" and the planned usage amount of the user is "3,000 yen", the money balance is insufficient. At this time, if the determined amount determined in advance by the user is "5,000 yen", the electronic money server 30 uses the open API of the financial institution such as a bank and puts "on the API base 40 of the financial institution such as a bank". Request simultaneous execution of withdrawal and transfer of "5,000 yen".

In addition, the accounting system 52 of a financial institution such as a bank confirms the account balance of the user's deposit and savings account (user's deposit and savings account 53), and if it is "20,000 yen", for example, "5,000 yen" is deducted. , The account balance will be "15,000 yen".

After that, the electronic money server 30 adds the determined amount "5,000 yen" transferred to the user's money balance "2,000 yen" when receiving the "success code" from the API platform 40, and the money balance. Is "7,000 yen".
The electronic terminal 60 of the store confirms that the user's money balance "7,000 yen" exceeds the planned usage amount "3,000 yen", pays the planned usage amount "3,000 yen", and pays the money balance "4,000 yen". ".

The electronic money support system 10 accelerates the monetization of the electronic money business operator by simultaneously executing the withdrawal and the transfer and transmitting the "success code" to the electronic money server 30 of the electronic money business operator, and the member store. It is also possible to accelerate the payment to.
In addition, as for the withdrawal and transfer amount, a predetermined method is selected from the charge amount determined in advance by the user or the shortage amount with respect to the money balance owned by the user, so that the user can calculate the charge amount. , There is no need to request, and the burden on the user can be reduced.

(First feature point)
Hereinafter, the feature points of the present invention will be described.
The first feature point includes the above-mentioned "preconditions" regarding the "method of charging electronic money", and includes the following steps as the first configuration.

(First configuration)
(1) First step The first step is an API platform 40, provided that the transfer execution API (settlement execution) 42, which is an open API, is issued from the electronic money server 30 based on the user's intention. Is the step of executing the transfer execution API (settlement execution) 42.
Regarding the first step, steps S10, S20, S21, S31, S32, S22, S23, and S33 correspond to each other in the order of FIG. 3 described later.

(2) Second step The second step is a step in which the API platform 40 withdraws the same amount as the charge amount determined by the user from the deposit / savings account (user deposit / savings account 53) by the accounting system 52.
The second step corresponds to step S34 in FIG. 3, which will be described later.

(3) Third step The third step is a step in which the API platform 40 transfers the same amount as the charge amount to the transfer destination account (electronic money business deposit / savings account 54) by the accounting system 52 at the same time.
The third step corresponds to step S35 in FIG. 3, which will be described later.

(4) Fourth Step The fourth step is a step in which the API platform 40 transmits a "success code" to the electronic money server 30 after simultaneous execution of withdrawal and transfer.
The fourth step corresponds to step S36 in FIG. 3, which will be described later.

(Second configuration)
As the second configuration, the API platform 40 transmits the "success code" to the electronic money server 30, and the electronic money server 30 receives the transmitted "success code" as an opportunity. In 30, it is characterized in that the charge amount is requested to be added to the money balance of the electronic money owned by the user.
Regarding the second configuration, steps S24 and S11 correspond to each other in the order of FIG. 3 described later.

(Second feature point)
Regarding the "electronic money charging method", the second feature point is, in addition to the first configuration (first to fourth steps) and the second configuration of the first feature point described above, as a third configuration. Includes the following steps.

(Third configuration)
(1) Fifth step The fifth step is a predetermined amount determined by the user by executing the transfer execution API (settlement execution) 42 on condition that the transfer execution API (settlement execution) 42 is received. Alternatively, the API base 40 is a step of withdrawing the shortfall amount from the money balance owned by the user from the deposit / savings account (user deposit / savings account 53) by the accounting system 52.
Steps S63 and S64 correspond to the fifth step in the order of FIG. 4 described later.

(2) Sixth step The sixth step is a step in which the API base 40 transfers the determined amount or the shortage amount to the transfer destination account (electronic money business deposit / savings account 54) by the accounting system 52 at the same time.
The sixth step corresponds to step S65 in FIG. 4, which will be described later.

(Third feature point)
Regarding the "electronic money charging method", the third feature point is, in addition to the first configuration (first to fourth steps) and the second configuration of the first feature point described above, as a fourth configuration. Includes the following steps.

(Fourth configuration)
(1) Seventh step The seventh step is issued from the electronic money server 30 based on the intention of the user, and is issued only once on condition that the transfer instruction API (settlement application) 41, which is an open API, is received. This is a step in which the API platform 40 issues an access token that is permitted to be used, prohibited from reuse, and has an expiration date to the electronic money server 30.
The seventh step corresponds to steps S10, S20, S21, S31, and S32 in FIG. 3, which will be described later.

(2) Eighth step In the eighth step, the received transfer execution API (payment execution) 42 is used as an access token when the transfer execution API (payment execution) 42 is received from the electronic money server 30. This is a step of accessing the core banking system 52 by transmitting the data from the API platform 40 to the core banking system 52.
The seventh step corresponds to steps S22, S23, S33, and S34 in FIG. 3, which will be described later.

(Fourth feature point)
The fourth feature point includes the above-mentioned "preconditions" regarding the "method of charging electronic money", and includes the following steps as the fifth configuration.

(Fifth configuration)
(1) First step In the first step, the electronic money server 30 issues a transfer instruction API (settlement application) 41 and a transfer execution API (settlement execution) 42, which are open APIs, based on the intention of the user. It's a step.
Regarding the first step, steps S10, S20, S21, and S23 correspond to each other in the order of FIG. 3 described later.

(2) Second Step The second step is a step in which the electronic money server 30 transmits the issued transfer instruction API (settlement application) 41 and transfer execution API (settlement execution) 42 to the API platform 40.
Regarding the second step, steps S21, S22, and S23 correspond to each other in the order of FIG. 3 described later.

(3) Third step In the third step, the API platform 40 executes the received transfer execution API (settlement execution) 42, and the account system 52 transfers the charge amount determined by the user to the deposit / savings account (use). Withdrawal from the person's deposit and savings account 53), at the same time transfer the charge amount to the transfer destination account (electronic money business deposit and savings account 54), and after simultaneous execution of withdrawal and transfer, the "success code" sent by the API platform 40 is electronically transmitted. This is a step in which the electronic money server 30 adds the charge amount to the money balance of the electronic money owned by the user on condition that the money server 30 receives the payment.
Regarding the third step, steps S33, S34, S35, S36, and S24 correspond to each other in the order of FIG. 3 described later.

(Fifth feature point)
The fifth feature point includes the following step as the sixth configuration in addition to the fifth configuration (first to third steps) of the fifth feature point described above with respect to the "method of charging electronic money". ..

(Sixth configuration)
(1) Fourth step In the fourth step, when the electronic money server 30 receives the planned usage amount of the electronic money planned by the user from the electronic terminal 60 of the store, the user owns the planned usage amount. This is a step in which the electronic money server 30 determines whether or not the amount of money to be paid has been reached.
Regarding the fourth step, steps S40 and S50 correspond to each other in the order of FIG. 4 described later.

(2) Fifth step In the fifth step, if the money balance is insufficient as a result of the judgment, the transfer instruction API (settlement application) 41 and the transfer execution API (settlement execution) 42, which are open APIs, are used. , Is a step issued by the electronic money server 30.
Regarding the fifth step, steps S51, 52, and S63 correspond to each other in the order of FIG. 4 described later.

(3) Sixth Step The sixth step is a step in which the electronic money server 30 transmits the issued transfer instruction API (settlement application) 41 and transfer execution API (settlement execution) 42 to the API platform 40.
Regarding the sixth step, steps S51 and S53 correspond to each other in the order of FIG. 4 described later.

(7th configuration)
As a seventh configuration, the electronic money server 30 transmits the transfer instruction API (settlement application) 41 and the transfer execution API (settlement execution) 42 to the API base 40, thereby transmitting the transfer instruction API (settlement application) 41 and the transfer execution API (settlement application) 42. When the API platform 40 receives the transfer execution API (settlement execution) 42, the API platform 40 sets the determined amount determined in advance by the user or the shortage amount for the money balance owned by the user. Is characterized by requesting that the account system 52 be used to withdraw money from the deposit / savings account (user deposit / savings account 53) and at the same time transfer the determined amount or shortfall to the transfer destination account (electronic money business deposit / savings account 54). And.
Regarding the seventh configuration, steps S61, S62, S63, S64, and S65 correspond to each other in the order of FIG. 4 described later.

(Explanation of FIG. 1)
As shown in FIG. 1, the electronic money support system 10 is premised on the following configuration and "things".
Since the following (1) to (3) have been described above, the description thereof will be omitted. In addition, the electronic money support system 10 is not limited to the following (1) to (6), and when the user only charges the electronic money, (5) ordinary deposit and savings account 22 and (6) retail store. Electronic terminal 60 may be omitted.
(1) Electronic money server 30
(2) API platform 40
(3) Core banking system 52

(4) Electronic money card 20
For example, a "bar code" is displayed on the electronic money card 20 and is owned by the user.
Although the "bar code" and the like have been exemplified, the present invention is not limited to this, and a "two-dimensional code" other than the "bar code" may be displayed, or an "RFID" may be embedded.

(5) Communication terminal 21
The communication terminal 21 is composed of, for example, a "smartphone" and is owned by the user. The user uses a smartphone to access the electronic money server 30 of the electronic money business operator via the Internet, and sends, for example, a charge request for electronic money.
Although the "smartphone" is exemplified as the communication terminal 21, the communication terminal 21 is not limited to this, and may be a mobile communication terminal such as a mobile phone, PHS, PDA, notebook PC, or tablet, or a mobile information terminal.

(6) Passbook for financial institutions 22
The bankbook 22 for financial institutions is owned by the user and is used for transactions with financial institutions. In addition to the financial institution passbook 22, a cash card may be used. Further, the passbook 22 for financial institutions may be paper or a "digital passbook".

(7) Electronic terminal 60
The electronic terminal 60 is composed of, for example, a "POS cash register" and is installed at a store or the like. The "POS cash register" reads the barcode of the user's electronic money card 20 and confirms the user's identity. Further, the electronic terminal 60 uses the read barcode to access the electronic money server 30 of the electronic money business operator via a dedicated line, and executes confirmation of electronic money information, exchange of information, and the like. "Cash register" is an abbreviation for "register".
Although the "POS cash register" is exemplified as the electronic terminal 60, the present invention is not limited to this, and a terminal may be used. Moreover, although the "dedicated line" is illustrated, the present invention is not limited to this, and the Internet may be used or used in combination.

(Relationship between electronic money card 20 and communication terminal 21)
There are the following types of combinations of the electronic money card 20 and the communication terminal 21.
(1) When using the electronic money card 20 and the communication terminal 21 in combination (2) When using the communication terminal 21 alone (3) When using the electronic money card 20 alone

(Combination of electronic money card 20 and communication terminal 21)
In the combination of the electronic money card 20 and the communication terminal 21, the electronic money card 20 is "positive" and the communication terminal 21 is "secondary".
As shown in FIG. 1, the electronic money card 20 is brought to a store, and after shopping is completed, the electronic money card 20 is used as a reader of an electronic terminal 60 of, for example, a "POS cash register" installed at the store. It is used to confirm the identity of the user by holding up and reading the "bar code".

A communication terminal 21 such as a smartphone is used to request a charge for electronic money.
A program provided by an electronic money business operator (hereinafter referred to as "first smartphone application") is installed in the communication terminal 21. As shown in FIG. 7, the first smartphone application includes a communication function with an electronic money server and a display function of a display.

(When using the communication terminal 21 alone)
When the communication terminal 21 is used alone, there are the following specification modes.
(1) First Specification Aspect of Communication Terminal 21 The first specification aspect of communication terminal 21 is a case where a "two-dimensional code" other than a bar code or "bar code" is displayed on the display of a smartphone.

Similar to the electronic money card 20, the bar code or the like on the display is used for reading the "bar code" or the like and confirming the identity of the user by holding it over the reader of the electronic terminal 60 installed at the store.
In addition to the above-mentioned first smartphone application, a program for displaying a barcode or the like on a display (hereinafter, referred to as "second smartphone application") is installed in the communication terminal 21.

(2) Second Specification Aspect of the Communication Terminal 21 The second specification aspect of the communication terminal 21 also has the functions of the electronic money server 30 of the electronic money business operator.
In the communication terminal 21, in addition to the communication function with the API platform 40 of the financial institution, a program (hereinafter referred to as "third smartphone application") for managing the user's electronic money is installed.

(When using the electronic commerce card 20 alone)
When the electronic money card 20 is used alone, as shown in FIG. 1, the electronic money card 20 can be read by holding the electronic money card 20 over the reader of the electronic terminal 60 at the store. In addition to being used to verify the identity of the user, it also has a charging function through the touch panel and keyboard of the electronic terminal 60.

(Explanation of FIG. 2)
FIG. 2 is for explaining the details of the electronic money support system 10 shown in FIG.
The electronic money support system 10 includes the following configurations.
(1) Electronic terminal 60
The electronic terminal 60 is installed in a store or the like and includes the following configurations.

(1-1) Electronic money operation function system 61
The electronic money operation function system 61 mainly controls the money balance inquiry and the charge screen.
(1-2) Electronic money payment function system 62
The electronic money payment function system 62 mainly controls a reduction in the payment amount and an increase in the charge. The electronic money payment function system 62 is connected to the electronic money operation function system 61.

(2) Electronic money server 30
The electronic money server 30 is managed by an electronic money business operator.
The electronic money server 30 includes the following configurations.
(2-1) Electronic money support function system 31
The electronic money support function system 31 mainly constitutes a mechanism for transmitting a transfer instruction API, a transfer execution, and an API.

(2-2) Electronic money management function system 32
The electronic money management function system 32 mainly manages member management, balance management, usage statement management, settlement, and the like. After executing the API, the electronic money management function system 32 executes an increase / decrease in the money balance according to a completion instruction of the electronic money support function system 31.
The electronic money management function system 32 is connected to the electronic money payment function system 62 and is also connected to the electronic money support function system 31.

(2-3) Others Although not shown, the electronic money server 30 includes an electronic money balance management DB, and member information, money balance, and the like are stored in the electronic money balance management DB.
(3) API platform 40
The API platform 40 is managed by a financial institution such as a bank.
The API platform 40 includes the following configurations.
(3-1) Settlement application API (transfer instruction) 41
The payment application API (transfer instruction) 41 is connected to the electronic money payment function system 62.

(3-2) Settlement execution API (transfer execution) 42
The payment execution API (transfer execution) 42 is connected to the electronic money payment function system 62.
In addition, the API platform 40 has the above-mentioned transfer instruction API 41 and transfer execution API 42 programs, receives an API request from the electronic money support function system, and cooperates with the next-stage financial institution system 50.

(4) Financial institution system 50
The financial institution system 50 is managed by a financial institution such as a bank. The management entity of the financial institution system 50 and the management entity of the API infrastructure 40 may be the same or different. For example, the API infrastructure 40 is managed by the first management entity, and the financial institution system 50 May be managed by a second management entity.

The financial institution system 50 includes the following configurations.
(4-1) Internal API51
The internal API 51 is connected to the payment execution API (transfer execution) 42.
(4-2) Core banking system 52
Core banking system 52 is connected to internal API 51.

Core banking system 52 includes the following configurations:
(4-2-1) User deposit and savings account 53
(4-2-2) Electronic Money Business Deposit and Savings Account 54
The electronic commerce business deposit and savings account 54 can be transferred from the user deposit and savings account 53.
In the financial institution system 50, the internal API 51 that receives the transfer execution API 42 and the accounting system 52 receive instructions from the internal API 51 to (1) withdraw from the user deposit / savings account 53 and (2) withdraw the amount. The process of transferring money to the electronic money business deposit and savings account 54 is executed in sequence.

(Explanation of FIG. 3)
FIG. 3 is a flowchart for explaining the charging process of electronic money.
It is divided into three columns, and the left column on the left side of FIG. 3 describes the operation of the user's communication terminal 21. The central column in the center explains the operation of the electronic money server 30 of the electronic money business operator, and the right column on the right side explains the operation of the API platform 40 and the core banking system 52 (50) of the financial institution.

First, the process proceeds to step S10 in the left column, and the "electronic money charge request (3,000 yen)" is executed. Step S10 is executed by the user using the communication terminal 21, and is transmitted to the electronic money server 30 of the electronic money business operator.
After the end of step S10, the process proceeds to step S20 in the center row. In step S20, "confirmation of the money balance of electronic money (2,000 yen remaining)" is executed. Step S20 is executed by the electronic money server 30, and is started with a "charge request" as a trigger to confirm the user's money balance and whether the total of the charge amount and the balance has reached the upper limit of the electronic money. Will be done. In addition, there is an upper limit on electronic money.

After the end of step S20, the process proceeds to step S21 on the lower side. In step S21, "creation / transmission of transfer instruction API by charge amount" is executed. Step S21 is executed by the electronic money server 30, and the created transfer instruction API is transmitted to the API base 40.
After the end of step S21, the process proceeds to step S31 in the right column.

If there is no electronic money balance in step S21, the content of the insufficient balance is returned. The error code is "400" as illustrated in FIG. 10, and the transfer instruction API responds with an insufficient balance error. Here, it is assumed that the balance of electronic money is "10,000 yen".

In step S31, "reception of transfer instruction API" is executed. Step S31 is executed by the API platform 40.
After the end of step S31, the process proceeds to step S32 at the bottom. In step S32, the transfer instruction API reply (grant / send update token) ”is executed.
Here, the "renewal token" refers to a payment application acceptance token, which will be described later.
The settlement application acceptance token is a token that is issued each time the transfer instruction API is issued and has a time limit only once.

Step S32 is executed by the accounting system 52 (50), and the reply of the transfer instruction API and the update token are transmitted to the electronic money server 30.
After the end of step S32, the process proceeds to step S22 in the center row. In step S22, "reception of transfer instruction API (reception of update token)" is executed, and the payment processing reception number issued together with the payment application reception token in the transfer instruction API is received. Step S22 is executed by the electronic money server 30.

After the end of step S22, the process proceeds to step S23 at the bottom. In step S23, "creation / transmission of transfer execution API (access using update token) is executed. Step S23 is executed by the electronic money server 30, and the update token and payment processing reception number are used. The API base 40 is accessed and the transfer execution API is transmitted.
After the end of step S23, the process proceeds to step S33 in the right column. In step S33, "reception / execution of transfer execution API" is executed. Step S33 is performed by the API platform 40.

Step S33 proceeds to lower step S34. In step S34, "withdrawal of the charge amount (3,000 yen) from the user's deposit / savings account by the accounting system (account balance: 7,000 yen)" is executed. Step S34 is executed by the core banking system 52 (50) based on the “transfer execution API” transmitted from the API base 40.
After the end of step S34, the process proceeds to step S35 at the bottom. In step S35, "transfer the charge amount (3,000 yen) to the transfer destination account of the electronic money business operator by the accounting system" is executed. Step S35 is performed by core banking system 52 (50).

After the end of step S35, the process proceeds to step S36 at the bottom. In step S36, "reply of transfer execution API (processing result: success)" is executed. Step S36 is executed by the API platform 40 based on the report from the core banking system 52 (50), and sends the "code of success" to the electronic money server 30.
After the end of step S36, the process proceeds to step S24 in the center row. In step S24, "reception of success code, addition of charge amount (5,000 yen remaining), transmission of charge completion notification" is executed. Step S24 is executed on the electronic money server 30, and sends a "charge completion notification" to the user's communication terminal 21.

After the end of step S24, the process proceeds to step S11 in the left column. In step S11, "completion of charge completion notification (balance display: 5,000 yen)" is executed. Step S11 is executed on the communication terminal 21, and when the user confirms the "balance display: 5,000 yen" displayed on the display of the communication terminal 21, the "electronic money charge request (3,000 yen)" is executed. You can confirm that it was done.

(Explanation of FIG. 4)
FIG. 4 is a flowchart for explaining the auto-charging process of electronic money.
It is divided into three columns, and the left column on the left side of FIG. 4 describes the operation of the electronic terminal 61 of the store. The central column in the center explains the operation of the electronic money server 30 of the electronic money business operator, and the right column on the right side explains the operation of the API platform 40 and the core banking system 52 (50) of the financial institution.

First, the process proceeds to step S40 in the left column, and the "electronic money payment operation (3,000 yen)" is executed. Step S40 is executed using the electronic terminal 61 of the store, and the estimated usage amount of the user is transmitted to the electronic money server 30 of the electronic money business operator.
After the end of step S40, the process proceeds to step S50 in the center row. In step S50, it is determined that "is the money balance sufficient?" Step S50 is executed by the electronic money server 30.

Here, two cases are assumed.
Case 1 is a case where the money balance is "5,000 yen" and exceeds the planned usage amount (3,000 yen), so the determination result in step S50 is "Yes" (YES).
In case 2, when the money balance is "2,000 yen", the amount is less than the planned usage amount (3,000 yen) and is insufficient, so the determination result in step S50 is "No" (NO).

In case 1, "Yes" (YES), the process proceeds from step S50 to step S54 at the bottom of the center row.
In step S54, "payment processing (payment amount: 3,000 yen)" is executed. Step S54 is executed by the electronic money server 30 and transmits "payment completed" to the electronic terminal 61.
After the end of step S54, the process proceeds to step S41 in the left column. In step S41, the user is notified of "payment completed". Step S41 is executed by the electronic terminal 61.
Since the money balance has been reduced from "5,000 yen" to "2,000 yen", the user can confirm that the payment has been executed from the money balance.

Next, the case of Case 2, that is, the case where the money balance is insufficient will be described.
In case 2, "No" (NO), the process proceeds from step S50 to step S51 immediately below.
In step S51, "creation / transmission of transfer instruction API by additional amount of money" is executed. Step S51 is executed by the electronic money server 30, and the created transfer instruction API is transmitted to the API base 40.
Here, as the "money additional amount", a predetermined method is selected from the charge amount determined in advance by the user or the shortage amount with respect to the money balance owned by the user, and the "money additional amount" is "5,000 yen". Is illustrated.

After the end of step S51, the process proceeds to step S61 in the right column.
If there is no electronic money balance in step S61, the content of the insufficient balance is returned. The error code is "400" as illustrated in FIG. 10, and the transfer instruction API responds with an insufficient balance error. Here, it is assumed that the balance of electronic money is "20,000 yen".

In S61, "reception of transfer instruction API" is executed. Step S61 is performed by the API platform 40.
After the end of step S61, the process proceeds to step S62 at the bottom. In step S62, the transfer instruction API reply (granting / transmitting the update token) ”is executed.
Here, the "renewal token" refers to a payment application acceptance token, which will be described later.
The settlement application acceptance token is issued each time the transfer instruction API is issued, and is a one-time, time-limited token.

Step S62 is executed by the accounting system 52 (50), and the reply of the transfer instruction API and the update token are transmitted to the electronic money server 30.
After the end of step S62, the process proceeds to step S52 in the center row. In step S52, "reception of transfer instruction API (reception of update token)" is executed, and the payment processing reception number issued together with the payment application reception token in the transfer instruction API is received. Step S52 is executed by the electronic money server 30.

After the end of step S52, the process proceeds to step S53 at the bottom. In step S53, "creation / transmission of transfer execution API (access using update token) is executed. Step S53 is executed by the electronic money server 30, and uses the update token and the payment processing reception number. The API base 40 is accessed and the transfer execution API is transmitted.
After the end of step S53, the process proceeds to step S63 in the right column. In step S63, "reception / execution of transfer execution API" is executed. Step S63 is performed by the API platform 40.

After the end of step S63, the process proceeds to step S64 at the bottom. In step S63, "withdrawal of additional money (5,000 yen) from the user's deposit / savings account by the core banking system (account balance: 15,000 yen)" is executed. Step S64 is executed by the core banking system 52 (50) based on the "transfer execution API" transmitted from the API base 40.
After the end of step S64, the process proceeds to step S65 at the bottom. In step S65, "transfer the additional amount of money (5,000 yen) to the transfer destination account of the electronic money business operator by the accounting system" is executed. Step S65 is performed by core banking system 52 (50).

After the end of step S65, the process proceeds to step S66 at the bottom. In step S66, "reply of transfer execution API (processing result: success)" is executed. Step S66 is executed by the API platform 40 based on the report from the core banking system 52 (50), and sends a "success code" to the electronic money server 30.
After the end of step S66, the process proceeds to step S55 in the center row. In step S55, "receipt of success code, addition of additional money (5,000 yen) (remaining 7,000 yen)" is executed. Step S55 is executed on the electronic money server 30.

After the end of step S55, the process proceeds to the upper step S54 described above. In step S54, "payment processing (payment amount: 3,000 yen)" is executed, and then the process proceeds to step S41 in the left column.
In step S41, the user is notified of "payment completed".
Since the money balance has increased from "2,000 yen" to "4,000 yen", the user can confirm that the money balance is insufficient and the additional money amount (5,000 yen) has been auto-charged.

(Explanation of FIG. 5)
FIG. 5 is a flowchart of registration of a charging account number in the charging of electronic money.
By registering the charging account number in advance using the communication terminal 21 owned by the user using FIG. 5, the user can charge the electronic money simply by inputting the charge amount.
By registering the transfer source account (user account) in advance using the transfer instruction API, the user can transfer money without specifying his / her own account or transfer destination account.
It is divided into three columns, and the left column on the left side of FIG. 5 describes the operation of the user's communication terminal 21. The central column in the center explains the operation of the electronic money server 30 of the electronic money business operator, and the right column on the right side explains the operation of the API platform 40 of the financial institution.

First, the process proceeds to step S100 in the left column, and the "request for connection with the account number" is executed (see screen 70 in FIG. 6). In step S100, the financial institution is requested to connect to the account by using the "smartphone application" installed on the communication terminal 21.
After the end of step S100, the process proceeds to step S110 in the center row. In step S110, the "API login request" is executed. Step S110 is executed by the electronic money server 30 of the electronic money operator. The electronic money server 30 executes a login request to the API platform 40 of the financial institution.

After the end of step S110, the process proceeds to step S120 in the right column. In step S120, "API login screen, redirect" is executed. The API platform 40 of the financial institution uses the "open API" to return (redirect) the "API login screen" to the user's communication terminal 21 in response to the login request.

After the end of step S120, the process proceeds to step S101 in the left column. In step S101, "login screen display (ID, password) is executed." Open API "is used for" login screen display ", and" login screen "is displayed on the display of the communication terminal 21 ("login screen display". See screen 71 in FIG. 6). The user inputs an ID, password, etc. on the "login screen".

After the end of step S101, the process proceeds to step S122 in the right column. In step S122, "API authorization screen, redirect" is executed. The API platform 40 of the financial institution performs authentication processing and returns (redirects) the "API authorization screen" to the user's communication terminal 21 using the "open API".
After the end of step S122, the process proceeds to step S102 in the left column. In step S102, "API authorization screen display (authorization authorization response)" is executed. An "open API" is used for the "API authorization screen display", and the "API authorization screen" is displayed on the display of the communication terminal 21 (see screen 72 in FIG. 6).

After the end of step S102, the process proceeds to step S123 in the right column. In step S123, the "API authorization process (authorization success)" is executed. The information for approving the service (electronic money charge here) is transferred to the API platform 40 of the financial institution, and the "authorization code" for the electronic money charge is transmitted to the smartphone application using the "open API".

After the end of step S123, the process proceeds to step S103 in the left column. In step S103, "authorization code receipt" is executed. Step S103 is executed by using the "smartphone application" of the communication terminal 21. After that, the "smartphone application" of the communication terminal 21 uses the "authorization code" to acquire the reference system talk such as account information, balance / deposit / withdrawal details, etc. to the API platform 40 via the electronic money server 30.

After the end of step S103 in the left column, the process proceeds to step S111 in the center column. In step S111, the "reference access token request" is executed. Step S111 is executed by the electronic money server 30 of the electronic money operator.
After the end of step S111, the process proceeds to step S124 in the right column. In step S124, "API authorization server, access token issuance" is executed. Step S124 is performed using the "open API" by the financial institution's API platform 40.

After the end of step S124, the process proceeds to step S112 in the center row. In step S112, "account number inquiry API required with access token" is executed. Step S112 is executed by the electronic money server 30 of the electronic money operator, executes the account number inquiry API using the reference token, and acquires the target account information used for the electronic money charge from the accounting system 52 (50). do.

After the end of step S112, the process proceeds to step S125 in the right column. In step S125, "account number inquiry API reception / reply" is executed. Step S125 is performed using the "open API" by the financial institution's API platform 40.
After the end of step S125, the process proceeds to step S113 in the center row. In step S113, "display a list of account numbers for the application" is executed. Step S113 is executed by the electronic money server 30 of the electronic money business operator, provides the list data of the target accounts to the smartphone application, and the user selects and saves the account number in the electronic money management function system 32. ..

After the end of step S113, the process proceeds to step S104 in the left column. In step S104, "select an account number for payment" is executed. Step S104 is executed by the "smartphone application" of the user's communication terminal 21.
After the end of step S104, the process proceeds to step S114 in the center row. In step S114, "registering the database of account numbers for settlement" is executed. Step S114 is executed by the electronic money server 30 of the electronic money operator.

(Explanation of FIG. 6)
FIG. 6 is an explanatory diagram for explaining an example of the screen of the communication terminal 21.
Screens 70 to 74 relate to the process of registering the account number for settlement shown in FIG.
The screen 70 corresponds to step S100 in FIG.
The screen 71 corresponds to steps S120 and S101 of FIG.
The screen 72 corresponds to steps S122 and S102 of FIG.
The screen 73 corresponds to step S113 in FIG.
The screen 74 corresponds to step S114 of FIG. 5 and is a “completion screen”.

(Explanation of FIG. 7)
FIG. 7 is an explanatory diagram for explaining another example of the screen of the communication terminal 21.
Screens 80,81 relate to the charge process shown in FIG.
The screen 80 corresponds to step S10 in FIG.
Screen 81 corresponds to step S11 in FIG. 3, and assumes a case where the balance of electronic money is “5,000 yen”.

(Explanation of FIG. 8)
FIG. 8 shows an example of a user's account details.
At the bottom, "Withdrawal: 3,000" yen, "Deposit (passbook description): Electronic money charge", and "Balance: 7,000" yen are displayed.
The withdrawal amount of "3,000" yen for "electronic money charge" is subtracted from the "balance: 10,000" yen in the upper row.

(Explanation of FIG. 9)
FIG. 9 shows an example of the account details of the electronic money business operator.
At the bottom, "Withdrawal (passbook description): Charge deposit", "Deposit: 3,000" yen, and "Balance: 1,051,500" yen are displayed.
"Balance: 1,048,5000" yen in the upper row is added with "3,000" yen for the deposit of "electronic money charge".

(Explanation of FIG. 10)
FIG. 10 is an excerpt of a part of a list for explaining a list of response codes for API requests.
The following three examples of the "HTTP status code" will be described.
(1) Code "201" (normal processing)
The code "201" is output at the time of "(normal processing)", and the "answer items" are as follows.
"Payment processing reception number, payment processing reception date, payment processing reception time, etc."
The remarks are as follows.
"Request transfer execution API by payment processing reception number"

(2) Code "400" (error)
The code "400" is output at the time of "(error)", and the "answer items" are as follows.
"Error information (insufficient balance, suspension of usage account, etc.)"
The remarks are as follows.
"Interruption of e-commerce charge"

(3) Code "503" (error)
The code "503" is also output at the time of "(error)", and the "answer items" are as follows.
"Error information (out of core banking system hours)"
The remarks are the same as "(2) Code" 400 "(error)" and are omitted.

(Explanation of FIG. 11)
FIG. 11 is for explaining a usage example of the IC card 23.
The IC card 23 is an example of an electronic money card 20 owned by a user and shown in FIG. 1. An IC chip is embedded therein, and the IC chip functions as an electronic money unit 21.

The electronic money unit 21 mainly has the balance management of electronic money, and here, personal information and electronic money information for confirming the identity of the user are stored.
The IC card 23 is brought to a store, for example, and the electronic information stored in the electronic money communication device 63 installed in the store is read. The electronic money communication device 63 also serves as an electronic money reading device, and communicates with the IC card 23 via an internal sensor.
After that, the electronic money communication device 63 communicates with the electronic money management system 32 of the electronic money server 30 of the electronic money business operator, and executes the operation of the electronic money including the charge processing.

(Explanation of FIG. 12)
FIG. 12 is for explaining a usage example of the smartphone 25.
FIG. 12 shows a case where the smartphone 25 is used instead of the IC card 23 of FIG.
The smartphone 25 is an example of the communication terminal 21 owned by the user and shown in FIG. The electronic money application 26 is installed on the smartphone 25, and the electronic money application 26 is an example of a smartphone application, and in addition to the communication function, personal information for confirming the identity of the user is stored.

The smartphone 25 communicates with the electronic money server 30 of the electronic money business operator via the Internet, and executes the operation of electronic money including charge processing. The electronic money server 30 has an electronic money unit 21, and the electronic money unit 21 mainly has electronic money balance management as described above.

(Explanation of FIG. 13)
FIG. 13 is for explaining a usage example of the prepaid card 27 or the smartphone 25.
FIG. 13 shows a case where a prepaid card 27 or a smartphone 25 is used instead of the IC card 23 of FIG.
The prepaid card 27 is an example of the electronic money card 20 owned by the user and shown in FIG. 1, and a “bar code” is displayed on the surface of the card. Although the "bar code" is illustrated, the present invention is not limited to this, and a "two-dimensional code" other than the "bar code" may be displayed.

The prepaid card 27 is, for example, brought to a store or the like and read by an electronic money reading device 64 such as a bar code reader installed in the store. The read information is transmitted to the POS cash register 65 to which the electronic money reader 64 is connected, and the POS cash register 65 communicates with the electronic money server 30 of the electronic money operator by the communication function, and the electronic money including the charge processing is used. Perform operations.

The electronic money server 30 has an electronic money unit 21, and the electronic money unit 21 mainly has electronic money balance management as described above.
On the other hand, when using the smartphone 25, the display function of the smartphone application installed on the smartphone 25 is used to display a "bar code" on the screen. Although the "bar code" is illustrated, the present invention is not limited to this, and a "two-dimensional code" other than the "bar code" may be displayed.
The "bar code" displayed on the screen is read and used by an electronic money reading device 64 installed at a store or the like, like a prepaid card 27.

(Explanation of FIG. 14)
FIG. 14 is a flowchart for explaining an auto charge process using the IC card 23.
Since FIG. 14 has a part in common with FIG. 4 described above, the same reference numerals are used for the common components, and the description thereof will be omitted.

First, the user proceeds to step S40 in the left column, and the user executes the "electronic money payment operation (for 3,000 yen)" using the IC card 23.
After the end of step S40, the process proceeds to step S70 at the bottom. In step S70, the IC card 23 determines "is the money balance sufficient?"

As shown in FIG. 11, the IC card 23 has an electronic money unit 21 and has electronic money balance management. Therefore, on the POS cash register 65 (see FIG. 13) side installed at a store or the like, the balance of electronic money stored in the IC card 23 can be compared with the planned usage amount.
As a result, if the balance of electronic money is sufficient, the process proceeds to "Yes" (YES), and the process proceeds from step S70 to step S71 in the lower row. In step S71, the "payment process (payment amount: 3,000 yen)" is executed using the IC card 23.

After the end of step S71, the process proceeds to step S41 at the bottom, and the user is notified that the "payment completed" has been completed, for example, by using the POS cash register 65.
On the other hand, when the money balance is insufficient, that is, when the money balance is insufficient, the process proceeds from step S70 to step S51 in the center column, and thereafter, the auto charge process described with reference to FIG. 4 is executed.

(Explanation of FIG. 15)
FIG. 15 is an explanation created for comparing the first embodiment of the present invention described with reference to FIGS. 1 to 14 and the second embodiment described later with reference to FIGS. 16 and 16. Therefore, the description will be omitted.

(Explanation after the second embodiment)
16th and subsequent embodiments will be described with reference to the second to fifth embodiments of the present invention.
FIG. 16 is for explaining a second embodiment of the present invention.
As shown in FIG. 16, the second embodiment is characterized in that the charge support server 100 is used.

As shown in FIG. 16, the charge support server 100 is located between the electronic money server 30 and the API base 40, and is for supporting the charging of electronic money by the electronic money server 30 and the API base 40. ..

FIG. 17 is for explaining a third embodiment of the present invention.
As shown in FIG. 17, the third embodiment is characterized in that a settlement processing number is used.
The payment processing number is used between the API base 40 and the charge support server 100, and is transmitted from the API base 40.
FIG. 18 is for explaining the outline of the electronic money support system according to the second and third embodiments of the present invention.

19 and 20 are for explaining the fourth embodiment of the present invention.
The fourth embodiment is characterized in that two fixed-length first and second telegrams 210 and 240 are used for the "telegram".
20 and 21 are for explaining the fifth embodiment of the present invention.
The fifth embodiment is characterized in that one general-purpose third telegram 250 is used for the "telegram".

(Characteristic points according to the second to fifth embodiments of the present)
The features of the present invention according to the second to fifth embodiments of the present invention will be described below.

(10th feature point)
The tenth feature of the present invention is as follows with respect to the "method of charging electronic money".
First, the method of charging electronic money is premised on the following configuration, for example, as shown in FIG.
The same applies to the third embodiment shown in FIG. 17, for example.
(1) Electronic money server 30
The electronic money server 30 manages electronic money owned by the user.

(2) Charge support server 100
As shown in FIGS. 19 to 22, for example, the charge support server 100 can communicate with the electronic money server 30, and communicates using the telegrams 210, 240, 250 unique to the electronic money server 30.
Here, the "telegram" includes two fixed-length first and second telegrams 210 and 240 as shown in FIGS. 19 and 20, and one general-purpose telegram as shown in FIGS. 21 and 22. The third telegram 250 and is included.

(3) API platform 40
As shown in FIG. 16, the API platform 40 can communicate with the electronic money server 30, and manages an open API (for example, a transfer API) opened to the charge support server 100.
(4) Core banking system 52
As shown in FIG. 16, for example, the accounting system 52 is connected to the API platform 40, and deposits and withdrawals to the deposit and savings account owned by the user, and the transfer destination owned by the management entity that manages the electronic money server 30. It is possible to transfer money to an account.

Secondly, the method of charging electronic commerce includes the following steps, for example, as shown in FIG.
The same applies to the third embodiment shown in FIG. 17, for example.
(5) First Step In the first step, for example, as shown in FIG. 16, at least an electronic money number unique to electronic money and a charge amount are transmitted from the electronic money server 30 based on the intention of the user. On condition that the including telegrams 210 and 250 are received, the charge support server 100 creates a transfer API which is an open API using the access token peculiar to the service, and transmits the transfer API to the API base 40 (for example, FIG. 16). (See steps S210 to S212).

(6) Second Step In the second step, for example, as shown in FIG. 16, the transfer API is executed on the API base 40 on the condition that the transfer API is received, and the same amount as the charge amount determined by the user is applied. , Withdrawal from the deposit / savings account by the core banking system 52 (see, for example, steps S213 and S214 in FIG. 16).
In addition to this, in the second step, for example, as shown in FIG. 16, the same amount as the charge amount is simultaneously transferred to the transfer destination account by the core banking system 52 (see, for example, step S214 in FIG. 16).

(7) Third step As shown in FIG. 16, for example, the third step is to transmit a "success code" to the charge support server 100 on the API platform 40 after simultaneous execution of withdrawal and transfer. (See, for example, steps S215 and S216 in FIG. 16).
(8) Fourth step As shown in FIG. 16, for example, in the fourth step, on the condition that the "success code" is received, the charge support server 100 adds electronic money of telegrams 240 and 250 to which normal processing data is added. It is transmitted to the server 30 (see, for example, step S217 in FIG. 16).

(9) Fifth step In the fifth step, for example, as shown in FIG. 16, the charge amount is added to the money balance of the electronic money owned by the user on the electronic money server 30 on condition that the telegrams 210, 240, 250 are received. (See, for example, step S218 in FIG. 16).

(Effect of 10th feature point)
The tenth feature point has the following effects with respect to the "method of charging electronic money".
That is, according to the tenth feature point, the funds of the electronic money business operator are obtained by immediately sending the money from the user's deposit / savings account to the electronic money business operator using the open API for the electronic money charge. It is possible to accelerate the conversion and payment to member stores.

In addition to this, according to the tenth feature, by adding the charge support server 100, it is possible to quickly process a telegram peculiar to the electronic money server 30.
That is, according to the tenth feature point, first, the processing load on the electronic money server 30 side can be reduced.

In the first embodiment of the invention shown in FIG. 15, as shown in the figure, the processing related to the open API was performed in steps S200 and S202.
On the other hand, according to the tenth feature point, as shown in FIG. 16, since the processing related to the open API is executed on the charge support server 100 side in steps S211, S212, and S217, the same processing is performed. It can be processed quickly.

Secondly, according to the tenth feature point, the load on the API substrate 40 side can be reduced.
That is, in the first embodiment of the invention shown in FIG. 15, as shown in FIG. 15, "transmission of access token" was executed from the API substrate 40 in step 201.
On the other hand, according to the tenth feature point, since the transfer API, which is an open API, is created on the charge support server 100 side using the service-specific access token, the burden on the API board 40 side is borne. Can be reduced.

(11th feature point)
The eleventh feature point of the present invention is as follows, in addition to the feature point of the invention described in the tenth feature point described above, regarding the "method of charging electronic money".
First, the telegrams 210 and 240 include the following configurations, for example, as shown in FIGS. 17, 19 and 20.
(1) First telegram 210
The first telegram 210 includes at least an electronic money number unique to electronic money and a charge amount, as shown in FIG. 19, for example.
(2) Second telegram 240
The second telegram 240 is set with data for normal processing, for example, as shown in FIG.
Here, "set" means "record".

Second, in the first step, for example, as shown in FIGS. 17 and 19, the first telegram 210, which is a fixed long telegram, is converted into transfer APIs 220 and 230 and then transmitted to the API base 40 (for example, shown in FIG. 17). See steps S221, S222, S224).
Third, in the fourth step, for example, as shown in FIGS. 17 and 20, the transfer APIs 220 and 230 are converted into the second telegram 240, which is a fixed long telegram, and transmitted to the electronic money server 30 (for example, FIG. See steps S227 to S229 shown in 17).

(Effect of the eleventh feature point)
The eleventh feature point has the following effects in addition to the tenth feature point described above with respect to the "method of charging electronic money".
That is, according to the eleventh feature point, the burden on the electronic money server 30 side can be reduced by using the fixed length format as the telegram on the charge support server 100 side.

(12th feature point)
The twelfth feature point of the present invention is as follows, in addition to the feature point of the invention described in the tenth feature point described above, regarding the "method of charging electronic money".
First, the telegram (third telegram 250) is a general-purpose telegram, for example, as shown in FIGS. 21 and 22.

Second, in the first step, for example, as shown in FIG. 21, transfer APIs 260 and 270 are created using a general-purpose telegram (third telegram 250) (see, for example, steps S221, S222, S224 shown in FIG. 17). ..
Third, in the fourth step, for example, as shown in FIG. 22, a "success code" is set in the general-purpose telegram (third telegram 250) and transmitted to the electronic money server 30 (for example, in FIG. 17). See steps S228 and S229 shown).
Here, "set" means "record".

(Effect of the 12th feature point)
The twelfth feature point has the following effects in addition to the tenth feature point described above with respect to the "method of charging electronic money".
That is, according to the twelfth feature point, the burden on the electronic money server 30 side can be reduced by using the telegram (third telegram 250) on the charge support server 100 side and using the general-purpose format.

(13th feature point)
The thirteenth feature point of the present invention is as follows, in addition to the feature point of the invention described in the tenth feature point described above, regarding the "method of charging electronic money".
First, the charge support server 100 includes, for example, as shown in FIG. 16, a linking database 200 that links an electronic money number and a deposit / savings account.
The same applies to the third embodiment shown in FIG. 17, for example.

Secondly, in the first step, for example, as shown in FIG. 19, the deposit / savings account information regarding the deposit / savings account is added to the transfer API 220 based on the electronic money number included in the telegram 210 using the linking database 200. (See, for example, steps S221 and 222 in FIG. 17).
The same applies to the fifth embodiment shown in FIG. 21, for example.

(Effect of the thirteenth feature point)
The thirteenth feature point has the following effects in addition to the tenth feature point described above with respect to the "method of charging electronic money".
That is, according to the thirteenth feature point, by using the linking database 200, the deposit / savings account information regarding the deposit / savings account can be quickly transferred to the transfer API 220,260 on the charge support server 100 side based on the electronic money number. And it can be added reliably.

(14th feature point)
The invention described in the fourteenth feature point is as follows in addition to the feature point of the invention described in the thirteenth feature point described above with respect to the "method of charging electronic money".
First, the associative database 200 stores access tokens, for example, as shown in FIG.
The same applies to the fifth embodiment shown in FIG. 21, for example.

Secondly, in the first step, as shown in FIGS. 16 and 19, for example, the access token stored in the association database 200 is read, and the read access tokens are used to create transfer APIs 220 and 260 (for example, FIG. See steps S211,212 shown in 16.)
The same applies to the fifth embodiment shown in FIG. 21, for example.

(Effect of the 14th feature point)
The fourteenth feature point has the following effects in addition to the thirteenth feature point described above with respect to the "method of charging electronic money".
That is, according to the 14th feature point, the access token stored in the association database 200 is read, and the transfer APIs 220 and 260 are quickly and surely created on the charge support server 100 side using the read access token. can.

(15th feature point)
The fifteenth feature point of the present invention is as follows, in addition to the feature point of the invention described in the thirteenth feature point described above, regarding the "method of charging electronic money".
First, the telegrams 210 and 240 include the following configurations, for example, as shown in FIGS. 17, 19 and 20.
(1) First telegram 210
The first telegram 210 includes at least an electronic money number unique to electronic money and a charge amount, as shown in FIG. 19, for example.

(2) Second telegram 240
The second telegram 240 is set with data for normal processing, for example, as shown in FIG.
Secondly, the transfer APIs 220 and 230 include the following configurations, for example, as shown in FIG.
(3) Transfer instruction API
The transfer instruction API is an open API (see, for example, transfer API 220 (telegram conversion) in FIG. 19).

(4) Transfer execution API
The transfer execution API is an open API (see, for example, transfer API 230 (telegram execution) in FIG. 19).

Third, the first step includes the following steps, for example, as shown in FIG.
(5) 10th step As shown in FIG. 17, for example, the 10th step is an open API using the access token registered in advance by the user on the charge support server 100 on condition that the first telegram 210 is received. A transfer instruction API (see, for example, transfer API 220 (telegram conversion) in FIG. 19) is created, and the transfer instruction API is transmitted to the API base 40 (see, for example, steps S221 and 222 shown in FIG. 17).

(6) 11th step In the 11th step, for example, as shown in FIG. 17, the payment processing number is set on the API base 40 on the condition that the transfer instruction API (for example, refer to the transfer API 220 (telegram conversion) in FIG. 19) is received. It responds to the charge support server 100 (see, for example, step S223 shown in FIG. 17).

(7) 12th step In the 12th step, for example, as shown in FIG. 17, the payment processing set in the response portion of the transfer instruction API (for example, refer to the transfer API 220 (message conversion) in FIG. 19) in the charge support server 100. Create a transfer execution API (see, for example, transfer API 230 (message execution) in FIG. 19) using the number, and use the service-specific access token prepared in advance to create the transfer execution API (for example, transfer API 230 (message execution) in FIG. 19). ) Is transmitted to the API substrate 40 (see, for example, step S224 shown in FIG. 17).

Fourth, in the second step, as shown in FIG. 17, for example, on the condition that the transfer execution API (for example, see the transfer API 230 (telegram execution) in FIG. 19) is received, the transfer execution API (for example, the transfer execution API (for example)) is performed on the API base 40. Execute the transfer API230 (see telegram execution) in FIG. 19 (see, for example, step S225 shown in FIG. 17).

Fifth, in the fourth step, as shown in FIG. 17, for example, on the condition that the "success code" is received, the charge support server 100 adds the data of normal processing to the second telegram 240 to the electronic money server. 30 is transmitted (see, for example, steps S229 and S230 shown in FIG. 17).
Sixth, in the fifth step, as shown in FIG. 17, for example, on condition that the second telegram 240 is received, the electronic money server 30 adds the charge amount to the money balance of the electronic money owned by the user. (See, for example, step S230 shown in FIG. 17).

(Effect of the 15th feature point)
The fifteenth feature point has the following effects in addition to the fourteenth feature point described above with respect to the "method of charging electronic money".
That is, according to the fifteenth feature point, the security between the charge support server 100 and the API platform 40 can be improved by using the payment processing number.

(16th feature point)
The 16th feature of the present invention is as follows with respect to the "electronic money support system".
First, the electronic money support system 10 is premised on the following configuration, for example, as shown in FIG.
The same applies to the third embodiment shown in FIG. 17, for example.
(1) Electronic money server 30
The electronic money server 30 manages electronic money owned by the user.

(2) Charge support server 100
As shown in FIGS. 19 to 22, for example, the charge support server 100 can communicate with the electronic money server 30, and communicates using the telegrams 210, 240, 250 unique to the electronic money server 30.
Here, the "telegram" includes two fixed-length first and second telegrams 210 and 240 as shown in FIGS. 19 and 20, and one general-purpose telegram as shown in FIGS. 21 and 22. The third telegram 250 and is included.

(3) API platform 40
As shown in FIG. 16, the API platform 40 can communicate with the electronic money server 30, and manages an open API (for example, a transfer API) opened to the charge support server 100.
(4) Core banking system 52
As shown in FIG. 16, for example, the accounting system 52 is connected to the API platform 40, and deposits and withdrawals to the deposit and savings account owned by the user, and the transfer destination owned by the management entity that manages the electronic money server 30. It is possible to transfer money to an account.

Secondly, as shown in FIG. 16, for example, the charge support server 100 is transmitted from the electronic money server 30 based on the intention of the user, and includes at least an electronic money number unique to electronic money and a charge amount. A transfer API, which is an open API, is created using the service-specific access token on condition that the telegrams 210, 240, and 250 are received, and the transfer API is transmitted to the API base 40 (see, for example, steps S210 to S212 in FIG. 16).
The same applies to the third embodiment shown in FIG. 17, for example.

Thirdly, as shown in FIG. 16, the API platform 40 executes the transfer API on condition that the transfer API is received, and the same amount as the charge amount determined by the user is set in the deposit / savings account by the accounting system 52. At the same time, the same amount as the charge amount is transferred to the transfer destination account by the accounting system 52 (see, for example, steps S213 and S214 in FIG. 16).
The same applies to the third embodiment shown in FIG. 17, for example.

Fourth, as shown in FIG. 16, the API platform 40 transmits a "success code" to the charge support server 100 after simultaneous execution of withdrawal and transfer (see, for example, steps S215 and S216 in FIG. 16).
The same applies to the third embodiment shown in FIG. 17, for example.

Fifth, as shown in FIG. 16, for example, the charge support server 100 transmits the telegrams 210, 240, 250 to which the normal processing data is added to the electronic money server 30 on condition that the "success code" is received, and the electronic money server 100. At 30, on condition that the telegrams 210, 240, 250 are received, the charge amount is requested to be added to the money balance of the electronic money owned by the user (see, for example, steps S217 and S218 in FIG. 16).
The same applies to the third embodiment shown in FIG. 17, for example.

(Effect of 16th feature point)
The 16th feature point has the same effect as the 10th feature point described above with respect to the "electronic money support system".

(Second Embodiment shown in FIG. 16)
FIG. 16 is for explaining a second embodiment of the present invention.
As shown in FIG. 16, the second embodiment is characterized in that the charge support server 100 is used.
In addition to this, the second embodiment is characterized in that the association database 200 (hereinafter, also referred to as “association DB”) is used in association with the charge support server 100.

As shown in FIG. 16, the charge support server 100 is located between the electronic money server 30 and the API base 40, and is for supporting the charging of electronic money by the electronic money server 30 and the API base 40. ..
In the description of the second embodiment, the same components as those of the first embodiment described above with reference to FIGS. 1 to 15 are designated by the same reference numerals, and the description thereof will be omitted. do.

First, in FIG. 16, the process proceeds to step S210, and the "creation / transmission of telegram" is executed on the electronic money server 30. The "telegram" is transmitted to the "charge support server 100" in the electronic money server 30.
Here, the "electronic money server 30" manages the electronic money owned by the user.
Here, the "telegram" includes two fixed-length first and second telegrams 210 and 240 as shown in FIGS. 19 and 20, and one general-purpose telegram as shown in FIGS. 21 and 22. The third telegram 250 and is included.

After executing step S210, the process proceeds to the next step S211. In step S211, "acquisition of deposit / savings account information from telegram" is executed on the charge support server 100.
Here, the "charge support server 100" is capable of communicating with the electronic money server 30, and communicates using the telegrams 210, 240, 250 unique to the electronic money server 30.

Further, in step S211 the charge support server 100 executes communication with the associated DB 200.
That is, the charge support server 100 reads the access token stored in the associated DB 200.

After executing step S211 to the next step S212. In step S212, the charge support server 100 executes "creation / transmission of transfer API". The "transfer API" is transmitted to the API platform 40 on the charge support server 100.
Here, the "transfer API" is an open API.
The charge support server 100 reads the access token stored in the associated DB 200 in step S211 and creates the transfer APIs 220 and 230 shown in FIG. 19 using the read access token in the next step S212.
The same applies to the fifth embodiment shown in FIG.

After executing step S212, the process proceeds to the next step S213. In step S213, "execution of transfer API" is performed on the API base 40.
Here, the "API platform 40" manages the transfer API, which is an open API that can communicate with the electronic money server 30 and is open to the charge support server 100.
After executing step S213, the process proceeds to the next step S214. In step S214, the accounting system 52 executes "withdrawal from the user's deposit / savings account" and at the same time "transfer from the deposit / savings account to the business operator".

After executing step S214, the process proceeds to the next step S215. In step S215, the core banking system 52 executes “transmission of processing result”. The "processing result" is transmitted to the API base 40 by the core banking system 52.
Here, the "core banking system 52" is connected to the API platform 40, and deposits and withdrawals to the deposit and savings account owned by the user, and to the transfer destination account owned by the management entity that manages the electronic money server 30. The transfer can be performed.
After executing step S215, the process proceeds to the next step S216. In step S216, “creation / transmission of“ success code ”” is executed on the API platform 40. The "success code" is transmitted to the charge support server 100 on the API platform 40.

After executing step S216, the process proceeds to the next step S217. In step S217, the charge support server 100 executes "creation / transmission of telegram (normal)". The "telegram (normal)" is transmitted to the electronic money server 30 in the charge support server 100.
After executing step S217, the process proceeds to the next step S218. In step S218, the electronic money server 30 executes "adding the charge amount to the balance of the electronic money" and ends the charge process of the electronic money.

(Third embodiment shown in FIG. 17)
FIG. 17 is for explaining a third embodiment of the present invention.
The third embodiment is characterized in that a "settlement processing number" is used.
The "payment processing number" is used between the API platform 40 and the charge support server 100, and is transmitted from the API platform 40.

In the third embodiment, as compared with the second embodiment described with reference to FIG. 16, the transfer API is divided into a transfer instruction API and a transfer execution API from the viewpoint of preventing fraud countermeasures, and processing is performed. From the viewpoint of continuity and prevention of multiple frauds, it is connected by a unique "payment processing number" to enhance the security of the accounting system.
In the description of the second embodiment, it is the same as the first embodiment described above with reference to FIGS. 1 to 15 and the second embodiment described with reference to FIG. The components are designated by the same reference numerals and the description thereof will be omitted.

First, in FIG. 17, the process proceeds to step S220, and the “first telegram creation / transmission” is executed on the electronic money server 30.
Here, the "first telegram" is one of the "telegrams", and the "telegram" includes two "first telegram 210" shown in FIG. 19 and "second telegram 240" shown in FIG. There is a connoisseur. The first and second telegrams 210 and 240 are of fixed length format.

After executing step S220, the process proceeds to the next step S221. In step S221, "acquisition of deposit / savings account information from the first telegram" is executed on the charge support server 100.
Further, in step S221, the charge support server 100 executes communication with the associated DB 200.
That is, the charge support server 100 reads the access token stored in the associated DB 200.

After executing step S221, the process proceeds to the next step S222. In step S222, "creation / transmission of transfer instruction API" is executed on the charge support server 100. "The transfer instruction API is transmitted to the API base 40 in the charge support server 100.
Here, the "transfer instruction API" is a kind of "transfer API" which is an open API. The "transfer API" is composed of two types, a "transfer instruction API" and a "transfer execution API".

After executing step S222, the process proceeds to the next step S223. In step S223, "transmission of payment processing number" is executed on the API platform 40. The "payment processing number" is transmitted to the charge support server 100 on the API platform 40.
After executing step S223, the process proceeds to the next step S224. In step S224, the charge support server 100 executes "creation / transmission of transfer execution API". The "transfer execution API" is transmitted to the API platform 40 on the charge support server 100.

The "transfer execution API" is created by using the access token read from the associated DB 200 in the previous step S221 and the "payment processing number" transmitted from the API base 40 in the previous step S223.
After executing step S224, the process proceeds to the next step S225. In step S225, “execution of transfer API” is performed on the API base 40.
After executing step S225, the process proceeds to the next step S226. In step S226, the accounting system 52 executes "withdrawal from the user's deposit / savings account" and at the same time "transfer from the deposit / savings account to the business operator".

After executing step S226, the process proceeds to the next step S227. In step S227, the core banking system 52 executes “transmission of processing result”.
After executing step S227, the process proceeds to the next step S228. In step S228, “creation / transmission of“ success code ”” is executed on the API platform 40.

After executing step S228, the process proceeds to the next step S229. In step S229, the charge support server 100 executes "creation / transmission of the second telegram (normal)".
After executing step S229, the process proceeds to the next step S230. In step S230, "add the charge amount to the balance of the electronic money" is executed on the electronic money server 30, and the charge process of the electronic money is completed.

(Additional explanation of FIG. 17)
FIG. 17 described above will be additionally described with a focus on the “payment processing number”.
The transfer instruction API created by the charge support server 100 is sent to the API base 40 (see step A223), and after the API base 40 receives it, a normal request is confirmed and a "payment processing number" indicating a processing reservation is taken. Number, set the "payment processing number" in the transfer instruction API, and reply (see step S223).

The "payment processing number" is set in the request information of the transfer execution API, and the transfer execution API is transmitted to the API platform 40 (see step S224).
As for the access token, the transfer instruction API is transmitted using the user's token registered in advance in the charge support server 100 (see step S221), and the transfer execution API is the service-specific access token registered in advance in the charge support server 100. (See step S224).

Since the "payment processing number" can execute the transfer execution API only once, it has the effect of preventing a plurality of illegal processes.
The reason why the transfer instruction API and the transfer execution API are separated is that the transfer instruction API is operated from the outside, the API platform 40 returns the settlement processing number of the appropriate request, and the settlement execution API that operates the accounting system 52 using it. By executing, even if the transfer instruction API is directly executed due to a cyber attack or the like, the accounting system processing cannot be executed.

(Explanation of FIG. 18)
FIG. 18 is an explanatory diagram for explaining the outline of the electronic money support system 10 according to the second and third embodiments.
In the description of the embodiments relating to the second and third embodiments, the first embodiment described above with reference to FIGS. 1 to 15 and the first embodiment described with reference to FIG. 16 will be described. The same components as those of the second embodiment and the third embodiment described with reference to FIG. 17 are designated by the same reference numerals, and the description thereof will be omitted.

As shown in the upper part of FIG. 18, the electronic money support system 10 is functionally divided into the following four layers.
It is not limited to the following (1) to (4).
(1) Device layer 110
(2) Presentation layer 120
(3) Application layer 130
(4) API relay function layer 140
The layer of the electronic money support system 10 is not limited to (1) to (4) described above.

(Device layer 110)
The device layer 110 is composed of the following various terminals connected to the electronic money server 30.
(1) POS terminal 1111
The POS terminal 1111 has, for example, a manned "POS cash register". "POS cash register" means a cash register having a POS function, that is, a register.

(2) POS terminal 2112
The POS terminal 2112 has, for example, an unmanned "POS cash register".
(3) Dedicated terminal 113
The dedicated terminal 113 includes, for example, a “kiosk terminal”. A "kiosk terminal" is a small, self-supporting information terminal installed in stores, public facilities, railway stations, and the like.

(4) PC114
(5) Smartphone 115
The terminal connected to the electronic money server 30 is not limited to (1) to (5) described above.

(Presentation layer 120)
The presentation layer 120 is composed of POS systems 121, 122 and various applications 123 to 125.
The POS systems 121 to 125 and the like located in the presentation layer 120 are individually connected to various terminals 11 to 115 located in the device layer 110 via a dedicated line 150 and the Internet 151.

(Application layer 130)
The application layer 130 is composed of a POS management system 131 and an electronic money server 30.
The POS management system 131 is individually connected to the POS system 1121 and the POS system 1122 located in the presentation layer 120, and product management and inventory management are executed.

The POS system 1121 and the POS system 1122 are individually connected to the electronic money server 30, and after the purchase amount is confirmed, a payment message is communicated from the payment function.
Various applications 123 to 125 located in the presentation layer 120 are connected to the electronic money server 30, and payment telegrams are communicated.

(API relay function layer 140)
The API relay function layer 140 is composed of a charge support server 100, and a telegram is communicated with an electronic money server 30 located in the application layer 130.

(Fourth Embodiment shown in FIGS. 19 and 20)
19 and 20 are for explaining the fourth embodiment of the present invention.
The fourth embodiment is characterized in that, as shown in FIGS. 19 and 20, two fixed-length first and second telegrams 210 and 240 are used in the "telegram".

In the description of the fourth embodiment, the first embodiment described above with reference to FIGS. 1 to 15 and the second embodiment described with reference to FIG. 16 and FIG. 17 The same components as those of the second embodiment described with reference to and the second and third embodiments related to the second and third embodiments described with reference to FIG. 18 are designated by the same reference numerals and described. Is omitted.

(Explanation of FIG. 19)
19 and 20 illustrate the role of the charge support server.
FIG. 19 illustrates the telegram conversion at the time of charge request, and FIG. 20 illustrates the telegram conversion at the time of charge response when normally processed.
As shown in FIG. 19, the charge support server 100 receives the first telegram 210, and then uses the electronic money number (see arrow a2) and the charge linking key (see arrow a1) in the telegram to transfer API 220 (see arrow a1). Generate a transfer instruction API).

The transfer API220 (transfer instruction API) is created by linking to the HTTP request part with the user's account information (financial institution code, store number, subject, account number, etc.) derived from the electronic money number of the DB200 and the charge linking key. ) Is set in the transfer source account information which is the interface of API (see arrow a4).
For the transfer destination account number, set the account information of the electronic money business operator registered in the charge support server 100 in advance, set the charge amount in the transfer amount (see arrow a3), and create the transfer API 220 (transfer instruction API). ..

In addition, the access token acquired in advance by the user is set in the transfer API on the charge support server 100 (see arrow a5), and is transmitted to the API platform 40 to execute the telegram conversion.
The transfer API 220 (transfer instruction API) is the transfer API 230 (transfer execution API) and is executed on the API platform 40. "Transfer from account" is executed.

(Explanation of FIG. 20)
In the core banking system 51, as shown in FIG. 20, after the normal processing, the information of the normal processing is returned to the API base 40.
The API base 40 sets a "success code" representing normal processing in the transfer API 230 (transfer execution API) and the transfer API 220 (transfer instruction API), and also sets the processing result information in the response unit of the HTTP.

The charge support system 100 receives the success code of the transfer API and generates a response message (second message 240) indicating the success of the charge (see arrow b3).
In the charge response message (second message 240), set the electronic money number and charge linking key derived from the user account information of the linking DB200 based on the transfer source account information (arrows b1, b4, b5). reference).
In addition, the "success code" of the transfer API 220 (transfer instruction API) is converted into a code or status indicating the normality of the charge response telegram (second telegram 240) and transmitted to the electronic money server 30.

(Explanation of items in FIG. 19)
The "items" in FIG. 19 will be described below.
As shown in FIG. 19, the association data DB 200 (association database) includes the following items.
(A1) Charge linking key (A2) Electronic money number (A3) User account information (A4) User token

The first telegram 210 (charge request) includes the following items.
(B1) [Communication control header]
・ Size, type (requirement)
(B2) [Business common header]
・ Terminal information, charge method, (auto manual)
(B3) [Individual business information]
・ Electronic money number, charge amount, charge source information,
(Charge linking key, etc.)

The transfer API (telegram conversion) 220 includes the following items.
The transfer API (telegram conversion) 220 is also referred to as a "transfer instruction API".
(C1) [HTTP header]
・ Access token (C2) [HTTP (request)]
・ Transfer amount, transfer source account information, transfer destination account information (C3) [HTTP (response)]

The transfer API (Telegram Execution) 230 includes the following items.
The transfer API (telegram execution) 230 is also referred to as a “transfer execution API”.
Further, the items of the transfer API (telegram execution) 230 are the same as those of the transfer API (telegram conversion) 220 described above.
(D1) [HTTP header]
・ Access token (D2) [HTTP (request)]
・ Transfer amount, transfer source account information, transfer destination account information (D3) [HTTP (response)]

Next, the arrows a1 to a5 in FIG. 19 will be described below.
The "arrow a1" reads out the "(charge linking key, etc.)" in the "[business individual information]" of the first telegram 210 on the charge support server 100, and uses it as the "charge linking key" of the linking data DB 200. to access.

The “arrow a2” reads the “electronic money number” in the “[business individual information]” of the first telegram 210 on the charge support server 100, and accesses the “electronic money number” of the linked data DB 200.
The "arrow a3" reads the "charge amount" in the "[business individual information]" of the first message 210 on the charge support server 100, and reads the "charge amount" of the transfer API (message conversion) 220 (transfer instruction API) "[HTTP ( Set to "Transfer amount" in "Request)]".

The "arrow a4" converts the "transfer source account information" obtained from the "user account information" of the linked data DB 200 on the charge support server 100 to the "[HTTP" of the transfer API (transmission conversion) 220 (transfer instruction API). (Request)]] and set it in "Transfer source account information".
The "arrow a5" is the "[HTTP header]" of the transfer API (message conversion) 220 (transfer instruction API) of the "access token" obtained from the "user token" of the linked data DB 200 on the charge support server 100. Set to.

(Explanation of items in FIG. 20)
The "items" in FIG. 20 will be described below.
Since the items of the association data DB 200 (association database) are the same as those shown in FIG. 19, the description thereof will be omitted.
Since the items of the second telegram 240 (charge response) are the same as those of the first telegram 210 (charge request) shown in FIG. 19, the description thereof will be omitted.

In the transfer API (telegram conversion) 220 (transfer instruction API), the following items are included in the items of [HTTP (response)].
(1) Success code (2) Processing result information, etc. Other items in the transfer API (telegram conversion) 220 (transfer instruction API) are the same as those shown in FIG. 19, so the description is omitted. ..

In the transfer API (telegram execution API) 230 (transfer execution API), the following items are included in the items of [HTTP (response)].
(1) Success code (2) Processing result information, etc. Other items in the transfer API (telegram execution) 230 (transfer execution API) are the same as those shown in FIG. 19, so description thereof will be omitted. ..

Next, the arrows b1 to b5 in FIG. 20 will be described below.
The arrow "b1" reads the "transfer source account information" in the "[HTTP (request)]" of the transfer API (message conversion) 220 (transfer instruction API) on the charge support server 100, and reads the "transfer source account information" of the linked data DB 200. Access "User Account Information".

The arrow "b2" reads the "transfer amount" in "[HTTP (request)]" of the transfer API (telegram conversion) 220 (transfer instruction API) on the charge support server 100, and the second telegram 240 (charge response). Set to "Charge amount" in "[Individual business information]".
The arrow "b3" reads the "success code" in "[HTTP (response)]" of the transfer API (telegram conversion) 220 (transfer instruction API) on the charge support server 100, and reads the second telegram 240 (charge response). ) "[Communication control header]".

The arrow "b4" reads the "electronic money number" from the associated data DB 200 on the charge support server 100 and sets it in the "[business individual information]" of the second telegram 240 (charge response).
The arrow "b5" reads the "charge linking key" from the linking data DB 200 in the charge support server 100, and sets it in "[business individual information]" of the second telegram 240 (charge response).

(Fifth Embodiment shown in FIGS. 21 and 22)
21 and 22 are for explaining the fifth embodiment of the present invention.
The fifth embodiment is characterized in that, as shown in FIGS. 21 and 22, one general-purpose third telegram 250 is used for the "telegram".

In the description of the fifth embodiment, the first embodiment described above with reference to FIGS. 1 to 15 and the second embodiment described with reference to FIG. 16 and FIG. 17 The second embodiment described with reference to the second embodiment, the second and third embodiments described with reference to FIG. 18, and the fourth embodiment described with reference to FIGS. 19 and 20. The same components as those in the form are designated by the same reference numerals, and the description thereof will be omitted.

(Explanation of items in FIG. 21)
The "items" in FIG. 21 will be described below.
Since the items of the association data DB 200 (association database) are the same as those shown in FIG. 19, the description thereof will be omitted.
The items of the third telegram 250 (API request) are as follows.
(1) [HTTP header]
・ Corporate access token

(2) [HTTP (request)]
・ Terminal information, charge method
・ Electronic money number
・ Charge amount
・ Charge source information
・ (Charge linking key, etc.)
(3) [HTTP (Response)]

Since the items of the transfer API (telegram conversion) 260 (transfer instruction API) are the same as the transfer API (telegram conversion) 220 (transfer instruction API) shown in FIG. 19, the description thereof will be omitted.
Since the items of the transfer API (telegram execution) 270 (transfer execution API) are the same as the transfer API (telegram execution) 220 (transfer execution API) shown in FIG. 19, the description thereof will be omitted.

Next, the arrows c1 to c5 in FIG. 21 will be described below.
The arrow "c1" reads "(charge linking key, etc.)" in "[HTTP (request)]" of the third telegram 250 (API request) on the charge support server 100, and "charges" of the linking data DB 200. Access the "linking key".

The “arrow c2” reads the “electronic money number” in the “[HTTP (request)]” of the third telegram 250 (API request) on the charge support server 100, and converts it into the “electronic money number” of the associated data DB 200. to access.
The "arrow c3" reads the "charge amount" in "[HTTP (request)]" of the 3 message 250 (API request) on the charge support server 100, and reads the "charge amount" of the transfer API (message conversion) 260 (transfer instruction API). Set to "Transfer amount" in "[HTTP (request)]".

The "arrow c4" converts the "transfer source account information" obtained from the "user account information" of the linked data DB 200 on the charge support server 100 into the "[HTTP" of the transfer API (telegram conversion) 260 (transfer instruction API). (Request)]] and set it in "Transfer source account information".
“Arrow c5” indicates the “access token” obtained from the “user token” of the linked data DB 200 in the charge support server 100, and the “[HTTP header]” of the transfer API (message conversion) 260 (transfer instruction API). Set to.

(Explanation of items in FIG. 22)
The "items" in FIG. 22 will be described below.
Since the items of the association data DB 200 (association database) are the same as those shown in FIG. 19, the description thereof will be omitted.

Since the items of the third telegram 250 (API response) are the same as those of the third telegram 250 (API request) shown in FIG. 20, the description thereof will be omitted.
Since the items of the transfer API (telegram conversion) 260 (transfer instruction API) are the same as the transfer API (telegram conversion) 220 (transfer instruction API) shown in FIG. 20, the description thereof will be omitted.
Since the items of the transfer API (telegram execution) 270 (transfer execution API) are the same as the transfer API (telegram execution) 220 (transfer execution API) shown in FIG. 20, the description thereof will be omitted.

Next, the arrows d1 to d6 in FIG. 22 will be described below.
The arrow "d1" reads the "transfer source account information" in the "[HTTP (request)]" of the transfer API (message conversion) 220 (transfer instruction API) on the charge support server 100, and reads the "transfer source account information" of the linked data DB 200. Access "User Account Information".
The arrow "d2" reads the "transfer amount" in "[HTTP (request)]" of the transfer API (message conversion) 220 (transfer instruction API) on the charge support server 100, and reads the third message 250 (API response). Set to "Charge amount" in "[HTTP (request)]" of.

The arrow "d3" reads the "success code" in "[HTTP (respond)]" of the transfer API (telegram conversion) 220 (transfer instruction API) on the charge support server 100, and reads the third telegram 250 (API response). ) "[HTTP (Respond)]" in "Success Code".
The arrow "d4" reads "processing result information, etc." in "[HTTP (respond)]" of the transfer API (message conversion) 220 (transfer instruction API) on the charge support server 100, and reads the third message 250 (API). Set to "Processing result information, etc." in "[HTTP (Respond)]" of Response).

The arrow "b5" reads the "electronic money number" from the linked data DB 200 on the charge support server 100, and sets it as the "electronic money number" in the "[HTTP (request)]" of the third telegram 250 (API response). set.
The arrow "b6" reads the "charge linking key" from the linking data DB 200 on the charge support server 100, and "(charge linking)" in "[HTTP (request)]" of the third telegram 250 (API response). Set to "key, etc.)".

(First Embodiment)
10 Electronic money support system
20 Electronic money card 21 Communication terminal
22 Passbook 23 IC card
24 Electronic Money Department 25 Smartphone
26 Electronic money application (smartphone application)
27 prepaid card
30 Electronic money server
31 Electronic money support function system
32 Electronic money management function system
40 API platform
41 Transfer instruction API (payment application)
42 Transfer execution API (payment execution)
50 Banking system
51 Internal API 52 Core Banking System
53 User Deposit and Savings Account
54 Electronic Money Business Deposit and Saving Account
60 Electronic terminal
61 Electronic money operation function system
62 Electronic money payment function system
63 Electronic money communication device (electronic money reader)
64 Electronic Money Reader 65 POS Cash Register
70 to 74 screens 80 to 81 screens (second embodiment)
100 Charge support server 110 Device layer
111 POS terminal 1 112 POS terminal 2
113 Dedicated terminal 114 PC
115 smartphone
120 presentation layer
121 POS system 1 122 POS system 2
123 Dedicated application
124 Web application 1
125 Web application 2
130 Application Layer 131 POS Management System
140 API relay function layer 150 Leased line
151 Internet (third embodiment)
200 Account number linking DB
210 1st telegram (fixed length format)
220 Transfer API (Telegram conversion) <Transfer instruction API>
230 Transfer API (Telegram execution) <Transfer execution API>
240 Second telegram (fixed length format)
(Fourth Embodiment)
250 Third telegram (general-purpose format)
260 Transfer API (Telegram conversion) <Transfer instruction API>
270 Transfer API (Telegram execution) <Transfer execution API>

The invention according to one aspect of the present invention aims at the following points with respect to the "method of charging electronic money".
That is, the invention according to one aspect of the present invention uses an open API to immediately transfer money from a user's deposit / savings account to an electronic money business operator in response to an electronic money charge, thereby raising funds for the electronic money business operator. This is to speed up the process of payment to member stores.

An object of the invention according to one aspect of the present invention is the same as the above-mentioned invention according to one aspect of the present invention with respect to the "electronic money support system".

The invention according to one aspect of the present invention is characterized by the following points with respect to the "method of charging electronic money".
First, the electronic money charging method is premised on the following configuration.
(1) Electronic Money Server An electronic money server manages electronic money owned by a user.

Secondly, the method of charging electronic commerce includes the following steps.
(5) First step
The first step is the charge, subject to the reception of the message transmitted from the electronic money server based on the intention of the user and including at least the electronic money number unique to the electronic money and the charge amount. In the support server, the transfer API which is the open API is created by using the access token peculiar to the service, and the transfer API is transmitted to the API platform.

The invention according to one aspect of the present invention is characterized by the following points in addition to the above-mentioned feature points of the invention according to one aspect of the present invention with respect to the "method of charging electronic money".
First, the telegram includes the following configuration.
(1) First Telegram The first telegram includes at least the electronic money number unique to the electronic money and the charge amount.
(2) Second telegram The second telegram is a set of the data of the normal processing.
Secondly, in the first step , the first telegram, which is a fixed long telegram, is converted into the transfer API and then transmitted to the API board.
Third, in the fourth step , the transfer API is converted into the second telegram, which is the fixed long telegram, and transmitted to the electronic money server.

The invention according to one aspect of the present invention is characterized by the following points in addition to the above-mentioned feature points of the invention according to one aspect of the present invention with respect to the "method of charging electronic money".
First, the telegram is a general-purpose telegram.
Secondly, in the first step , the transfer API is created using the general-purpose telegram.
Third, in the fourth step , the "success code" is set in the general-purpose telegram and transmitted to the electronic money server.

The invention according to one aspect of the present invention is characterized by the following points in addition to the above-mentioned feature points of the invention according to one aspect of the present invention with respect to the "method of charging electronic money".
First, the charge support server includes a linking database that links the electronic money number and the deposit / savings account.
Secondly, in the first step , the deposit / savings account information related to the deposit / savings account is added to the transfer API based on the electronic money number included in the telegram using the linking database.

The invention according to one aspect of the present invention is characterized by the following points in addition to the above-mentioned feature points of the invention according to one aspect of the present invention with respect to the "method of charging electronic money".
First, the access token is stored in the association database.
Secondly, in the first step , the access token stored in the association database is read, and the transfer API is created using the read access token.

The invention according to one aspect of the present invention is characterized by the following points in addition to the above-mentioned feature points of the invention according to one aspect of the present invention with respect to the "method of charging electronic money".
First, the telegram includes the following configuration.
(1) First Telegram The first telegram includes at least the electronic money number unique to the electronic money and the charge amount.
(2) Second telegram The second telegram is a set of the data of the normal processing.
Secondly, the transfer API includes the following configuration.
(3) Transfer instruction API
The transfer instruction API is the open API.
(4) Transfer execution API
The transfer execution API is the open API.

Third, the first step includes the following steps.
(5) 10th step In the 10th step, on the condition that the first message is received, the transfer instruction API, which is the open API, is used in the charge support server by using the access token registered in advance by the user. It is created and the transfer instruction API is transmitted to the API base.
(6) Eleventh Step The eleventh step is to respond the settlement processing number to the charge support server on the condition that the transfer instruction API is received on the API platform.
(7) 12th step In the 12th step, the transfer execution API is created by using the payment processing number set in the response portion of the transfer instruction API on the charge support server, and the service-specific access prepared in advance is used. The transfer execution API is transmitted to the API base using the token.

The invention according to one aspect of the present invention is characterized by the following points with respect to the "electronic money support system".
First, the electronic money support system is premised on the following configuration.
(1) Electronic Money Server An electronic money server manages electronic money owned by a user.
(2) Charge Support Server The charge support server is capable of communicating with the electronic money server, and communicates using a telegram unique to the electronic money server.

Since the present invention is configured as described above, the present invention has the effects described below.
The invention according to one aspect of the present invention has the following effects with respect to the "method of charging electronic money".
That is, according to the invention according to one aspect of the present invention, in response to the charge of electronic money, the electronic money business operator can immediately transfer money from the user's deposit / savings account to the electronic money business operator by using the open API. It is possible to accelerate the monetization of funds and the payment to member stores.
In addition to this, according to the invention according to one aspect of the present invention, by adding the charge support server, it is possible to quickly process the telegram peculiar to the electronic money server.

The invention according to one aspect of the present invention has the same effect as the above-mentioned invention according to one aspect of the present invention with respect to the "electronic money support system".

Secondly, the method of charging electronic commerce includes the following steps, for example, as shown in FIG.
The same applies to the third embodiment shown in FIG. 17, for example.
(5) First step
The first step is, for example, as shown in FIG. 16, receiving a message 210,250 transmitted from the electronic money server 30 based on the intention of the user and including at least an electronic money number peculiar to electronic money and a charge amount. The charge support server 100 creates a transfer API that is an open API using the access token unique to the service, and transmits the transfer API to the API base 40 (for example, steps S210 to S212 in FIG. 16). reference).

Second, in the first step , for example, as shown in FIGS. 17 and 19, the first telegram 210, which is a fixed long telegram, is converted into transfer APIs 220 and 230 and then transmitted to the API substrate 40 (for example, in FIG. 17). See steps S221, S222, S224 shown).
Third, in the fourth step , for example, as shown in FIGS. 17 and 20, the transfer APIs 220 and 230 are converted into the second telegram 240, which is a fixed long telegram, and transmitted to the electronic money server 30 (for example,). See steps S227-S229 shown in FIG. 17).

Second, in the first step , for example, as shown in FIG. 21, transfer APIs 260 and 270 are created using a general-purpose telegram (third telegram 250) (see, for example, steps S221, S222, S224 shown in FIG. 17). ).
Third, in the fourth step , for example, as shown in FIG. 22, a "success code" is set in the general-purpose telegram (third telegram 250) and transmitted to the electronic money server 30 (for example, FIG. 17). See steps S228 and S229 shown in.
Here, "set" means "record".

Secondly, in the first step , for example, as shown in FIG. 19, the deposit / savings account information regarding the deposit / savings account is added to the transfer API 220 based on the electronic money number included in the telegram 210 using the linking database 200. (See, for example, steps S221 and 222 in FIG. 17).
The same applies to the fifth embodiment shown in FIG. 21, for example.

Secondly, in the first step , as shown in FIGS. 16 and 19, for example, the access token stored in the association database 200 is read, and the read access tokens are used to create transfer APIs 220 and 260 (for example,). See steps S211,212 shown in FIG. 16).
The same applies to the fifth embodiment shown in FIG. 21, for example.

Third, the first step includes the following steps, for example, as shown in FIG.
(5) 10th step As shown in FIG. 17, for example, the 10th step is an open API using the access token registered in advance by the user on the charge support server 100 on condition that the first telegram 210 is received. A transfer instruction API (see, for example, transfer API 220 (telegram conversion) in FIG. 19) is created, and the transfer instruction API is transmitted to the API base 40 (see, for example, steps S221 and 222 shown in FIG. 17).

Claims (7)

An electronic money server that manages electronic money owned by the user,
A charge support server that can communicate with the electronic money server and communicates using a telegram unique to the electronic money server.
An API platform that can communicate with the electronic money server and manages an open API that is open to the charge support server.
An accounting system that is connected to the API platform and can execute deposits and withdrawals to the deposit and savings account owned by the user, and transfers to the transfer destination account owned by the management entity that manages the electronic money server. On the premise of
Based on the intention of the user, the charge support server is service-specific on condition that the message is received from the electronic money server and includes at least the electronic money number unique to the electronic money and the charge amount. The first step of creating a transfer API, which is the open API, and transmitting the transfer API to the API platform, using the access token of
On condition that the transfer API is received, the transfer API is executed on the API platform, and the same amount as the charge amount determined by the user is deducted from the deposit / savings account by the accounting system.
At the same time, the second step of transferring the same amount as the charge amount to the transfer destination account by the accounting system, and
After the simultaneous execution of withdrawal and transfer, the third step of transmitting the "success code" to the charge support server on the API platform, and
On condition that the "success code" is received, the charge support server has a fourth step of transmitting the telegram to which the data of normal processing is added to the electronic money server.
The fifth step of adding the charge amount to the money balance of the electronic money owned by the user on the electronic money server on condition that the telegram is received.
A method of charging electronic commerce, which comprises. In the telegram
A first telegram including at least the electronic money number unique to the electronic money and the charge amount.
Including the second telegram in which the data of the normal processing is set,
In the first step,
After converting the first telegram, which is a fixed long telegram, into the transfer API, it is transmitted to the API board.
In the fourth step,
The transfer API is converted into the second telegram, which is the fixed long telegram, and transmitted to the electronic money server.
The method for charging electronic money according to claim 1. The telegram is a general-purpose telegram,
In the first step,
Create the transfer API using the general-purpose telegram,
In the fourth step,
The "success code" is set in the general-purpose telegram and transmitted to the electronic money server.
The method for charging electronic money according to claim 1. The charge support server has
It is equipped with a linking database that links the electronic money number and the deposit / savings account.
In the first step,
Using the linked database, the deposit / savings account information related to the deposit / savings account is added to the transfer API based on the electronic money number included in the telegram.
The method for charging electronic money according to claim 1. In the association database,
The access token is stored
In the first step,
Read the access token stored in the association database and read it.
Create the transfer API using the read access token.
The method for charging electronic money according to claim 4, wherein the electronic money is charged. In the telegram
A first telegram including at least the electronic money number unique to the electronic money and the charge amount.
Including the second telegram in which the data of the normal processing is set,
The transfer API includes
The transfer instruction API, which is the open API, and
Including the transfer execution API, which is the open API,
In the first step,
On condition that the first telegram is received, the charge support server creates the transfer instruction API, which is the open API, using the access token registered in advance by the user, and uses the transfer instruction API as the API base. 10th step to send to
In the API platform, on condition that the transfer instruction API is received, the eleventh step of responding to the charge support server with the payment processing number and
In the charge support server, the transfer execution API is created by using the payment processing number set in the response portion of the transfer instruction API, and the transfer execution API is used by using the service-specific access token prepared in advance. The 12th step to send to the API platform and
Including
The second step is
On the condition that the transfer execution API is received, the transfer execution API is executed on the API base.
The fourth step is
On condition that the "success code" is received, the charge support server transmits the second telegram to which the data of the normal processing is added to the electronic money server.
The fifth step is
On condition that the second telegram is received, the charge amount is added to the money balance of the electronic money owned by the user on the electronic money server.
The method for charging electronic money according to claim 1. An electronic money server that manages electronic money owned by the user,
A charge support server that can communicate with the electronic money server and communicates using a telegram unique to the electronic money server.
An API platform that can communicate with the electronic money server and manages an open API that is open to the charge support server.
An accounting system that is connected to the API platform and can execute deposits and withdrawals to the deposit and savings account owned by the user, and transfers to the transfer destination account owned by the management entity that manages the electronic money server. On the premise of
The charge support server is
Based on the intention of the user, the service-specific access token is used on condition that the message is received from the electronic money server and includes at least the electronic money number unique to the electronic money and the charge amount. A transfer API that is the open API is created, the transfer API is transmitted to the API platform, and the transfer API is transmitted.
The API base is
On condition that the transfer API is received, the transfer API is executed, and the same amount as the charge amount determined by the user is deducted from the deposit / savings account by the accounting system.
At the same time, the same amount as the charge amount is transferred to the transfer destination account by the accounting system.
The API base is
After the withdrawal and transfer are executed at the same time, the "success code" is sent to the charge support server.
The charge support server is
On condition that the "success code" is received, the telegram to which the data of normal processing is added is transmitted to the electronic money server.
The electronic money server requests that the charge amount be added to the money balance of the electronic money owned by the user on condition that the telegram is received.
An electronic money support system characterized by this.

Images