JP2018137005A - Settlement system, settlement method, and settlement program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To make it possible to provide means that is highly convenient by avoiding a foreign exchange spread as much as possible at a time of settlement between different currency types in offshore EC.SOLUTION: A settlement system provides means that is highly convenient by avoiding a foreign exchange spread as much as possible at a time of settlement between different currency types in offshore EC. According to a representative embodiment, the settlement system includes a settlement gateway that: detects a deposit by using a first currency type from a consumer to a predetermined deposit/withdrawal bank account; issues a first virtual currency of the first currency type equivalent to an amount of money relating to the deposit; changes the first virtual currency into a second virtual currency of a second currency type; and instructs a withdrawal equivalent to an amount of money in the second virtual currency from the deposit/withdrawal bank account to a bank account of a merchant.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a payment technology in electronic commerce (EC), and more particularly to a payment system, a payment method, and a payment program that support payment in so-called “cross-border EC” and a technology that is effective when applied to a payment program.

  With the spread and development of IT environments such as the Internet, businesses that sell products and services through electronic commerce provide products to overseas consumers to expand sales channels, etc. The market is expanding. In cross-border EC, consumers and stores (hereinafter sometimes referred to as “merchant”) conduct transactions across countries, so in the settlement, the merchant accepts payment and the consumer Sometimes the currency used is different. Generally, settlement by credit card, overseas remittance by a bank, etc. are used, and settlement is made by converting the currency by a credit card company or a bank.

  As a technology related to settlement at cross-border EC, for example, Japanese translations of PCT publication No. 2012-501013 (Patent Document 1) discloses an intermediary platform when a buyer purchases a product on an offshore retailer website using local currency. The technique used is described. Here, a buyer places an order on an offshore merchant website, which sends an order request to an intermediary platform. The intermediary platform calculates the purchase amount in local currency, exchanges the local currency amount provided by the user via the financial platform for an equivalent foreign currency amount, and also indicates successful payment to enable the shipment of goods Notify transaction messages to offshore retailer websites.

  Further, for example, Japanese Patent Laid-Open No. 2012-256200 (Patent Document 2) describes a technique for avoiding the risk of exchange fluctuation and reducing the fee for international settlement. Here, the first exchange rate applied to the exporter and the second exchange rate to which the broker's profit is added are input. In addition, it receives receipt data including the export destination currency price and the export destination account representing the price of the exported goods in the export destination currency, and stores the export destination account and the export destination currency price included in the receipt data in association with each other. Transfer the destination currency price from the destination account to the source account, calculate the first destination currency price based on the destination currency price and the first exchange rate, and based on the destination currency price and the second exchange rate The second export source currency price is obtained, the difference between the first export source currency price and the second export source currency price is obtained, the difference is stored in association with the broker account, and the first export source currency price is stored as the receiving account. Store it in association.

Special table 2012-501013 gazette JP 2012-256200 A

  When a settlement method such as credit card or bank remittance is used in cross-border EC, or when a settlement method as described in Patent Document 1 is used, a credit card is usually used for currency conversion. Unique exchange rates with spreads added by companies, banks and other intermediaries are used. As a result, it becomes higher than the exchange rate in the market, resulting in a heavy burden on the user and reduced convenience.

  In addition, when using the settlement method described in Patent Document 2, since the export source account and the export destination account are created in the same bank, there is no need to handle it as overseas remittance, while the account is stored in the same bank. There are restrictions such as having to create, which also results in reduced convenience and flexibility.

  Accordingly, an object of the present invention is to provide a settlement system and a settlement method capable of providing a convenient means by avoiding a currency exchange spread as much as possible at the time of settlement between different currency types in cross-border EC. It is to provide.

  The above and other objects and novel features of the present invention will be apparent from the description of this specification and the accompanying drawings.

  Of the inventions disclosed in this application, the outline of typical ones will be briefly described as follows.

  A payment system according to a representative embodiment of the present invention is a payment system that performs payment related to a transaction between users belonging to different currency areas, and detects payment by a first currency type for a predetermined account, It has a settlement gateway that issues a virtual currency equivalent to the amount related to the deposit, matches the opposite orders, and instructs the withdrawal by the second currency type of the equivalent value.

  Among the inventions disclosed in the present application, effects obtained by typical ones will be briefly described as follows.

  In other words, according to the representative embodiment of the present invention, it is possible to provide a convenient means by avoiding exchange spread as much as possible in settlement between different currency types in cross-border EC. It becomes.

