Payment server, balance management method, and program

Abstract

Clearly manage the monetary information for events where there is a time lag between the time of setup and when it is granted to a specific user, as a prepaid payment method. [Solution] A payment server that cooperates with a payment application running on a user's terminal device and provides an electronic payment service using a fund source including a charge balance charged by the user, comprising: an acquisition unit that acquires setting information for a gift code provided by a merchant and converted into a non-withdrawable charge balance by the user's actions; and a balance management unit that, at the time the setting information is acquired, adds the value indicated by the setting information to a balance limit that is counted as part of a prepaid payment means in a balance management system.

Description

Technical Field

[0001] The present invention relates to a settlement server, a balance management method, and a program.

Background Art

[0002] Conventionally, in order to allow a target person who can be a recipient of an electronic gift card available in an electronic payment service to use it, information on content and information on a gift card before activation are managed in association with each other. When the usage mode of the content by the target person satisfies the acquisition conditions of the gift card whose usage mode is preset, the gift card is activated to a usable state, and an invention of a system for giving a privilege corresponding to the amount associated with the activated gift card to the target person is disclosed (Patent Document 1).

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In the conventional technology, regarding an event with a time lag from the setting time until it is given to a specific user, the management method as a prepayment payment means was ambiguous.

[0005] The present invention has been made in consideration of such circumstances, and one of the objectives is to provide a settlement server, a balance management method, and a program capable of clearly managing the amount information of an event with a time lag from the setting time until it is given to a specific user as a prepayment payment means.

Means for Solving the Problems

[0006] One aspect of the present invention is a payment server that cooperates with a payment application operating on a user's terminal device and provides an electronic payment service using a fund source including a charge balance charged by the user, comprising: an acquisition unit that acquires setting information for a gift code provided by a merchant and converted into points usable as the charge balance by the user's actions; and a balance management unit that, at the time the setting information is acquired, adds the value indicated by the setting information to a balance limit that is counted as part of a prepaid payment means in a balance management system. [Effects of the Invention]

[0007] According to one aspect of the present invention, monetary information for events that have a time lag between the time of setting and the time they are assigned to a specific user can be clearly managed as a prepaid payment method. [Brief explanation of the drawing]

[0008] [Figure 1] This diagram shows the basic forms of in-store electronic payment. [Figure 2] This diagram shows an example of a configuration for performing electronic payments (terminal payments) using a payment app. [Figure 3] This figure shows an example of the contents of user information 172. [Figure 4] This diagram shows an example of the contents of merchant / store information 174. [Figure 5] This diagram shows an overview of the processing flow when a user scan is performed. [Figure 6] This diagram shows an overview of the processing flow when a store scan is performed. [Figure 7] This diagram shows an example of a configuration for performing electronic payments (card payments) using payment cards. [Figure 8] This figure shows an overview of the balance management system operated by the balance management system information 176 and the balance management unit 150. [Figure 9] This is a diagram to explain how gift codes work. [Figure 10] This figure shows an example of the processing flow for gift codes executed by the payment server 100. [Figure 11] This figure shows an example of a screen that can be displayed based on the information output by the output unit 160. [Modes for carrying out the invention]

[0009] [overview] The following describes embodiments of the payment server, balance management method, and program according to the present invention with reference to the drawings. The payment application, payment server, and credit card server work together to provide an electronic payment service. The electronic payment service is a service that supports payment for the purchase of goods and services at a store. A store is, for example, a physical store (real store) that exists in the real world, but may also include a virtual store for e-commerce. A virtual store may include one provided by an entity different from the operator of the electronic payment service. In that case, when settling a purchase at a virtual store, the system is controlled to transition to the interface screen of the electronic payment service. In the electronic payment service, a store is treated as belonging to, for example, a merchant (brand), and electronic payment when a purchase is made at a store is mainly made between the user and the merchant. Alternatively, electronic payment may be made between the user and the store. First, the overall picture of the electronic payment service will be described, and then the characteristic balance management method of the present invention will be described.

[0010] [Types of in-store electronic payment methods] Figure 1 shows a basic configuration of in-store electronic payment. Basically, electronic payment is executed by three parties: a medium M held by the user U, store equipment E, and a payment system S. The medium M is a portable computer device such as a smartphone or a credit card. Store equipment E is located in a physical store (hereinafter simply referred to as "store") in the real world and includes POS devices, wireless communication devices, credit card readers, printed materials with code images such as QR codes (registered trademarks), or display devices that show code images. In in-store electronic payment, first, user identification information and payment amount information are shared unidirectionally or bidirectionally between the medium M and the store equipment E. During this process, one of the medium M or store equipment E optically reads various information from the code image displayed by the other, provides information via NFC (Near Field Communication), or reads the PAN (Primary Account Number) by a credit card reader. Then, one of the medium M or store equipment E (the one that received information from the other) transmits the payment information necessary for payment to the payment system S via the network NW. Furthermore, both the medium M and the store equipment E may transmit some information to the payment system S. The payment system S manages various information of the user U and performs electronic payments between the store and the user U in various ways. Electronic payments are made using either a prepaid system or a post-paid system, or both, or by other methods. In addition, electronic payments may also include forms of so-called online shopping, which are performed by both the user's terminal device and the payment system. The network NW includes, for example, the internet, LAN (Local Area Network), wireless base stations, and provider equipment. Various devices that communicate via the network NW, as described later, are assumed to have communication devices such as network cards and wireless communication modules.

[0011] [Configuration (Terminal Payment)] Figure 2 shows an example of a configuration for electronic payment (terminal payment) using a payment application. This electronic payment is executed around a payment application 20 running on a user terminal device 10, which is one of the media Ms; one or more store payment terminals 30 and one or more store code images 40, which are part of the store equipment E; and a payment server 100 that constitutes part of the payment system S. The payment server 100 communicates with the user terminal device 10, the store payment terminals 30, and one or more information terminals 50 via a network NW.

[0012] The user terminal device 10 is, for example, a portable terminal device such as a smartphone or tablet. The user terminal device 10 is a computer device having at least optical reading function, communication function, display function, input acceptance function, and program execution function. In the following description, the components for realizing these functions will be referred to as a camera, communication device, touch panel, CPU (Central Processing Unit), etc. In the user terminal device 10, the payment application 20 is executed by a processor such as the CPU, and it operates in cooperation with the payment server 100 to provide electronic payment services to users. The payment application 20 is installed in the user terminal device 10 from, for example, an application distribution server (not shown), and controls the camera, communication device, touch panel, etc. of the user terminal device 10. In the following description, there may be instances where it is written as "sending information to the user terminal device 10 (or receiving / acquiring information from the user terminal device 10)" and instances where it is written as "sending information to the payment application 20 (or receiving / acquiring information from the payment application 20)," but these are merely differences in expression and do not distinguish anything.

[0013] The store payment terminal 30 is installed, for example, in a store. The store payment terminal 30 is a computer device (or a collection thereof) having at least a product price acquisition function, an optical reading function, a program execution function, and a communication function. The store payment terminal 30 includes a so-called POS (Point of Sale) device, and the POS device may have a product price acquisition function and an optical reading function.

[0014] The store code image 40 is placed in the store and is a code image such as a QR code (registered trademark) printed on a paper or plastic medium. Note that the store code image 40 may be displayed by a display placed in the store (which may be a display of a terminal device such as a smartphone or a tablet terminal).

[0015] The information terminal 50 is used by the operator of the franchise that manages the store. In the electronic payment service, a customer as a provider of goods or services is treated as a franchise (brand), and there is one or more stores under its umbrella. There may be a franchise that operates only one store. The information terminal 50 is a smartphone, a tablet terminal, a personal computer, etc. The information terminal 50 operates a franchise interface 55. The franchise interface 55 may be a franchise application or a web page displayed by a general-purpose browser. The franchise interface 55 accepts settings of coupons, etc. by the operator of the franchise and transmits them to the payment server 100. The information terminal 50 may have a function of displaying a code image corresponding to the store code image 40 or reading the code image displayed by the user terminal device 10 by executing the franchise interface 55 (in the latter case, an optical reading function is required).

[0016] The payment server 100 communicates with the credit card server 200 via the network NW. The payment server 100 has, for example, a content providing unit 110, an information management unit 120, a payment processing unit 130, an acquisition unit 140, a balance management unit 150, an output unit 160, and a storage unit 170. Components other than the storage unit 170 are realized, for example, by a hardware processor such as a CPU executing a program (software). Some or all of these components are LSI (Large Scale Integration), ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable It may be implemented by hardware (including circuitry), such as a gate array or a GPU (Graphics Processing Unit), or by the cooperation of software and hardware. The program may be stored in advance in a storage device (a storage device equipped with a non-transitory storage medium), such as an HDD (Hard Disk Drive) or a flash memory, or stored in a removable storage medium (a non-transitory storage medium), such as a DVD or a CD-ROM, and installed in the storage device by mounting the storage medium on a drive device. The acquisition unit 140, the balance management unit 150, and the output unit 160 may be configured as a balance management device separate from the settlement server 100, but here it is assumed to be a part of the settlement server 100.