It is the figure which showed the outline | summary about the structural example of the payment system which is one embodiment of this invention. It is the figure which showed the outline | summary about the example of the payment in cross-border EC of one embodiment of this invention. It is the figure which showed the outline | summary about the specific example of the payment in cross-border EC of one embodiment of this invention. It is the flowchart which showed the outline | summary about the example of the flow of the payment process in one embodiment of this invention. It is the sequence diagram shown about the example of the flow of the price determination process in the local currency in one embodiment of this invention. It is the flowchart shown about the example of the flow of the calculation process of the average acquisition rate in one embodiment of this invention. It is the sequence diagram shown about the example of the flow of the money_receiving | payment monitoring process and virtual currency issue process in one embodiment of this invention. It is the sequence diagram shown about the example of the flow of the exchange order instruction | indication process and redemption instruction | indication process in one embodiment of this invention. It is the sequence diagram shown about the example of the flow of a payment request process and the payment process in one embodiment of this invention. It is the figure which showed the outline | summary about the example of the settlement in the conventional cross-border EC. It is the figure which showed the outline | summary about the specific example of the payment in the conventional cross-border EC.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. Note that components having the same function are denoted by the same reference symbols throughout the drawings for describing the embodiment, and the repetitive description thereof will be omitted. In the following, in order to make the features of the present invention easier to understand, the description will be made in comparison with the prior art.

  FIG. 10 is a diagram showing an outline of an example of settlement in the conventional cross-border EC. The left side of the figure shows Japanese consumers and merchants, and the right side shows US merchants and consumers. Purchase transactions between consumers and merchants in Japan and between consumers and merchants in the United States are not cross-border EC, and, of course, settlement is performed in the currency of each country. That is, Japanese consumers pay in Japanese yen (shown as “¥” in the figure), and Japanese merchants receive in Japanese yen as they are. US consumers pay in US dollars (shown as “$” in the figure), and US merchants receive US dollars as they are.

  On the other hand, in the case of cross-border EC where a Japanese consumer purchases a product etc. via a US merchant website, for example, if a payment is made with a credit card, the Japanese consumer will pay in Japanese yen. For US merchants, you are paid in US dollars. At this time, the amount paid by Japanese consumers is the amount converted from US dollars at a unique exchange rate used by a credit card company or the like. Usually, a spread is added to the exchange rate by a credit card company or the like, which is higher than the exchange rate in the market. The same applies when a consumer in the United States purchases merchandise from a Japanese merchant.

  FIG. 11 is a diagram showing an outline of a specific example of settlement in the conventional cross-border EC. Here, an example of a specific settlement situation in the cross-border EC between Japan and the United States in the example of FIG. 10 is shown. For example, in the top chart, Japanese consumers “Mr. a”, “Mr. b”, and “Mr. c” are sold at US merchants “Shop A”, “Shop B”, and “Shop C”, respectively. In this case, a product of $ 9, $ 5, and $ 2 is purchased. If the exchange rate in the market is 1 $ = ¥ 100, the payment amount in Japanese yen should be ¥ 900, ¥ 500, ¥ 200, respectively. In the example in the figure, the spread of ¥ 4 is The exchange rate (1 $ = ¥ 104) is applied, and Japanese consumer payments are ¥ 936, ¥ 520 and ¥ 208, respectively, which are expensive.

  Similarly, in the lower chart, US consumers “Mr. d”, “Mr. e” and “Mr. f” are sold at Japanese merchants “Store D”, “Store E”, and “Store F”, respectively. In this case, the products of ¥ 100, ¥ 500, and ¥ 300 are purchased. In this case, payment amounts in US dollars should be $ 1, $ 5, and $ 3, respectively. In the example in the figure, an exchange rate ($ 1.04 $) with a spread of $ 0.04 is placed. = ¥ 100) is applied, and US consumer payments are $ 1.04, $ 5.2, and $ 3.1, respectively, and are expensive.

  In order to avoid the influence of such exchange spreads on settlement at cross-border EC as much as possible, in the settlement system according to an embodiment of the present invention, payment from the consumer is made between the consumer and the overseas merchant. And set up a gateway for payment to make payments to the merchant. Then, instead of making a direct exchange exchange for each transaction and making a settlement, it is converted into virtual currency once in the gateway, exchange orders between currency types in virtual currency are managed as board information, and opposing orders are matched. As a result, an exchange rate with no spread can be used, and the consumer only has to pay the amount determined by the exchange rate, thereby reducing the cost burden when purchasing the product.

  FIG. 2 is a diagram showing an outline of an example of settlement in the cross-border EC according to the present embodiment. In the case similar to the conventional example of FIG. 10, in the present embodiment, in the case of cross-border EC, for example, exchange (Japanese yen → US dollar) related to payment to a US merchant by a Japanese consumer, Currency exchange (US dollar → Japanese yen) related to payment to a Japanese merchant by a consumer in the middle using the virtual currency in the intermediate EC settlement gateway 10. This allows Japanese consumers to apply Japanese yen payments to Japanese merchants, and US consumers to pay US dollars to US merchants. This makes it possible to eliminate the effects of exchange spreads without actually changing the currency using foreign exchange.

  FIG. 3 is a diagram showing an outline of a specific example of settlement in the cross-border EC of the present embodiment. In the case similar to the conventional example of FIG. 11, for example, if Japanese consumer “Mr. a” in the upper diagram purchases a product of $ 9 from US merchant “Shop A”, the exchange spread is added. You won't be charged ¥ 900. Here, for convenience of explanation, the exchange rate spread is set to zero. However, depending on the result of the exchange matching, a small amount of spread may actually be used. The payment of ¥ 900 is for US consumers “Mr. d”, “Mr. e”, and “Mr. f” at “Store D”, “Store E”, and “Store F” of Japanese merchants in the lower chart. Since the total sales amount is ¥ 100 + ¥ 500 + ¥ 300 = ¥ 900, the EC settlement gateway 10 makes a target of matching and is used for payment to these merchants.

  Similarly, US consumers “Mr. d”, “Mr. e”, and “Mr. f” in the lower chart are ¥ 100 from Japanese merchants “Store D”, “Store E”, and “Store F”, respectively. , ¥ 500, ¥ 300 are purchased, $ 1, $ 5, and $ 3 will not be added to the exchange rate spread. The total payment of $ 9 is $ 9 for the US merchant “Shop A” in the upper chart, and the sales amount to US consumer “a” is $ 9. Eligible for payment to the merchant.

  In the present embodiment, as in the example of FIG. 3, instead of matching settlement with exchange between currency types only one-to-one, as long as the total of the sales amount and the payment amount match, m: n It can be matched by number. A method for matching the opposite currency exchanges is not particularly limited, but a so-called “plate approach method” in a stock market or the like can be appropriately used.