[0017] The storage unit 170 is, for example, an HDD, a flash memory, a RAM (Random Access Memory), etc. The storage unit 170 may be a NAS (Network Attached Storage) device accessible by the settlement server 100 via a network. Information such as user information 172, franchise / store information 174, and balance management system information 176 is stored in the storage unit 170.

[0018] The content providing unit 110 has, for example, the function of a web server and provides information (content) for displaying various screens of the electronic payment service to the user terminal device 10. The content providing unit 110 provides content to the user terminal device 10 in the form of a web page or provides parameters necessary for the payment application 20 to render an image to the user terminal device 10.

[0019] The information management unit 120 edits, adds, deletes, etc. the user information 172 and the franchise / store information 174 and manages them. [[ID=I4]]

[0020] Figure 3 shows an example of the contents of User Information 172. User Information 172 is a collection of information such as User URL, Account ID, Phone Number, Password, Registration Date, Charge Balance, Points, Electronic Money Type, Terminal Payment Method, Card Payment Method, Various History Information, Identity Verification Flag, Name, Address, Date of Birth, Email Address, Bank Account, Postpay Settings, and Postpay Conditions Information, all of which are linked to each other. Hereafter, the instance of a user (electronic payment account) to which this information is linked may be referred to as an account. In the figure, items indicated by "-" indicate that they are not set.

[0021] The user URL is used for processing transfers between users. When registering for a new electronic payment service, registration of a phone number and password is required. The account ID is issued to the user by the payment server 100. The registration date is the date the user registered for the electronic payment service (the date the account was created). The charge balance is information indicating the balance of electronic money set by the user sending money to their account in advance. Transfer methods include depositing money into an ATM (Automatic Teller Machine) of a designated company (bank) and transferring money from a registered bank account. Points are the usable value of the charge balance. The type of electronic money indicates, for example, whether the electronic money can be withdrawn or can only be used for electronic payments. More detailed information on balance management will be described later. The terminal payment method is setting information indicating whether the user will make an electronic payment using the charge balance (balance payment) or a deferred payment in terminal payments. The card payment method is setting information indicating whether the user will make an electronic payment using the charge balance (balance payment) or a deferred payment in card payments. Various types of transaction history information include charge history, which shows the history of users sending money to electronic payment services in advance to increase their balance, and payment history, which shows the details of each transaction made by the user (date and time, store ID of the store where the purchase was made, merchant ID, payment amount, payment method, etc.).

[0022] The "Verified" flag indicates whether the user has completed identity verification using an identification document. Post-payment becomes available only after identity verification is complete. In the diagram, the user with account ID "002" has not completed identity verification and therefore can only select balance payment as their terminal payment method. The bank account is the account number of a bank account into which funds can be deposited for the electronic payment service. The "Post-payment Settings" indicates whether the user has completed the necessary setup to enable post-payment. The "Post-payment Conditions" information shows various conditions for post-payment, such as the limit and the current month's usage amount.

[0023] Figure 4 shows an example of the contents of the merchant / store information 174. The merchant / store information 174 includes, for example, a first table 174A in which the merchant ID and store ID are associated with the store URL, a second table 174B in which the merchant name and sales amount (as described above) are associated with the merchant ID, and a third table 174C in which the store name is associated with the store ID. In addition to this information, the merchant / store information 174 may also include information such as the merchant or store category, the store's location, and payment patterns.

[0024] The payment processing unit 130 performs various processes for electronic payment. There are two methods for terminal payment, which are described below: the first method (user scan) and the second method (store scan).

[0025] Figure 5 shows an overview of the processing flow when a user scan is performed. First, the user terminal device 10, with the payment application 20 running, reads and decodes the store code image 40 using its optical reading function (S1). The store code image 40 contains information about the store URL. The payment application 20 sends first payment information, including the store URL and the user's account ID, to the payment server 100 (S2). The payment server 100 searches for merchant / store information 174 using the merchant ID and store ID corresponding to the store URL, obtains the merchant name and store name information (S3), and sends it to the payment application 20 (S4). The user enters the payment amount into the payment application 20 on the screen where the merchant name and store name are displayed (S5). Then, the payment application 20 generates second payment information, including at least the payment amount, and sends it to the payment server 100 (S6).