<System configuration>
FIG. 1 is a diagram showing an outline of a configuration example of a payment system according to an embodiment of the present invention. The payment system 1 includes a cross-border EC environment and an EC payment gateway 10 that performs a payment process related to transactions in the cross-border EC. The cross-border EC environment may be a general one. For example, the consumer terminal 31 that is an information processing terminal used by the consumer 30 and is connected via the network 50 such as the Internet, It has a Web server 41 that implements an EC Web site for a merchant 40 with a different service area.

  Further, as an actual bank account used for settlement, in addition to an individual bank account 42 for each merchant 40 to receive payment, a bank account 20 for deposit / withdrawal for each currency type held by the EC settlement gateway 10 for settlement processing. Have. In the example of FIG. 1, as the deposit / withdrawal bank account 20, bank accounts (deposit / withdrawal bank accounts 20a to 20c) that accept deposits and withdrawals in Japanese yen, US dollars, and Chinese yuan are provided. These accounts may be individually set up in a bank or the like in each currency region.

  The EC settlement gateway 10 is a server system implemented by, for example, a server device or a virtual server built on a cloud computing environment, and includes an OS (Operating System), a DBMS (DataBase Management System), a Web server (not shown), and the like. A bank deposit / withdrawal management unit 11, a virtual currency exchange engine 12, a gateway (GW) account management unit 13, a merchant account management unit 14, a price converter 15, and a market maker 16 implemented as software that operates on middleware such as a program Etc. have each part. Further, it has a data store such as a merchant management master 17 implemented by a database or the like.

  The bank deposit / withdrawal management unit 11 has a function of performing deposit instructions such as deposit monitoring and transfer / remittance to the bank account 42 of each merchant 40 with respect to each deposit / withdrawal bank account 20. Specifically, processing is performed by issuing a command or the like via an interface such as online banking or net banking of the bank where the deposit / withdrawal bank account 20 is provided.

  The virtual currency exchange engine 12 has a function as a processing engine for realizing a virtual cryptocurrency that can be distributed and exchanged on a network. It may be implemented as an interface function for an external virtual currency exchange engine or virtual currency exchange service. As the virtual currency exchange engine 12, a known technique can be used as appropriate. In the present embodiment, as a currency exchange network for enterprises, a function group necessary for currency exchange is provided as OSS (Open Source Software) and is freely available Ripple (registered trademark) (https: // ripple may be described as using .com /).

  The GW account management unit 13 has a function of managing a GW account 13a that is an account of a virtual currency (equivalent to “IOU” in Ripple) for the EC settlement gateway 10 provided on the virtual currency exchange engine 12 such as Ripple. . The GW account management unit 13 issues a virtual currency of a predetermined currency type (Japanese yen (¥), US dollar ($), Chinese yuan (yuan) in the example of FIG. 1) to the GW account 13a. Further, when a deposit of virtual currency from a merchant account (described later) to the GW account 13a (equivalent to redemption of the IOU in Ripple) is detected, the bank deposit / withdrawal management unit 11 receives the target from the deposit / withdrawal bank account 20 A withdrawal instruction to the bank account 42 of the merchant 40 is output.

  The merchant account management unit 14 has a function of managing a merchant account that is a virtual currency account associated with each merchant 40. In the example of FIG. 1, one or more Japanese accounts 14a, US accounts 14b, and Chinese accounts 14c are provided as merchant accounts corresponding to merchants 40 in Japan, the United States, and China, respectively.

  Each merchant is set with a currency type of virtual currency that is permitted to be received. Normally, only the currency type distributed in the target country is permitted, but other currency types may be permitted, for example, when the Japanese merchant 40 permits receipt in Chinese yuan. Such setting information is registered in advance in the merchant management master 17 or the like. When there is a deposit of virtual currency by a type other than the currency type permitted to receive, the exchange order to the currency type permitted to receive is made to the market maker 16 described later, and the virtual currency as a result of the exchange is obtained. Deposit money.

  The price converter 15 converts the prices of products sold on the EC website provided by the web server 41 of the merchant 40 based on the information in the order book 16a held by the market maker 16 described later, into the local currency of the consumer It has a function to convert to a price and present it.

  The market maker 16 has a function of managing the information of the order book 16a held for each currency exchange combination between currency types and performing a currency exchange process. The order book 16a holds exchange order information issued from the merchant account management unit 14 as order board information. The market maker 16 performs matching as shown in FIG. 3 described above on the sell / buy exchange order in the order book 16a to establish the exchange order. A specific matching method is not particularly limited, and a matching function provided in the virtual currency exchange engine 12 such as Ripple may be used, or a matching process may be independently constructed. The market maker 16 also calculates and outputs an average acquisition rate for exchange based on the current board information in response to an instruction from the price converter 15 or the like.

  The merchant management master 17 is a table that holds master information about the merchant 40 that performs payment using the payment system 1 of the present embodiment. The merchant 40 described above manages information on the type of currency that the deposit is permitted, information on the bank account 42, and the like.

  In the example of FIG. 1, the EC settlement gateway 10 is configured as one server system, but the configuration can be changed flexibly as appropriate. For example, the bank deposit / withdrawal management unit 11, the GW account management unit 13, The merchant account management unit 14 and the like can be distributed in each country and configured as a gateway system for each country, and the price converter 15 and the market maker 16 can be provided in one place. .

  In this embodiment, the GW account management unit 13 and the merchant account management unit 14 are configured as software having a function of managing account information. However, the account information and the function of accessing the account information are provided. It can also be implemented as an integrated “account object”. Similarly, the market maker 16 can also be implemented as an “order book object” in which the information of the order book 16a and a function for accessing the information are accessed.

<Processing flow (overall)>
FIG. 4 is a flowchart showing an outline of an example of the flow of payment processing in the present embodiment. In the settlement process when the consumer 30 purchases goods from an overseas merchant 40 by cross-border EC, first, prior to the settlement, the EC website of the merchant 40 accesses the price converter 15 of the EC settlement gateway 10. Then, the payment price in the local currency of the consumer 30 for the sales price of the product or the like is acquired and presented to the consumer 30 (S01). At this time, the price converter 15 refers to the status of the order book 16a in the market maker 16 and converts the sales amount in the currency unit of the country to which the merchant 40 belongs to the payment amount in the currency unit of the country to which the consumer 30 belongs. Convert and output.

  When the payment amount is determined and the purchase contract for the product is concluded, the bank deposit / withdrawal management unit 11 of the EC settlement gateway 10 thereafter deposits the above payment amount from the consumer 30 to the deposit / withdrawal bank account 20. It is monitored whether or not (S02). The deposit / withdrawal bank account 20 to which the consumer 30 deposits is designated by the EC settlement gateway 10 according to the currency type. For example, in the example of FIG. 1, in the case of payment in Japanese yen, the bank account for deposit / withdrawal 20a that accepts deposit / withdrawal in Japanese yen is designated. The bank deposit / withdrawal management unit 11 periodically checks whether or not each deposit / withdrawal bank account 20 has been deposited. When there is a new deposit, the GW account management unit 13 is notified of the currency type and amount, and information relating to the payee merchant 40.

  Note that the information related to the merchant 40 of the payee includes, for example, information such as an ID for identifying the merchant 40 in the transfer information that is input when the consumer 30 deposits money into the deposit / withdrawal bank account 20, This can be grasped by inputting the order number of the transaction. For example, when information such as an ID for specifying the merchant 40 is designated, the merchant 40 can be specified by referring to the merchant management master 17 in the EC settlement gateway 10. When the order number is determined, for example, when a purchase contract is concluded in the merchant 40, the Web server 41 sends the order number and the information of the merchant 40 to the EC settlement gateway 10 via the network 50 in advance. By transmitting, the merchant 40 can be specified.

  When the payment from the consumer 30 can be grasped, the GW account management unit 13 that has received the notification, corresponds to the currency type and the deposit amount related to the deposit (that is, equivalent currency) (IOU in Ripple) Further, the issued virtual currency is transferred to the merchant account associated with the target merchant 40 (S03).

  The merchant account management unit 14 monitors the payment to each merchant account, and when it detects that the target merchant account has received virtual currency, the merchant 40 allows the merchant 40 to accept the currency type. If it does not match the currency type to be exchanged, an exchange order for exchanging the currency type of the received virtual currency to the currency type permitted by the merchant 40 is issued to the market maker 16 (S04). For example, in order to exchange ¥ 1,000 for $ 10, an exchange order of “Sell: ¥ 1,000 / Buy: $ 10” is made. Note that the information on the currency type that each merchant 40 permits is registered in advance in the merchant management master 17 or the like as described above.

  On the other hand, if the currency type of the virtual currency deposited in the merchant account matches the currency type that the merchant 40 accepts, or the currency type of the currency that the exchange order is executed and allowed to accept Is transferred to the merchant account, the merchant account management unit 14 remits the entire amount of the virtual currency deposited in the target merchant account to the GW account 13a (in the case of Ripple, redemption of the IOU) (S05).

  The GW account management unit 13 monitors the receipt of the virtual currency to the GW account 13a, and when detecting the receipt of the virtual currency from the merchant account, the GW account management unit 13 corresponds to the currency type and the deposit amount (ie, equivalent value). The actual currency amount and information of the bank account 42 of the merchant 40 corresponding to the merchant account of the deposit source are transmitted to the bank deposit / withdrawal management unit 11 to request withdrawal (S06). Information on the bank account 42 of the target merchant 40 is registered in advance in the merchant management master 17 or the like as described above.

  Based on the currency type and amount received from the GW account management unit 13 and the information of the bank account 42, the bank deposit / withdrawal management unit 11 handles the target currency type bank account 20 (in the example of FIG. From the deposit / withdrawal bank account 20b) which accepts deposit / withdrawal in dollars, the actual withdrawal process such as transfer or remittance is performed on the bank account 42 of the target merchant 40 (S07). The above-described series of processing completes settlement at the cross-border EC.

<Processing flow (price determination in local currency)>
FIG. 5 is a sequence diagram showing an example of the flow of the price determination process in the local currency in step S01 of FIG. The price converter 15 of the EC settlement gateway 10 that has received the payment price acquisition request in the local currency first instructs the market maker 16 to calculate the average acquisition rate based on the order board information. In response to the instruction, the market maker 16 first issues a command or the like to the virtual currency exchange engine 12 to obtain the exchange order board information between the target currency types, that is, the information in the order book 16a. Then, based on the information in the order book 16a, an average acquisition rate is calculated by a method to be described later and responds to the price converter 15. The price converter 15 calculates the payment amount in the local currency of the consumer 30 based on the average acquisition rate and the sales amount of the product.

  FIG. 6 is a flowchart showing an example of the flow of the average acquisition rate calculation process in the example of FIG. First, a loop process for repeating the process for the exchange order list is started (S11). In the loop process, first, as a preparatory process for updating the exchanged amount based on the target exchange order, the price after the exchange related to the target exchange order (hereinafter referred to as “α”) is calculated, The exchanged amount “A + α” is calculated by adding “α” to the total of the exchanged amounts so far (hereinafter referred to as “A”). It is assumed that the exchange order information includes information on the exchange rate and the exchange target amount, for example, “Exchange at $ 1 = ¥ 100 for ¥ 5,000 for exchange”.

  Next, it is determined whether or not the exchanged amount “A + α” is equal to or greater than the sales amount in the currency of the selling country (S13). If “A + α” is less than the sales amount, the exchanged amount so far is updated (S14). That is, “A + α” is set as a new “A”, and the process proceeds to the next exchange order (S15, S11).

  On the other hand, if “A + α” is equal to or greater than the sales amount in step S13, the average acquisition rate is adjusted so that the exchanged amount “A + α” is equal to the sales amount (S16). For example, when the amount of “A” before adding “α” is less than the sales amount, the average acquisition rate is calculated by the following formula.

Average acquisition rate = Average acquisition rate +
Exchange rate in target exchange order x (sales amount-A) / A
Thereafter, the loop process is terminated, the average acquisition rate calculated in step S16 is returned (S17), and the process is terminated. Through the above series of processing, the average exchange rate in the virtual currency between the target currency types can be acquired based on the exchange order board information in the order book 16a.

<Processing flow (payment monitoring, virtual currency issuance)>
FIG. 7 is a sequence diagram showing an example of the flow of the deposit monitoring process in step S02 and the virtual currency issuing process in step S03 in FIG. First, the consumer 30 makes an actual deposit to the deposit / withdrawal bank account 20 designated by the EC settlement gateway 10. The bank deposit / withdrawal management unit 11 periodically detects whether or not there is a deposit to the account, thereby detecting the deposit and, if necessary, notifying the consumer 30 that the deposit has been confirmed. For example, payment confirmation can be notified by sending an e-mail to the consumer 30.

  The bank deposit / withdrawal management unit 11 that has detected the deposit instructs the GW account management unit 13 to issue a virtual currency (i.e., equal value) corresponding to the deposited currency type and amount (ie, IOU in Ripple). . Upon receiving the issue instruction, the GW account management unit 13 creates a transaction including a command for issuing and transferring virtual currency, and executes the transaction for the virtual currency exchange engine 12. Thus, the virtual currency is issued by the virtual currency exchange engine 12 and the issued virtual currency is transferred to the merchant account associated with the target merchant 40.

<Processing flow (exchange order instruction, redemption instruction)>
FIG. 8 is a sequence diagram showing an example of the flow of the exchange order instruction process in step S04 and the redemption instruction process in step S05 of FIG. First, the merchant account management unit 14 periodically checks with the virtual currency exchange engine 12 whether there is a virtual currency deposit transaction for the merchant account associated with each merchant 40. If it is detected by the response from the virtual currency exchange engine 12 that payment has been made, the currency type is then determined. Specifically, currency type information related to payment is acquired from the content of the response from the virtual currency exchange engine 12. Further, with reference to the merchant management master 17, information on the type of currency that the target merchant account (or the merchant 40 associated therewith) is permitted to receive is acquired. Then, it is determined whether or not these currency types match.

  If the currency types do not match, the processing of the exchange instruction for exchanging to the currency type permitted to be received is performed. Specifically, first, the merchant account management unit 14 creates a transaction including a command or the like for exchanging virtual currency, and transmits an exchange instruction including this transaction message to the market maker 16. The market maker 16 transmits the received transaction message to the virtual currency exchange engine 12, so that the virtual currency exchange engine 12 executes a transaction for exchange to exchange virtual currency between currency types.

  On the other hand, if the deposited currency type matches the currency type that the target merchant 40 permits to receive, the processing of a reimbursement instruction is performed to remit the received virtual currency to the GW account 13a. Specifically, first, the merchant account management unit 14 creates a transaction including a command for transferring the virtual currency to the GW account 13 a and executes the transaction for the virtual currency exchange engine 12. As a result, the virtual currency in the target merchant account is transferred by the virtual currency exchange engine 12 to the GW account 13a. Thereafter, the GW account management unit 13 requests the bank deposit / withdrawal management unit 11 to make a withdrawal request to the bank account 42 of the target merchant 40. Details of this process will be described later.

<Processing flow (withdrawal request, withdrawal process)>
FIG. 9 is a sequence diagram showing an example of the flow of the withdrawal request process in step S06 and the withdrawal process in step S07 in FIG. First, the GW account management unit 13 periodically checks with the virtual currency exchange engine 12 whether a virtual currency deposit transaction exists for the GW account 13a. If it is detected from the response from the virtual currency exchange engine 12 that there has been a deposit, then the contents of the withdrawal request are created. Specifically, from the content of the response from the virtual currency exchange engine 12, information on the currency type and amount related to payment, and information on the merchant account of the payment source are acquired. Then, the merchant management master 17 is referred to, information on the merchant 40 and the bank account 42 associated with the merchant account is obtained, and the real currency corresponding to the currency type and deposit amount of the virtual currency (ie, equivalent value) Information on the amount of money and information on the bank account 42 are created as the contents of the withdrawal request.

  Thereafter, the contents of the withdrawal request are transmitted to the bank deposit / withdrawal management unit 11 to request withdrawal. Based on the contents of the received withdrawal request, the bank deposit / withdrawal management unit 11 provides an actual remittance from the deposit / withdrawal bank account 20 that handles the target currency type to the target bank account 42 by a bank or the like. Direct to service and money transfer service. The transfer service provided by the bank or the like performs actual remittance from the deposit / withdrawal bank account 20 to the bank account 42 of the target merchant 40 in accordance with the instructed contents. With the above series of processing, settlement processing at the cross-border EC can be performed.

  As described above, according to the settlement system 1 according to an embodiment of the present invention, the EC settlement gateway 10 is provided between the consumer 30 and the overseas merchant 40, and direct exchange is performed for each transaction. In the EC settlement gateway 10, the payment is converted into virtual currency, the exchange order between currency types in the virtual currency is managed as board information in the order book 16a, and opposing orders are matched. This allows the exchange rate of the market in the virtual currency exchange network to be used, and the consumer only has to pay the amount determined by the exchange rate, avoiding the effects of spread, and paying the cost of purchasing the product. Can be reduced.

  As mentioned above, the invention made by the present inventor has been specifically described based on the embodiments. However, the present invention is not limited to the above-described embodiments, and various modifications can be made without departing from the scope of the invention. Needless to say. For example, the above-described embodiment has been described in detail for easy understanding of the present invention, and is not necessarily limited to the one having all the configurations described. In addition, it is possible to add, delete, and replace other configurations for a part of the configuration of the above-described embodiment.

  The present invention can be used in a payment system and a payment method that support payment in cross-border EC.

1 ... Payment system
DESCRIPTION OF SYMBOLS 10 ... EC payment gateway, 11 ... Bank deposit / withdrawal management part, 12 ... Virtual currency exchange engine, 13 ... GW account management part, 13a ... GW account, 14 ... Merchant account management part, 14a ... Japanese account, 14b ... US account, 14c ... China account, 15 ... Price converter, 16 ... Market maker, 16a ... Order book, 17 ... Merchant management master,
20, 20a-20c ... bank account for deposit and withdrawal,
30 ... Consumer, 31 ... Consumer terminal,
40 ... Merchant, 41 ... Web server, 42 ... Bank account,
50 ... Network

Claims (3)

A payment system for performing payments related to transactions between users belonging to different currency areas,
Detects deposits in a first currency type for a given account, issues a virtual currency equivalent to the deposit amount, matches the opposite order, and withdraws in a second equivalent currency type A payment system having a payment gateway for instructing. A payment method in a payment system for performing payment related to transactions between users belonging to different currency areas,
A first step in which the payment system detects a deposit in a first currency type for a predetermined account;
A second step in which the settlement system issues a virtual currency equivalent in value to the deposit;
A third step in which the payment system directs withdrawal with an equivalent second currency type after matching opposing orders;
A payment method. A payment program for causing a computer to execute processing so as to function as a payment system for performing payment related to transactions between users belonging to different currency areas,
A first process for detecting a deposit in a first currency type for a predetermined account;
A second process for issuing a virtual currency equivalent to the amount related to the deposit;
A third process for instructing withdrawal with an equivalent second currency type after matching opposing orders;
A payment program for causing the computer to execute.

Images