[0026] The payment processing unit 130 of the payment server 100 performs electronic payment based on the received second payment information if the "terminal payment method" in the user information 172 of the user is set to "balance payment" (S7-1). At this time, the payment processing unit 130 performs electronic payment by, for example, decreasing the charge balance managed in association with the user ID and increasing the item value of the merchant's sales proceeds. The item value of the merchant's sales proceeds is not used as electronic money itself, for example, but rather the amount corresponding to the item value of the sales proceeds is transferred to the bank account in a cycle according to the agreement between the merchant and the electronic payment service. On the other hand, if the "terminal payment method" is set to "post-payment", the payment processing unit 130 sends the first payment information and the second payment information to the credit card server 200 to request electronic payment (S7-2). The credit card server 200 performs electronic payment by adding the payment amount to the user's monthly usage amount based on the received information and deducting the monthly usage amount from the user's bank account after the closing date (S7-3).

[0027] Then, the payment processing unit 130 sends a payment completion notification (information for displaying the payment completion screen) to the payment application 20 via the content provision unit 110 (S8), and the payment application 20 displays the payment completion screen (S9). If the store code image 40 is displayed on a display placed in the store, the store code image 40 may include payment amount information as well as the store URL. In this case, the procedure for the user to enter the payment amount is omitted, and the payment amount information is included in the first payment information and sent to the payment server 100. Merchant name and store name information may be included and displayed on the payment completion screen.

[0028] Figure 6 shows an overview of the processing flow when a store scan is performed. First, when the payment app 20 is launched, when a payment operation is performed in the payment app 20, when it is time for an automatic update (for example, every minute), and at other times, the payment app 20 sends a request to the payment server 100 to issue a one-time code (S11). The payment processing unit 130 of the payment server 100 generates a one-time code (S12) and sends it to the payment app 20 (S13). The payment app 20 displays a code image such as a QR code or barcode that was generated based on the one-time code (S14). The user holds the display surface of the user terminal device 10 over the store payment terminal 30, and the store payment terminal 30 reads and decodes the code image using its optical reading function and obtains the one-time code, etc. (S15). Then, the store payment terminal 30 generates payment information including the one-time code, payment amount, merchant ID, store ID, etc., and sends it to the payment server 100 (S16). Payment amount information is obtained in advance through methods such as barcode scanning or manual entry.

[0029] The payment processing unit 130 of the payment server 100 identifies the user corresponding to the one-time code based on the received information, and if the "terminal payment method" in the user information 172 of that user is set to "balance payment", it performs electronic payment based on the received second payment information (S17-1). The content of the processing at this time is the same as the processing in S7-1 in Figure 5. On the other hand, if the "terminal payment method" is set to "post-payment", the payment server 100 sends the first payment information and the second payment information to the credit card server 200 to request electronic payment (S17-2). The credit card server 200 adds the payment amount to the user's monthly usage amount based on the received information and performs electronic payment by deducting the monthly usage amount from the user's bank account after the closing date (S17-3).

[0030] Then, the payment processing unit 130 sends a payment completion notification to the payment application 20 via the content provision unit 110 (S18), and the payment application 20 displays a payment completion screen (S19).

[0031] Furthermore, electronic payment may be performed using only one of the above patterns. Also, the "account ID" explained in Figure 2 may be other information that can be used as user identification information (for example, a phone number). In addition, the issuance of a one-time code may be omitted during store scanning, and the payment app 20 may display a code image generated based on the user's account ID. In that case, the payment server 100 will identify the user corresponding to the account ID instead of identifying the user corresponding to the one-time code.

[0032] Furthermore, instead of managing the "post-payment" settlement through the credit card server 200, it may be handled internally by the payment server 100. In this case, the configuration of the payment card 60, credit card server 200, etc., may be omitted.

[0033] [Payment Method (Card Payment)] Figure 7 shows an example of a configuration for electronic payment (card payment) using a payment card. This electronic payment is executed around a payment card 60, which is one of the media Ms; a credit processing terminal 70, which is one of the store equipment Es; and a payment server 100 and a credit card server 200, which constitute part of the payment system S. The credit card server 200 communicates with the credit processing terminal 70 via a network NW.

[0034] The credit processing terminal 70 is installed in the store, similar to the store payment terminal 30. The credit processing terminal 70 includes, for example, a credit payment terminal (credit card reader) and a POS device. The credit payment terminal reads the PIN (Personal Identification Number) from the inserted or scanned credit card and verifies it against the PIN entered by the user, or transmits the PAN (Primary Account Number) read from the credit card to the credit card server 200 via the POS device. The POS device works with the credit payment terminal to transmit information such as the payment amount to the credit card server 200. An acquisitioner server may be interposed between the credit processing terminal 70 and the credit card server 200, but for the sake of simplicity, the description of the acquisitioner server will be omitted below. The payment card 60 is, for example, similar in form to a commonly used credit card, with a communication chip embedded in the card base material. The communication chip contains a storage medium that stores the PIN and communicates with an external device via a contactor (or wireless antenna). Alternatively, the payment card 60 may be a magnetic stripe card. Note that the information (messages) transmitted and received when using a credit card includes an authorization message for authentication and a sales message to convey the payment amount; however, a detailed explanation distinguishing between these will be omitted below.

[0035] The credit card server 200 communicates with the settlement server 100 via a network NW. The credit card server 200 includes, for example, an information management unit 210, a credit interface 220, a settlement distribution unit 230, a credit settlement processing unit 240, and a storage unit 270. Components other than the storage unit 270 are implemented, for example, by a hardware processor such as a CPU executing a program (software). Some or all of these components may be implemented by hardware (including circuitry) such as an LSI, ASIC, FPGA, or GPU, or by the cooperation of software and hardware. The program may be stored in advance in a storage device such as an HDD or flash memory (a storage device with a non-transient storage medium), or it may be stored in a removable storage medium such as a DVD or CD-ROM (a non-transient storage medium) and installed in the storage device when the storage medium is mounted in a drive device. The storage unit 270 stores information such as card user information 272.

[0036] The information management unit 210 edits, adds, and deletes card user information 272 and manages it. Card user information 272 is information that associates, for example, information unique to the user (e.g., PAN), the card payment method, and the user's account ID (used by the payment server 100) with each other. The card payment method is setting information that indicates whether the user will make an electronic payment using their charged balance (balance payment) or a deferred payment in card payments.

[0037] The credit interface 220 determines whether the BIN (Bank Identification Number) in the PAN included in the message received from the credit processing terminal 70 is a code for the company. If it is a code for the company, it passes the message received from the credit processing terminal 70 to the settlement distribution unit 230. If it is not a code for the company, it discards the received message.

[0038] The settlement distribution unit 230 refers to the user's card user information 272 corresponding to the message obtained from the credit interface 220 and determines whether the "card payment method" is set to "post-payment". If the "card payment method" is set to "post-payment", the settlement distribution unit 230 notifies the credit interface 220 of this and passes the message obtained from the credit interface 220 to the credit payment processing unit 240. On the other hand, if the "card payment method" is set to "balance payment", the settlement distribution unit 230 adds the user's account ID to the message obtained from the credit interface 220 and sends it to the settlement server 100 to request electronic payment. The settlement server 100, upon receiving the request for electronic payment, performs the same processing as in S7-1 in Figure 5 and S17-1 in Figure 6.

[0039] The credit interface 220 checks the PAN and expiration date, and verifies whether the cumulative payment amount exceeds the monthly limit. The credit payment processing unit 240 adds the payment amount to the user's monthly usage amount based on the information contained in the message obtained from the payment distribution unit 230, and performs electronic payment by deducting the monthly usage amount from the user's bank account after the closing date.

[0040] [Balance Management] The following describes the processing of the acquisition unit 140, the balance management unit 150, and the output unit 160. As mentioned above, the payment server 100 works in cooperation with the payment application 20 running on the user terminal device 10 to provide electronic payment services using a fund source that includes the charge balance charged by the user.

[0041] Figure 8 shows an overview of the balance management system operated by the balance management system information 176 and the balance management unit 150. In the figure, the find source outside the balance management system frame indicates that a charge has been made. Other deposits indicate that deposits are made to users through user-to-user transfers, refunds from merchants, and other types of deposits. The balance management unit 150 stores the amounts related to these deposits in a temporary deposit pool, associating them with the account ID of the receiving user. Then, after confirming that the deposit does not exceed the upper limit of the user's charge balance, the amount is moved from the temporary deposit pool to the user-specific balance frame. As explained in Figure 3, the user-specific balance frame has a first-type balance frame and a second-type balance frame. The first-type balance frame is for charge balances that cannot be withdrawn, and the second-type balance frame is for charge balances that can be withdrawn. The first-type balance frame is an example of a prepaid payment method. The balance management system has a balance aggregation function. The balance aggregation function monitors transactions (commands) that move amounts from the temporary deposit pool to each user's balance limit, and transactions that move amounts from gift codes to the system limit, and calculates the breakdown of the total amount as described below.

[0042] Next, we will explain gift codes. Figure 9 is a diagram illustrating the mechanism of gift codes. Gift codes are provided by merchants and, through user actions, can be converted into either a non-withdrawable charge balance (i.e., a prepaid payment method) or points that can be used as a charge balance. Which it is converted into depends on the settings of the gift code. Note that we will omit the explanation for gift codes that are converted into points. A gift code is activated, for example, when the user, who is the purchaser, reads the code image CD attached to the product using the payment application 20 on their user terminal device 10. When the payment application 20 reads the information encoded in the code image using an optical reading means (camera function or scanning function) activated by the user's actions, it notifies (sends) notification information containing the encoded information (hereinafter, encoded information) to the payment server 100. As shown in Figure 8, the balance management unit 150 of the payment server 100 moves the amount obtained from the encoded information from the system balance to the deposit temporary pool, and then moves the amount to the first type balance of the user-specific balance balance. This grants the user a non-withdrawable charge balance.

[0043] Here, of the amount issued as a gift code, the amount corresponding to the gift code that is converted into a non-withdrawable charge balance must be counted as part of a prepaid payment method. This is because this amount is considered a type of debt that the electronic payment service operator owes to the user, and there is an obligation to report it to the administrative agency, and a portion of it must be deposited as a security deposit. However, the gift code is activated when the user reads the code image CD with the payment app 20. To solve the problem arising from this time lag, the payment server 100 of the present invention performs the following processing. Previously, gift codes with an expiration date within a predetermined period were excluded from the operation, but they can be clearly managed as prepaid payment methods by the following mechanism.

[0044] Figure 10 shows an example of the processing flow for gift codes executed by the payment server 100. First, the acquisition unit 140 acquires the setting information for the gift code (S100). The setting information includes, for example, the total amount that the merchant plans to spend, the expiration date, whether it will be converted into a non-withdrawable charge balance or points, and the amount per transaction. The balance management unit 150 refers to the setting information and determines whether or not the gift code will be converted into a non-withdrawable charge balance (S102). If it is a gift code that will be converted into a non-withdrawable charge balance, the balance management unit 150 adds the value (total amount) indicated by the setting information to the system frame (S104). The system frame is a balance frame that does not depend on the user, that is, a balance frame that is not associated with a user-specific balance frame and is not related to any user, and is a balance frame that is counted as part of the prepaid payment method in the balance management system. At this time, the balance aggregation function of the balance management system counts (adds) the total amount to "low-amount prepayment" based on the transaction when the total amount is added to the system frame.

[0045] Subsequently, the balance management unit 150 determines whether it has received notification information related to the gift code that will be converted into a non-withdrawable charge balance (S110). For example, the notification information includes information indicating the correspondence with the setting information mentioned above. If notification information is received, the balance management unit 150 refers to the user information 172 and determines whether the user related to the notification information has been verified (S112). Since the notification information is sent from the payment app 20, it is naturally possible to identify the user. If the user has been verified, the balance management unit 150 moves the amount equivalent to the gift code (the amount of points per transaction) from the system balance to the first type balance of the user's balance balance as a "high-value prepayment" (along with a flag that recognizes it as a "high-value prepayment"). At this time, the balance aggregation function of the balance management system moves the corresponding amount from "low-value prepayment" to "high-value prepayment" based on the transaction of the amount transfer. More details will be described later.

[0046] If S112 determines that the user related to the notification information has not been verified, the balance management unit 150 moves the amount equivalent to the gift code (points per transaction) from the system balance to the first type balance of the user-specific balance balance.

[0047] After performing any of the processes in S114 to S116, the balance management unit 150 determines whether the termination condition of the gift code event (e.g., expiration of the expiration date) has been met (S118). If the termination condition of the gift code event has not been met, the process returns to S110. If the termination condition of the gift code event has been met, the process in this flowchart ends. At this time, if there is an amount related to the gift code event remaining in the system account, the balance management unit 150 moves the amount remaining in the system account to the discard account.

[0048] Through this process, aggregated information on prepaid payment instruments can be output. The output unit 160 outputs information to an information device connected to the payment server 100, for example, showing the total amount of the system limit that is counted as part of the prepaid payment instrument, as a breakdown of the total amount of the prepaid payment instrument. Figure 11 is a diagram showing an example of a screen that can be displayed based on the information output by the output unit 160. The issued amount is the total amount of the prepaid payment instrument, and includes the total amount of gift codes that are converted into non-withdrawable charge amounts. The recovered amount is the amount used for the prepaid payment instrument, and if the gift card is charged to the user's balance, it does not affect the total amount as it is only a change in the management method for the prepaid payment instrument, so neither issuance nor recovery is recognized. Low-amount prepayments refer to the prepayment balances of users whose identity verification has not been completed, and this includes gift card balances. In the diagram, when a gift code worth 5 million yen (which is converted into a non-withdrawable charge amount) is issued from state (1), it changes to state (2). Then, when a gift code worth 500 yen is converted into a charge amount by a certain user, it changes to state (3).

[0049] According to the embodiment described above, monetary information for events with a time lag between the time of setup and when it is granted to a specific user can be clearly managed as a prepaid payment method.

[0050] Although embodiments for carrying out the present invention have been described above using examples, the present invention is not limited in any way to these embodiments, and various modifications and substitutions can be made without departing from the spirit of the present invention. [Explanation of Symbols]

[0051] E. Store facilities M medium S Payment System 10. User terminal device 20 Payment Apps 30 Store Payment Terminals 40 Store Code Images 60 Payment Cards 70 Credit card processing terminal 100 Payment Servers 130 Payment Processing Unit 140 Acquisition Department 150 Balance Management Department 160 Output section 176 Balance Management System Information 200 credit card servers

Claims

1. A payment server that collaborates with a payment application running on a user's terminal device and provides electronic payment services using a fund source that includes the charge balance charged by the user, A device that retrieves gift code setting information from a storage unit, which includes the total amount of the amount to be converted into a non-withdrawable charge balance by the user's actions, and the amount of the gift code setting information that includes the total amount of the amount to be converted into a non-withdrawable charge balance and the amount to be given to the user each time. When the aforementioned setting information is obtained, the balance management unit adds the total amount obtained from the setting information to be converted into the non-withdrawable charge balance to the balance limit, which is a system limit that is counted as part of the prepaid payment method in the balance management system and is not dependent on the user. A payment server equipped with the following features.

2. When the payment application reads the information encoded in the code image for activating the gift code using an optical reading means activated by the user's actions, it notifies the payment server of the encoded information. The balance management unit, in response to the notification, converts the amount per transaction corresponding to the gift code into the non-withdrawable charge balance. The encoded information includes information indicating the correspondence with the gift code setting information. The settlement server according to claim 1.

3. The system further includes an output unit that outputs information showing the total amount of the balance limit counted as part of the prepaid payment instrument as a breakdown of the total amount of the prepaid payment instrument. The settlement server according to claim 1.

4. A payment server that works in cooperation with a payment application running on the user's terminal device and provides electronic payment services using a fund source including the charge balance charged by the user, A process to retrieve from a storage unit the setting information of a gift code provided by a merchant and converted into a non-withdrawable charge balance by the user's actions, which includes the total amount to be converted into the non-withdrawable charge balance and the amount to be given to the user each time. When the aforementioned setting information is obtained, the process involves adding the total amount obtained from the setting information to be converted into the non-withdrawable charge balance to the balance limit, which is a system limit that is counted as part of the prepaid payment method in the balance management system and is independent of the user. A balance management method that performs this task.

5. The payment server processor, which works in conjunction with the payment application running on the user's terminal device and provides electronic payment services using a fund source including the charge balance charged by the user, A process to retrieve from a storage unit the setting information of a gift code provided by a merchant and converted into a non-withdrawable charge balance by the user's actions, which includes the total amount to be converted into the non-withdrawable charge balance and the amount to be given to the user each time. When the aforementioned setting information is obtained, the process involves adding the total amount obtained from the setting information to be converted into the non-withdrawable charge balance to the balance limit, which is a system limit that is counted as part of the prepaid payment method in the balance management system and is independent of the user. A program to execute.

Images