Information processing device, information processing method, and program
The information processing device analyzes credit card payment histories to select affiliated stores for prepaid card use, addressing overdraft risks and ensuring timely payment processing.
Patent Information
- Application Number
- JP2025102542
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2025-06-18
- Publication Date
- 2025-10-27
- Estimated Expiration
- 2045-06-18
AI Technical Summary
Existing electronic payment systems face challenges in selecting affiliated stores that allow the use of prepaid cards, leading to potential overdrafts and financial risks for service providers due to varying payment amounts at the time of sale and authorization.
An information processing device and method that analyzes credit card payment histories to generate lists of affiliated stores that permit or restrict the use of prepaid cards, based on payment data to manage electronic money balances effectively.
Enables appropriate selection of affiliated stores for prepaid card usage, reducing financial risks and ensuring timely payment processing.
Smart Images

Figure 0007760793000001_ABST
Abstract
Description
[Technical Field]
[0001] The present invention relates to an information processing device, an information processing method, and a program. [Background technology]
[0002] Conventionally, there is known an electronic payment service in which code information is displayed on a user terminal device owned by a user and the code information is read by a store terminal device installed in a store to execute electronic payment. Patent Document 1 also proposes an electronic payment system in which credit cards that can be used in the electronic payment service are registered in a payment server. [Prior art documents] [Patent documents]
[0003] [Patent Document 1] Patent No. 7311726 Summary of the Invention [Problem to be solved by the invention]
[0004] However, in the electronic payment system described in Patent Document 1, the electronic money balance charged by a user could only be used for payments at businesses that had concluded an affiliated store agreement with an electronic payment service provider that offered payments using electronic money, which sometimes caused inconvenience to users when making payments at businesses with which the provider had not concluded an affiliated store agreement. For this reason, in recent years, technology has been used that links the electronic money balance charged by a user to a prepaid card of an international brand that can be used for payments at the provider's stores, allowing the electronic money balance to be used for payments with the prepaid card.
[0005] However, with this technology, there are cases where the payment amount at the time of sale at the affiliated store (which is confirmed at a later time) exceeds the payment amount at the time of authorization, which is executed when a payment is made using a prepaid card. In this case, if the payment amount at the time of sale exceeds the electronic money balance, an excess amount occurs, and the user enters a state where they have borrowed funds from the electronic payment service provider for the excess amount to transact with the affiliated store (so-called overdraft). In such cases, the electronic payment service provider bears the financial risk for the user for the excess amount, but the frequency and amount of overdrafts vary depending on the store and industry of the affiliated store. Therefore, it is a challenge for electronic payment service providers to appropriately select affiliated stores that allow the use of prepaid cards in order to reduce financial risk.
[0006] The present invention has been made in consideration of these circumstances, and one of its objects is to provide an information processing device, an information processing method, and a program that can appropriately select affiliated stores that will allow the use of a prepaid card. [Means for solving the problem]
[0007] One aspect of the present invention is an information processing device that includes an acquisition unit that acquires at least a credit card payment history performed at one or more credit card affiliated stores, and a generation unit that generates, based on the payment history, list information that identifies affiliated stores among the one or more affiliated stores that will or will not allow the use of a prepaid card that performs payment processing using the electronic money balance of an electronic payment service that has been charged by the user. [Effects of the Invention]
[0008] According to one aspect of the present invention, it is possible to provide an information processing device, an information processing method, and a program that can appropriately select affiliated stores that permit the use of a prepaid card. [Brief explanation of the drawings]
[0009] [Figure 1]FIG. 1 is a diagram illustrating an example of the configuration of an electronic payment system in which an electronic payment service is realized. [Figure 2] This is a sequence diagram (part 1) illustrating the general flow of electronic payment. [Figure 3] This is a sequence diagram (part 2) illustrating the general flow of electronic payment. [Figure 4] FIG. 2 is a configuration diagram of a payment server 100. [Figure 5] FIG. 10 is a diagram showing an example of the contents of user information 172. [Figure 6] FIG. 10 is a diagram showing an example of the contents of affiliated store / store information 176. [Figure 7] FIG. 2 is a diagram illustrating the configuration of a user terminal device 200. [Figure 8] FIG. 1 is a diagram showing a first example of an outline of prepaid card payment. [Figure 9] FIG. 10 is a sequence diagram illustrating an example of a process for purchasing a product using a prepaid card. [Figure 10] FIG. 10 is a diagram showing an example of authorization information 178. [Figure 11] FIG. 10 is a diagram showing an example of sales confirmation information 180. [Figure 12] FIG. 10 is a diagram showing an example of a home screen of the payment application 20. [Figure 13] FIG. 10 is a diagram showing an example of a payment screen of payment application 20. [Figure 14] FIG. 10 is a diagram showing an example of rule information 182. [Figure 15] FIG. 10 is a diagram showing an example of blacklist information 184. [Figure 16] FIG. 10 is a diagram showing an example of whitelist information 186. [Figure 17] 10 is a flowchart showing an example of the flow of processing executed by the payment server 100. [Figure 18] FIG. 10 is a diagram showing a second example of an outline of prepaid card payment. DETAILED DESCRIPTION OF THE INVENTION
[0010] Hereinafter, with reference to the drawings, embodiments of an information processing device, an information processing method, and a program according to the present invention will be described. The various devices and servers described below, which provide services to users and perform internal analysis, may be realized by a group of distributed devices, and each device may be operated by a different business. Furthermore, the hardware owner (the cloud server provider) and the business that actually operates the device may also be different. An application program and a payment server work together to provide an electronic payment service. In the following description, the application program is referred to as a payment app. An electronic payment service is a service that supports payments for the purchase of goods and services at a store. A store is, for example, a physical store (real store) existing in real space, but may also include a virtual store for e-commerce. Virtual stores may also include stores provided by entities other than the operator of the electronic payment service. In such cases, a transition to an interface screen for the electronic payment service may be performed when making a payment for a purchase at the virtual store. In an electronic payment service, a store is treated as belonging to, for example, an affiliated store (brand), and when a purchase is made at a store, processing such as payment is primarily performed between the user and the affiliated store. Alternatively, processing such as payment may be performed between the user and the store. The card company server and the payment server also work together to provide payment services using credit cards and prepaid cards. A prepaid card is a prepaid card that can be charged with electronic money in advance and used at affiliated stores. When using a prepaid card at a store, payments can be made by holding or inserting the prepaid card into a store terminal device for cards. When using a prepaid card, the user may be required to enter a PIN. Furthermore, when using a credit card or prepaid card for online transactions (such as internet shopping), the user may be required to enter card information (such as the prepaid card number and expiration date) for the credit card or prepaid card on the payment screen of a website.
[0011] [Electronic payment service] FIG. 1 shows an example of the configuration of an electronic payment system in which an electronic payment service is realized. The electronic payment service is realized mainly by a payment server 100. The electronic payment system that realizes the electronic payment service includes, for example, one or more user terminal devices 200, one or more first store terminal devices 50, one or more second store terminal devices 70, the payment server 100, a card store terminal device 300, and a card company server 400. These devices communicate, for example, via a network NW. The network NW includes, for example, the Internet, a LAN (Local Area Network), a wireless base station, a provider device, etc.
[0012] Some or all of the functional components included in the electronic payment system may be distributed across multiple devices in any form, or may be integrated into any device. For example, some or all of the functional components of card company server 400 may be included in the configuration of payment server 100, and some or all of the functional components of payment server 100 may be included in the functional configuration of card company server 400.
[0013] User terminal device 200 is, for example, a portable terminal device such as a smartphone or tablet terminal. User terminal device 200 is a computer device having at least an optical reading function, a communication function, a display function, an input acceptance function, and a program execution function. In the following description, components for realizing these functions are referred to as a camera, a communication device, a touch panel, a CPU (Central Processing Unit), etc. In user terminal device 200, a processor such as a CPU executes payment app 20, which operates in cooperation with payment server 100 to provide electronic payment services to users. Payment app 20 is installed on user terminal device 200 from, for example, an application store, and controls the camera, communication device, touch panel, etc.
[0014] The first store terminal device 50 is installed, for example, in a store. The first store terminal device 50 is a computer device having at least a product price acquisition function, an optical reading function, a program execution function, and a communication function. The first store terminal device 50 includes a so-called POS (Point of Sale) device, and the product price acquisition function and the optical reading function may be realized by the POS device. The store code image 60 is placed in the store and is a code image such as a QR code (registered trademark) printed on a paper or plastic medium. The store code image 60 may be displayed on a display placed in the store (which may be the display of a terminal device such as a smartphone).
[0015] The second store terminal device 70 is used by the operator of the affiliated store. The second store terminal device 70 is a smartphone, tablet terminal, personal computer, etc. An interface for affiliated stores 72 runs on the second store terminal device 70. The interface for affiliated stores 72 may be an app for affiliated stores or a browser. The interface for affiliated stores 72 accepts coupon settings and the like from the operator of the affiliated store and transmits them to the payment server 100. The second store terminal device 70, which is a smartphone, has the function of displaying a code image corresponding to a store code image and reading the code image displayed by the user terminal device 200 by executing the app for affiliated stores.
[0016] The payment server 100 realizes electronic payment based on payment information received from the user terminal device 200 or the first store terminal device 50. The first store terminal device 50 may include a POS device and an affiliated store server, in which case payment information is sent from the POS device via the affiliated store server to the payment server 100. In the following explanation, this distinction will not be made and it is assumed that payment information is sent from the first store terminal device 50.
[0017] The store terminal 300 is a terminal used at affiliated stores that accept credit cards and prepaid cards. The store terminal 300 acquires information on the credit card or prepaid card presented by the user and transmits the acquired information to the card company server 400.
[0018] The card company server 400 is a server device of a card issuing company that issues credit cards and prepaid cards. The card company server 400 is operated, for example, by a group company of the payment server 100. In this embodiment, the affiliated store is an affiliated store of the electronic payment service as well as an affiliated store of the card issuing company. As will be described later, since the messages for credit cards and prepaid cards are the same (in other words, prepaid cards can also be used at credit card affiliated stores), the affiliated store that is the subject of judgment in the present invention only needs to be at least a credit card affiliated store.
[0019] 2 and 3 are sequence diagrams illustrating the general flow of electronic payment. There may be two patterns for electronic payment: Pattern 1 and Pattern 2.
[0020] In the case of pattern 1 (hereinafter referred to as user scan) shown in FIG. 2, user terminal device 200, with payment application 20 running, decodes store code image 60 using its optical reading function (S1). Store code image 60 includes store URL (Uniform Resource Locator) information. This store URL is the domain of the electronic payment service to which store identification information has been added, and is associated with an affiliated store ID, store ID, etc. in payment server 100 (described below). Payment application 20 sends first payment information including the store URL and account ID to payment server 100 (S2). Payment server 100 searches for store information (described below) using the affiliated store ID and store ID corresponding to the store URL, acquires information on the affiliated store name and store name (S3), and sends this information to payment application 20 (S4). The user enters the payment amount into user terminal device 200 on the screen displaying the affiliated store name and store name (S5). Then, the user terminal device 200 generates second payment information including at least the payment amount and sends it to the payment server 100 (S6). The payment server 100 makes the electronic payment based on the received second payment information (S7). The payment server 100 then sends a payment completion notice (information for displaying a payment completion screen) to the payment app 20 (S8), and the payment app 20 displays the payment completion screen (S9). Note that when the store code image 60 is displayed on a display installed in the store, the store code image 60 may include information on the payment amount in addition to the store URL. In this case, the step of the user inputting the payment amount is omitted, and the payment amount information is included in the first payment information and sent to the payment server 100. Information on the affiliated store name and store name may be included and displayed on the payment completion screen.
[0021] In the case of pattern 2 (hereinafter referred to as store scan) shown in FIG. 3, the payment app 20 sends a request to issue a one-time code to the payment server 100 when the payment app 20 is launched, when a payment operation is performed in the payment app 20, at the automatic update timing (e.g., every minute), and at other timings (S11). 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, generated based on the one-time code (S14). The user holds (presents) the display surface of the user terminal device 200 over the first in-store terminal device 50, and the first in-store terminal device 50 decodes the code image using its optical reading function and obtains the one-time code, etc. (S15). The first in-store terminal device 50 then generates payment information including the one-time code, payment amount, affiliated store ID, store ID, etc., and sends it to the payment server 100 (S16). The payment amount information is acquired in advance by reading a barcode, manually entering it, etc. Based on the received information, the payment server 100 identifies the user corresponding to the one-time code and performs electronic payment (S17). Then, the payment server 100 sends a payment completion notice to the payment application 20 (S18), and the payment application 20 displays a payment completion screen (S19).
[0022] Note that electronic payment may be performed using only one of the above patterns. Furthermore, the "account ID" described in FIG. 2 may be other information (e.g., a phone number) that can be used as user identification information. Furthermore, issuing a one-time code may be omitted in store scanning, and the payment application 20 may display a code image generated based on the user's account ID. In this case, the payment server 100 identifies the user corresponding to the account ID instead of identifying the user corresponding to the one-time code.
[0023] [Payment server] 4 is a configuration diagram of the payment server 100. The payment server 100 includes, for example, a communication unit 110, a payment content providing unit 120, a payment processing unit 130, an information management unit 140, an acquisition unit 150, a generation unit 160, and a storage unit 170. The components other than the communication unit 110 and the storage unit 170 are realized by, for example, a hardware processor such as a CPU executing a program (software). Some or all of these components may be realized by hardware (including circuitry) such as an LSI (Large Scale Integration), an ASIC (Application Specific Integrated Circuit), an FPGA (Field-Programmable Gate Array), a GPU (Graphics Processing Unit), or an SOC (System On Chip), or may be realized by a combination of software and hardware. The program may be stored in advance in a storage device such as an HDD (Hard Disk Drive) or flash memory (a storage device with a non-transitory storage medium), or may be stored in a removable storage medium (a non-transitory storage medium) such as a DVD or CD-ROM, and installed in the storage device by inserting the storage medium into a drive device.
[0024] The storage unit 170 is a hard disk drive (HDD), flash memory, RAM (Random Access Memory), or the like. The storage unit 170 may be a NAS (Network Attached Storage) device accessible by the payment server 100 via a network. The storage unit 170 stores information such as user information 172, payment content information 174, affiliated store / shop information 176, authorization information 178, sales confirmation information 180, rule information 182, blacklist information 184, and whitelist information 186. Some of this information may be stored in the storage unit of the user terminal device 200. The authorization information 178 and sales confirmation information 180 are examples of "payment history" in the claims, and the blacklist information 184 and whitelist information 186 are examples of "list information" in the claims.
[0025] The communication unit 110 is a communication interface for connecting to the network NW, and is, for example, a network interface card.
[0026] The payment content providing unit 120 has, for example, a web server function, and provides information (content) for displaying various screens of the electronic payment service to the user terminal device 200. The payment content providing unit 120 reads out necessary content from payment content information 174 as appropriate and provides it to the user terminal device 200. The user terminal device 200 accepts various inputs from the user while content is being played by the payment application 20, and transmits the above-mentioned payment information and the like to the payment server 100. The above content may be generated by the payment application 20. In this case, the payment content providing unit 120 provides the payment application 20 with information necessary for generating the content.
[0027] The payment processing unit 130 performs payment processing based on the payment information transmitted by the user terminal device 200 or the first store terminal device 50. The payment processing unit 130 performs payment processing while referring to the user information 172.
[0028] FIG. 5 is a diagram showing an example of the contents of user information 172. User information 172 is an example of user registration information. User information 172 includes, for example, a user URL, account ID, telephone number, and password, as well as an email address, user ID, name, address, date of birth, registration date, remaining balance, credit card payment settings, credit card limit, credit card payment amount, available credit card payment amount, payment method settings, bank account, credit card number, charge history information, payment history information, prepaid card information, and overdraft amount. The user URL is used for remittance processing between users. Registration of a phone number and password is required when registering for the electronic payment service. The account ID is issued to the user by the payment server 100, and the user ID can be set by the user (or does not have to be set). The email address, name, address, and date of birth are also information that can be set by the user (or do not have to be set). The registration date is the date on which the user registered for the electronic payment service (the date on which the account was created). Hereinafter, the user's instance (electronic payment account) to which this information is associated will be referred to as an account.
[0029] The charge balance indicates the balance of electronic money set by the user by transferring funds to the account in advance. Transfer methods include transfers from a designated bank's ATM (Automatic Teller Machine) or from a registered bank account. The credit payment setting indicates whether the settings for electronic credit payment have been completed and is set to either "Completed" or "Not Completed." The credit payment limit is the monthly credit payment limit. The credit payment amount is the amount of credit payment already used in the current month. The available credit payment amount is the amount of credit payment available in the current month, calculated by subtracting the credit payment amount from the credit payment limit. While the figure shows only one credit payment limit, in reality, there may also be daily limits, and the lower of these may be set as the credit payment limit. Further details on credit payments will be discussed later. The payment method setting indicates whether the user will currently make electronic payments using the charge balance or by credit payment. The bank account and credit card number are information on the bank account or credit card number (account number, card number) that can be used to deposit funds into the electronic payment service. The charge history information is a history of the user's previous transfers to the electronic payment service to increase the charge balance. The payment history information is information that shows the breakdown of payments made by the user for each payment (date and time, store ID of the store where the purchase was made, payment amount, payment method, etc.).
[0030] Prepaid card information is information about the prepaid card, such as the prepaid card number, expiration date, etc. The excess amount, which will be described in detail later, is the amount that occurs when, due to the payment mechanism, the payment amount for a payment using a prepaid card is confirmed and the confirmed payment amount is unintentionally larger than the user's electronic money balance.
[0031] FIG. 6 is a diagram showing an example of the contents of affiliated store / store information 176. The affiliated store / store information 176 includes, for example, a first table 176A in which an affiliated store ID and a store ID are associated with a store URL, a second table 176B in which an affiliated store ID is associated with an affiliated store name and sales amount (described above), and a third table 176C in which a store ID is associated with a store name. In addition to this information, the affiliated store / store information 176 may also include information such as the category of the affiliated store or store, the store location, and payment patterns. The above-mentioned affiliated store name may be, for example, information registered by the affiliated store or by an administrator of the electronic payment service. The above-mentioned affiliated store name and store name may be managed together. The above-mentioned affiliated store name may be, for example, a combination of the affiliated store name and the store name. It is preferable that the above-mentioned affiliated store name be an official name or a detailed name. In the affiliated store / store information 176, an affiliated store icon or other detailed information about the affiliated store may be associated with the affiliated store ID or store ID.
[0032] The information management unit 140 acquires information provided by other server devices and terminal devices. The information management unit 140 manages user information 172, affiliated store / store information 176, and authorization information 178 based on information acquired from the user terminal device 200 and the second store terminal device 70. The information management unit 140 adds new records, edits, deletes, etc. for the user information 172, affiliated store / store information 176, and authorization information 178.
[0033] The acquisition unit 150, as will be described in detail later, acquires first payment information including the payment amount (first payment amount) at the time of authorization (hereinafter referred to as "authorization") for payments using a prepaid card, and acquires second payment information including the payment amount (second payment amount) at the time of sales at the affiliated store. Furthermore, for payments using a credit card, the acquisition unit 150 acquires from the card company server 400 first payment information including the payment amount (first payment amount) at the time of authorization, and acquires second payment information including the payment amount (second payment amount) at the time of sales at the affiliated store.
[0034] [Electronic Payment] When payment information is acquired from the user terminal device 200 or the first store terminal device 50, the payment processing unit 130 references the user information 172 to acquire the "payment method setting" of the user. For users whose "payment method setting" is set to "charge balance," the payment processing unit 130 performs electronic payment as follows: For example, the payment processing unit 130 performs electronic payment by decreasing the charge balance managed in association with the user ID and increasing the item value of the affiliated store's sales proceeds. The item value of the affiliated store's sales proceeds is not used as electronic money itself, for example. Instead, the amount corresponding to the item value of the sales proceeds is transferred to a bank account in accordance with a cycle agreed upon between the affiliated store and the electronic payment service. The affiliated store may receive the sales proceeds as electronic money. In this case, the payment server 100 manages the account (wallet) corresponding to the affiliated store ID, the account's electronic money balance, and the sales proceeds history for each payment method in association with each other.
[0035] The payment processing unit 130 performs electronic payments for users whose "setting information" is set to "credit payment" as follows. Credit payment is a payment method in cooperation with a credit card company, which is a separate entity from the operator of the electronic payment service, and allows electronic payments within the credit payment limit and independent of the charge balance. To receive the credit payment service, a user may be required to obtain a credit card provided by the operator of the electronic payment service. The payment processing unit 130 adds the payment amount to the credit payment amount in the user information 172 and subtracts the payment amount from the available credit payment amount. If the payment amount exceeds the available credit payment amount, an error notification is returned to the payment app. The amount used for credit payment is settled, for example, for one month in a lump sum on the payment date of the following month, for example, by debit from a bank account. This processing is performed by the operator of the credit card company.
[0036] [User terminal device] 7 is a configuration diagram of user terminal device 200. User terminal device 200 includes, for example, a communication unit 210, a display unit 220, an input unit 230, a control unit 240, and a storage unit 250. Communication unit 210 is a communication interface for communicating via network NW. Display unit 220 and input unit 230 are realized, for example, by a touch panel display.
[0037] The control unit 240 is realized, for example, by a hardware processor such as a CPU executing a program (software). Some or all of these components may be realized by hardware (including circuit units) such as an LSI, ASIC, FPGA, or GPU, or may be realized by a combination 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 having a non-transitory storage medium), or may be stored in a removable storage medium (non-transitory storage medium) such as a DVD or CD-ROM, and installed in the storage device by inserting the storage medium into a drive device.
[0038] Storage unit 250 is a HDD, flash memory, RAM, or the like. Storage unit 250 may be a NAS device that user terminal device 200 can access via a network. Storage unit 250 stores user information 252, payment application 20, and the like. User information 252 is some or all of the information in the record corresponding to the user who owns user terminal device 200, among user information 172 shown in FIG. 5. Payment application 20 is read and executed by a hardware processor (such as a CPU) in user terminal device 200.
[0039] By launching the payment application 20 on the user terminal device 200, the user can use the electronic payment service provided by the payment server 100. That is, when the user operates the payment application 20 screen, electronic payment is performed by user scanning (FIG. 2) or store scanning (FIG. 3). While this electronic payment process is the same as conventional methods, this embodiment also makes it possible to make prepaid card payments using the charged electronic money balance. This point will be explained below.
[0040] [Prepaid card payment overview (example 1)] Figure 8 is a diagram showing a first example of an overview of prepaid card payments. The example shown in Figure 8 shows the processing flow when an on-us transaction is conducted. An on-us transaction is a transaction in which the issuer (issuer) of the prepaid card and the affiliated store contracting company (acquirer) are the same company. For this reason, in Figure 8, there is no affiliated store contracting company (acquirer) between the affiliated store and the card company.
[0041] In this embodiment, prepaid card payment is made from the charge balance of electronic money used in the electronic payment service. Therefore, before actually making a prepaid card payment, the user charges electronic money from the screen of the payment application 20 (S101). As a result, the payment server 100 adds the specified amount of electronic money to the electronic money balance linked to the user's account.
[0042] Next, the user applies for purchasing a product at an affiliated store (S102). At this time, the user has the prepaid card read by the card store terminal device 300. This allows the card store terminal device 300 to obtain card information (prepaid card number, expiration date, etc.) of the user's prepaid card. Note that although an application for purchasing a product is used here, it may also be an application for using a service.
[0043] Next, the card store terminal device 300 transmits payment information, including the settlement amount of the product to be purchased, to the card company server 400 (S103). There are two types of payment information: first payment information including the first payment amount, which is the payment amount at the time of authorization, and second payment information including the second payment amount, which is the payment amount at the time of sale at the affiliated store. However, for ease of explanation, they are simply referred to as "payment information" here. Details of the first payment information and the second payment information will be described later.
[0044] Next, upon receiving the payment information, the card company server 400 determines whether the card linked to the card number is a credit card or a prepaid card, for example, by referring to the card number included in the payment information. Whether the card linked to the card number is a credit card or a prepaid card can be determined, for example, by referring to a number corresponding to a predetermined number of digits in the card number. Here, it is assumed that the card company server 400 determines that the card linked to the card number is a prepaid card. If it is determined that the card linked to the card number is a prepaid card, the card company server 400 transmits payment information to the payment server 100 (S105). The payment server 100 deducts the payment amount from the user's charge balance based on the payment information received from the card company server 400 (S106). Specifically, the payment server 100 subtracts the payment amount from the user's charge balance in the user information 172.
[0045] Meanwhile, the card company server 400 pays the settlement amount to the affiliated store (S107). For example, the card company server 400 may transfer the settlement amount to the affiliated store's bank account. This allows the affiliated store to receive the settlement amount corresponding to the user's purchase of a product (or use of a service).
[0046] However, when the payment in S107 is completed, it is assumed that the card company has paid the settlement amount in advance. Therefore, the card company server 400 sends an advance payment request to the payment server 100 (S108). The payment server 100 pays the advance payment based on the advance payment request received from the card company server 400 (S109). Through the above process, when a user purchases a product (or uses a service) using a prepaid card, the payment can be made from the charge balance of the user's electronic money.
[0047] On the other hand, if S104 determines that the card associated with the card number is a credit card, the card company server 400 executes authorization processing independently without requesting processing from the payment server 100. More specifically, for example, the card company server 400 determines whether the credit card's available balance is equal to or greater than the payment amount. If it is determined that the credit card's available balance is equal to or greater than the payment amount, the card company server 400 approves the current credit card payment. After executing authorization processing, the card company server 400 shares data related to the executed authorization processing with the payment server 100 as authorization information 178. After that, when the credit card payment amount is confirmed, the card company server 400 shares data related to the confirmed payment amount with the payment server 100 as sales confirmation information 180. The user is then billed by the card company for the confirmed credit card usage amount at the end of each month. Therefore, with credit card payment, payment is not made immediately even if the user purchases a product. Note that credit card payment in FIG. 8 is different from credit card payment via user scan and store scan described in FIGS. 2 and 3.
[0048] On the other hand, with prepaid card payment, the payment server 100 refers to the user information 172 to check the user's electronic money balance (charge balance) and determines whether to approve the prepaid card payment. When a user purchases a product using a prepaid card, the payment server 100 immediately deducts the payment amount from the user's charge balance. Therefore, with a prepaid card, unlike credit card payment, the payment amount is immediately secured from the user's balance.
[0049] When making payments with credit cards and prepaid cards, the payment amount may differ between the time of authorization and the time of sale at the affiliated store. For example, when a user fills up at a gas station, the amount of gas actually filled is unknown at the time of authorization, so authorization processing may be performed with a payment amount of 1 yen. However, when the purchase is made at the affiliated store (gas station), the payment may be processed with a payment amount corresponding to the amount of gas actually filled (e.g., 5,000 yen). As another example, when a user makes a reservation at a hotel through a travel agency, authorization processing may be performed with the accommodation fee as the payment amount at the time of authorization, and when the purchase is made at the affiliated store (accommodation), the payment may be processed with the fee for the services actually used at the hotel (e.g., room service) added to the payment amount. In this way, the payment amount may differ between the time of authorization and the time of sale at the affiliated store. Based on this, the details of the processing when paying with a prepaid card will be explained below.
[0050] [Sequence diagram] Fig. 9 is a sequence diagram showing an example of a process related to purchasing a product using a prepaid card. The process shown in the sequence diagram of Fig. 9 is executed when a user applies to purchase a product at a member store. Note that although an application to purchase a product is used here, it may also be an application to use a service.
[0051] First, the card store terminal device 300 acquires card information (such as the prepaid card number and expiration date) of the user's prepaid card (S201). For example, the card store terminal device 300 may read the card information directly from the prepaid card presented by the user, or may have the user input the card information.
[0052] Next, the card store terminal device 300 transmits first payment information to the card company server 400 (S202). The first payment information is payment information at the time of authorization, which will be described later. For example, the first payment information includes an authorization message ID, an authorization type, a card number, a terminal identification number, a member store ID, a member store name, a store ID, an industry code, and a first payment amount. The authorization message ID is identification information for identifying each authorization corresponding to the first payment information. The authorization type is information indicating the type of the authorization (e.g., a usage authorization, a credit authorization, a recurring authorization, etc.). Here, a usage authorization refers to an authorization for requesting the execution of electronic payment using a card, a credit authorization refers to an authorization for requesting confirmation of the validity of a card, and a recurring authorization refers to an authorization for requesting the execution of multiple periodic electronic payments using a card. The card number is the number of the user's card included in the card information acquired in S201. The terminal identification number is identification information for identifying the card store terminal device 300. The affiliated store ID is identification information for identifying the affiliated store to which the store where the user is attempting to purchase a product belongs, and is the same information as the affiliated store ID shown in Figure 6. The store ID is identification information for identifying the store where the user is attempting to purchase a product, and is the same information as the store ID shown in Figure 6. The business code is identification information for identifying the business type of the affiliated store. The first payment amount is the payment amount at the time of authorization.
[0053] Next, the card company server 400 receives the first payment information from the card store terminal device 300 and, for example, references the card number included in the first payment information to determine whether the card linked to the card number is a credit card or a prepaid card (S203). Here, it is assumed that the card company server 400 determines that the card linked to the card number is a prepaid card. In this case, the card company server 400 transmits the received first payment information to the payment server 100 (S204). In this embodiment, the first payment information is transmitted to the payment server 100 because the payment server 100 performs payment processing for the prepaid card.
[0054] Next, the acquisition unit 150 of the payment server 100 acquires the first payment information transmitted from the card company server 400. The payment processing unit 130 performs authorization processing based on the first payment information acquired by the acquisition unit 150 (S205). The authorization processing is processing for determining whether or not to approve a payment using a prepaid card based on the first payment information. Specifically, in the authorization processing, the payment processing unit 130 acquires the user's electronic money balance (charge balance) from the user information 172. Furthermore, if the first payment amount included in the first payment information is less than or equal to the user's electronic money balance, the payment processing unit 130 determines to approve the payment using the prepaid card and subtracts the first payment amount from the user's electronic money balance. On the other hand, if the first payment amount included in the first payment information is greater than the user's electronic money balance, the payment processing unit 130 determines not to approve the payment using the prepaid card.
[0055] Next, the information management unit 140 updates the authorization information 178 stored in the storage unit 170 (S206). Fig. 10 is a diagram showing an example of the authorization information 178. As shown in Fig. 10, the authorization information 178 includes an authorization message ID, authorization date and time, authorization type, card number, card type, terminal identification number, affiliated store ID, affiliated store name, store ID, business code, first payment amount, and determination result.
[0056] Specifically, the information management unit 140 links the authorization message ID, authorization date and time, authorization type, card number, card type, terminal identification number, affiliated store ID, affiliated store name, store ID, business code, first payment amount, and determination result and adds them to the authorization information 178. In the case of a payment using a prepaid card, the authorization message ID, authorization date and time, authorization type, card number, terminal identification number, affiliated store ID, affiliated store name, store ID, business code, and first payment amount are information included in the first payment information received in S204. On the other hand, in the case of a payment using a credit card, these pieces of information are information provided by the card company server 400 after the card company server 400 executes the authorization process. The card type is information identifying whether the card for which the authorization process was executed is a credit card or a prepaid card. The authorization date and time is information indicating, for example, the date and time when the card store terminal device 300 issued the authorization message. The card type is added as a data item for convenience of explanation, but may be omitted. The payment server 100 may determine the card type by referring to a number corresponding to a predetermined number of digits in the card number, or may receive the card type from the card company server 400. The determination result is the result of the authorization process in S205. If the authorization process determines that the payment using the prepaid card is approved, the determination result is OK. On the other hand, if the authorization process determines that the payment using the prepaid card is not approved, the determination result is NG. For example, in FIG. 10, the determination result for the credit authorization using the prepaid card is NG. In this embodiment, the payment processing unit 130 does not approve small-amount authorizations (use authorizations in which the first payment amount is equal to or less than a predetermined amount), credit authorizations, or recurring authorizations for electronic payments using prepaid cards. The authorization type being a small-amount authorization, credit authorization, or recurring authorization is an example of satisfying the "predetermined condition" in the claims.
[0057] Returning to the explanation of FIG. 9, next, the payment server 100 transmits the authorization result to the card company server 400 (S207). The authorization result is information including an authorization message ID and a determination result (OK or NG). The card company server 400 transmits the authorization result to the card store terminal device 300 (S208), and the card store terminal device 300 transmits the authorization result to the user terminal device 200 (S209). The user terminal device 200 may display whether or not the payment using the prepaid card has been approved based on the authorization result received from the card store terminal device 300. This allows the user to understand the authorization result.
[0058] Next, the card store terminal device 300 transmits second payment information to the card company server 400 (S210). The second payment information is payment information at the time of sale at the affiliated store. For example, the second payment information includes a sales message ID, an authorization message ID linked to the sale, a prepaid card number, a terminal identification number, an affiliated store ID, and a second payment amount. The second payment amount is the payment amount at the time of sale at the affiliated store.
[0059] Next, the card company server 400 receives the second payment information from the card store terminal device 300 and transmits the received second payment information to the payment server 100 (S211). In this embodiment, the second payment information is transmitted to the payment server 100 to perform electronic payment using the user's electronic money balance with the prepaid card.
[0060] Next, the acquisition unit 150 of the payment server 100 acquires the second payment information transmitted from the card company server 400. The payment processing unit 130 performs payment processing based on the second payment information acquired by the acquisition unit 150 (S212). Specifically, the payment processing unit 130 acquires the first payment amount linked to the authorization message ID included in the second payment information from the authorization information 178. Furthermore, if the second payment amount included in the second payment information matches the first payment amount, the payment processing unit 130 completes the payment processing. On the other hand, if the second payment amount included in the second payment information does not match the first payment amount, the payment processing unit 130 calculates an additional amount to be collected by subtracting the first payment amount from the second payment amount. Thereafter, the payment processing unit 130 subtracts the calculated additional amount to be collected from the user's electronic money balance and completes the payment processing. This allows appropriate payment processing even if the second payment amount at the time of sale at the affiliated store is higher than the first payment amount at the time of authorization.
[0061] Next, the information management unit 140 updates the user information 172 and the sales confirmation information 180 stored in the storage unit 170 (S213). Specifically, the information management unit 140 updates the charge balance in the user information 172 based on the user's electronic money balance after deducting the additional collection amount.
[0062] FIG. 11 is a diagram illustrating an example of sales confirmation information 180. As shown in FIG. 11, sales confirmation information 180 includes a sales message ID, a sales confirmation date and time, an authorization message ID, a card number, a card type, a terminal identification number, a member store ID, a member store name, a store ID, a business code, and a second payment amount. Specifically, information management unit 140 links the sales message ID, the sales confirmation date and time, the authorization message ID, the card number, a card type, a terminal identification number, a member store ID, a member store name, a store ID, a business code, and the second payment amount and adds them to authorization information 178. In the case of a payment using a prepaid card, the sales message ID, the authorization message ID, the card number, the terminal identification number, the member store ID, the member store name, the store ID, the business code, and the second payment amount are information included in the second payment information received in S211. On the other hand, in the case of a payment using a credit card, these pieces of information are information provided by card company server 400 after card company server 400 executes the sales confirmation process. The sales confirmation date and time is information indicating, for example, the date and time when the card store terminal device 300 issued the sales message. The card type is information identifying whether the card on which the sales confirmation process was executed is a credit card or a prepaid card. As in Figure 10, the card type may be omitted.
[0063] As shown in FIG. 11, the card store terminal 300 typically links a sales message with an authorization message ID and notifies the card company server 400 of the message. This allows the card company server 400 to grasp definitive sales information linked to each authorization process. However, each affiliated store may operate the card store terminal 300 to issue a sales message not linked to an authorization message and send it to the card company server 400. In such cases, as shown by the sales message ID "B003" in FIG. 11, the authorization message ID is set to blank. When a sales message not linked to an authorization message is issued, it means that authorization processing has not been performed for that sale. Therefore, when a payment is made using a prepaid card, it is not always possible to reliably debit the second payment amount from the user's charge balance, which poses a financial risk (the risk of overdraft, described below) for the electronic payment service provider.
[0064] Returning to the explanation of FIG. 9, next, the payment server 100 sends a payment completion notice to the card company server 400 (S214). The payment completion notice includes the sales message ID and information indicating that the payment has been completed. The card company server 400 sends the payment completion notice to the card store terminal 300 (S215), and the card store terminal 300 sends a payment completion notice to the user terminal 200 (S216). Based on the payment completion notice received from the card store terminal 300, the user terminal 200 may display that the payment using the prepaid card has been completed. This allows the user to understand that the payment process has been completed.
[0065] In the above description, the prepaid card is a physical card, but this is not limiting. For example, the prepaid card of this embodiment may be a virtual prepaid card, which does not have a physical card. In the case of a virtual prepaid card, the user may use the user terminal device 200 to apply for an online purchase of a product by entering the prepaid card number, etc., on the affiliated store's website. The card information of the user's prepaid card (prepaid card number, expiration date, etc.) can be confirmed on the screen of the payment application 20. The details of the screen of the payment application 20 will be described later.
[0066] 9, it is also possible that the second payment amount at the time of sale at the affiliated store is lower than the first payment amount at the time of authorization. In such cases, the payment processing unit 130 calculates the refund amount by subtracting the second payment amount from the first payment amount and adds the refund amount to the user's electronic money balance. This allows appropriate payment processing even if the second payment amount at the time of sale at the affiliated store is lower than the first payment amount at the time of authorization.
[0067] Furthermore, in S212 of FIG. 9, if the user's electronic money balance is insufficient, the user may be unable to pay the additional amount to be collected. In this case, the payment processing unit 130 will additionally charge the user the shortfall amount. Specifically, if the additional amount to be collected is greater than the user's electronic money balance, the payment processing unit 130 charges the user the excess amount obtained by subtracting the electronic money balance from the additional amount to be collected, and resets the user's electronic money balance to zero. The information management unit 140 records the excess amount calculated by the payment processing unit 130 in the user information 172, linking it to the user's prepaid card information. This point will be explained below using a specific example.
[0068] For example, consider a case where the first payment amount at the time of authorization is 8,000 yen, the second payment amount at the time of sale at the affiliated store is 10,000 yen, and the user's electronic money balance is 9,000 yen. During authorization processing, the payment processing unit 130 determines that the prepaid card payment is approved because the first payment amount (8,000 yen) is less than the user's electronic money balance (9,000 yen), and subtracts the first payment amount (8,000 yen) from the user's electronic money balance (9,000 yen). As a result, the user's electronic money balance becomes 1,000 yen at the end of authorization processing.
[0069] Next, at the time of sales at the affiliated store, the payment processing unit 130 calculates the additional amount to be collected (2,000 yen) by subtracting the first payment amount (8,000 yen) from the second payment amount (10,000 yen). At this time, since the additional amount to be collected (2,000 yen) is more than the user's electronic money balance (1,000 yen), the payment processing unit 130 calculates the excess amount (1,000 yen) by subtracting the user's electronic money balance (1,000 yen) from the additional amount to be collected (2,000 yen). The payment processing unit 130 also bills the user for the excess amount (1,000 yen) and sets the user's electronic money balance (charge balance) to 0. This makes it possible to prevent missed billings even if the user's electronic money balance is insufficient.
[0070] The excess amount caused by the shortage of the electronic money balance can be resolved by the user by charging electronic money. Therefore, if the additional collected amount is greater than the electronic money balance (if an excess amount has occurred), the payment processing unit 130 notifies the user to charge electronic money for the excess amount. This point will be specifically explained using the screen of the payment application 20.
[0071] [Payment app screen] Fig. 12 is a diagram showing an example of the home screen of payment application 20. As shown in Fig. 12, the home screen of payment application 20 includes area A1, area A2, area A3, icon IC1, and button B1.
[0072] Area A1 displays card information (such as the prepaid card number and expiration date) of the prepaid card used for prepaid card payments. Users can understand the card information of the prepaid card by checking area A1 on the home screen.
[0073] Furthermore, if the user swipes area A1 left or right, the payment method of the electronic payment service can be switched to another payment method. For example, if the user swipes area A1 right, the payment app 20 switches to a payment method based on the electronic money balance. If the user swipes area A1 left, the payment app 20 switches to a payment method based on credit card payment. This allows the user to easily switch the payment method of the electronic payment service.
[0074] Area A2 displays icons for instructing the main operations in smartphone payments, such as scanning, remittance, points, usage history, and credit cards.
[0075] Area A3 displays various icons for launching various mini-apps that can be executed by payment app 20. Specifically, area A3 displays 12 icons. Of these icons, icon IC1 is an icon for launching a prepaid card mini-app. When the user selects (tap) icon IC1, payment app 20 launches the prepaid card mini-app. This makes it possible to display, for example, a card details screen showing details about the prepaid card, a payment history screen for prepaid card payments, etc. on display unit 220 of user terminal device 200.
[0076] Button B1 is a button for instructing the display of a payment screen. When the user selects (tap) button B1, the payment screen is displayed. The payment screen displays code information such as a barcode or QR code (registered trademark) used for smartphone payments. However, in S211 of FIG. 9 described above, if the additional amount to be collected is greater than the user's electronic money balance (i.e., if an excess amount has occurred), payment application 20 displays the payment screen shown in FIG. 12 on display unit 220 of user terminal device 200.
[0077] Fig. 13 is a diagram showing an example of a payment screen of payment application 20. For example, when the additional collected amount is greater than the electronic money balance and the user selects (tap) button B1 in Fig. 12, the payment screen shown in Fig. 13 is displayed on display unit 220 of user terminal device 200.
[0078] The payment screen displays code information such as a barcode or QR code (registered trademark) that is normally used for smartphone payments. However, if an excess amount has occurred, the user terminal device 200 does not display this code information on the payment screen, but instead displays the electronic money balance (0 yen) and the excess amount (1,000 yen). This prevents smartphone payments using code information from being made even if the user has an excess amount.
[0079] The payment screen also displays the message "Overage has occurred. Please charge the excess amount to resolve it. Once it is resolved, you will be able to use the remaining balance." along with button B2. When the user selects (tap) button B2, the electronic money charge screen is displayed. The user can charge electronic money from the charge screen.
[0080] When an excess amount occurs, the user is in a state where they have borrowed funds from the electronic payment service provider to make a transaction (a so-called overdraft). Therefore, when electronic money is charged to the user's electronic money balance, the payment processing unit 130 uses the charged electronic money preferentially to resolve the excess amount. By resolving the excess amount, code information such as a barcode or QR code (registered trademark) is displayed on the payment screen, and the user can make a smartphone payment using the code information.
[0081] Fig. 13 is a diagram showing an example of a payment completion screen of payment application 20. For example, when a prepaid card payment is made when the additional collected amount is greater than the electronic money balance, the payment completion screen shown in Fig. 13 is displayed on display unit 220 of user terminal device 200.
[0082] The payment completion screen normally displays the name of the store where the electronic payment was made, the payment amount, a message indicating that the payment has been completed, etc. However, if an overpayment has occurred, the user terminal device 200 will display the electronic money balance and the overpayment amount in addition to this information on the payment completion screen.
[0083] The payment completion screen also displays a message saying, "Your prepaid card has been overdrawn. You must top up your electronic money balance to pay the overdraft." along with button B3. When the user selects (tap) button B3, the electronic money top-up screen is displayed. The user can top up electronic money from the top-up screen.
[0084] In this way, when an excess amount has occurred, the user terminal device 200 displays a payment completion screen showing the excess amount on the display unit 220. This allows the user to easily understand that an excess amount has occurred.
[0085] [Creating blacklists and whitelists] As mentioned above, if an overdraft occurs, the user can cancel the overdraft by charging electronic money to their electronic money balance. However, while an overdraft occurs, the electronic payment service provider bears the financial risk for the user for the excess amount. Because the frequency and amount of overdrafts vary depending on the merchant's store and industry, electronic payment service providers must appropriately select merchants that allow the use of prepaid cards in order to reduce financial risk.
[0086] Against this background, the generation unit 160 generates list information that identifies, among one or more affiliated stores, affiliated stores that do or do not permit the use of the prepaid card, based on the authorization information 178 and the sales confirmation information 180. In this embodiment, the list information includes blacklist information 184 that identifies affiliated stores that do not permit the use of the prepaid card, and whitelist information 186 that identifies affiliated stores that do permit the use of the prepaid card, and the generation unit 160 generates the blacklist information 184 and the whitelist information 186 based on rule information 182 defined by the administrator of the payment server 100.
[0087] Thereafter, for example, when the payment processing unit 130 receives the first payment information in S204 of FIG. 9, it determines whether the affiliated store (identified by the affiliated store ID) included in the first payment information is included in the blacklist information 184. If it is determined that the affiliated store is included in the blacklist information 184, it denies the use of the prepaid card by the affiliated store (i.e., in this case, the authorization process is not performed in S205 of FIG. 9, and an error notification is returned to the card company server 400). On the other hand, if it is determined that the affiliated store included in the first payment information is not included in the blacklist information 184 or is included in the whitelist information 186, it approves the use of the prepaid card by the affiliated store (i.e., in this case, the process from S205 onward in FIG. 9 is performed). In other words, this reduces the financial risk associated with the occurrence of overdrafts. Below, the rule information 182, the blacklist information 184, and the whitelist information 186 are described in detail.
[0088] FIG. 14 is a diagram showing an example of rule information 182. As shown in FIG. 14, rule information 182 includes, for example, a rule type and its conditions. The rule type is information that identifies a blacklist or whitelist. The conditions are information for specifying the conditions for affiliated stores to which the blacklist or whitelist applies. Rule information 182 is specified in advance by the administrator of the electronic payment service, which is the issuer of the prepaid card.
[0089] As shown in FIG. 14 , in this embodiment, as an example, a blacklist condition includes that “the fee is less than the excess amount + the unauthorized sales amount within a predetermined period.” In this condition, the “predetermined period” refers to, for example, the period up to the last one year from the present time. The generation unit 160 can generate a blacklist or whitelist for data within a predetermined period by, for example, referencing the “authorization date and time” or “sales confirmation date and time” in the authorization information 178 and the sales confirmation information 180. The “fee” is information indicating the amount paid by a member store to an electronic payment service during a predetermined period. The fee is calculated, for example, by multiplying the “sales amount” stored in the second table 176B of the member store / store information 176 in FIG. 6 by a predetermined fee rate. The “excess amount” is information indicating the total excess amount incurred by the member store during a predetermined period. "Unauthorized sales amount" is information that indicates the total amount of payment amounts (secondary payment amount in Figure 11) that are listed in sales messages that are not linked to authorization messages generated at a merchant during a specified period. In other words, if the fee is less than the excess amount + unauthorized sales amount, it means that for the electronic payment service provider, the return (fee) obtained from the merchant is less than the risk (excess amount + unauthorized sales amount) of allowing the merchant to use the prepaid card.
[0090] As shown in the authorization information 178 in FIG. 10 and the sales confirmation information 180 in FIG. 11, the generation unit 160 calculates the excess amount + the sales amount without authorization for both credit cards and prepaid cards. For example, in the case of a credit card payment indicated by the combination of authorization message ID "A001" and sales message ID "B001," the generation unit 160 subtracts the first payment amount "1,400 yen" from the second payment amount "1,500 yen" to calculate an excess amount of 100 yen. Similarly, in the case of a prepaid card payment indicated by the combination of authorization message ID "A002" and sales message ID "B002," the generation unit 160 subtracts the first payment amount "500 yen" from the second payment amount "800 yen" to calculate an excess amount of 300 yen. Furthermore, in the case of prepaid card payment indicated by sales message ID "B003," the generation unit 160 calculates the second payment amount "1,000 yen" as the sales amount without authorization. As a result, for the affiliated store with affiliated store ID "13579," the generation unit 160 calculates the excess amount + sales amount without authorization as 100 yen + 300 yen + 1,000 yen = 1,400 yen for the above three data items.
[0091] In this way, the generation unit 160 adds up the excess amount and the unauthorized sales amount incurred for both credit cards and prepaid cards, and uses this total as the blacklist or whitelist determination target. Thus, according to this embodiment, by utilizing a wide range of data related to both credit cards and prepaid cards, it is possible to appropriately select affiliated stores that are permitted to use prepaid cards. Furthermore, even if an affiliated store has been registered in the blacklist information 184, credit card use is permitted, so when re-evaluation is conducted after a predetermined period, there is a possibility that the store may be removed from the blacklist information 184 based on data related to credit cards.
[0092] Furthermore, the blacklist criteria include "a merchant for which the number of messages in which the sales ID and authorization ID are not linked within a specified period exceeds a threshold." This can also be expressed as a merchant for which the number of records in which the "authorization message ID" is blank exceeds a threshold in the sales confirmation information 180 in FIG. 11, for example. Because such sales messages are received without executing the authorization process (i.e., without checking the user's electronic money balance), there is no guarantee that the payment amount can be debited from the user's electronic money balance, which poses a financial risk to the electronic payment service provider. Therefore, adding this criterion makes it possible to more appropriately select merchants that are permitted to use prepaid cards.
[0093] Furthermore, as shown in FIG. 14, in this embodiment, as an example, the whitelist conditions include "a merchant that uses an authorization that satisfies predetermined conditions within a predetermined period and for which the fee is equal to or greater than the excess amount plus the unauthorized sales amount." Here, the "predetermined conditions" refers to the authorization type being a small-amount authorization, a credit authorization, or a recurring authorization. As described above, in this embodiment, the payment processing unit 130 uniformly denies the use of prepaid cards that correspond to these authorization types. However, even if a merchant attempts such an authorization process, the payment processing unit 130 permits the use of a prepaid card for a merchant whose fee is equal to or greater than the excess amount plus the unauthorized sales amount (i.e., a merchant for which the return is greater than the risk for the electronic payment service provider).
[0094] FIG. 15 is a diagram showing an example of blacklist information 184. Blacklist information 184 includes, for example, an affiliated store ID, an affiliated store name, sales amount, a commission rate, a commission, and an excess amount + sales amount without authorization. In FIG. 15, for clarity of explanation, blacklist information 184 stores these information items, but it is sufficient if it includes at least the specific information of the affiliated store. As shown in FIG. 15, for the affiliated store with affiliated store ID "13579," the commission is sales amount × commission rate = 557420 × 1% = 5,574 yen, while the excess amount + sales amount without authorization is 8,700 yen. Therefore, the blacklist condition "commission is less than excess amount + sales amount without authorization within a specified period" is met, and the affiliated store is registered in blacklist information 184.
[0095] FIG. 16 is a diagram showing an example of whitelist information 186. Whitelist information 186 includes, for example, an affiliated store ID, an affiliated store name, sales amount, a commission rate, a commission, and an excess amount + sales amount without authorization. As shown in FIG. 16, for the affiliated store with affiliated store ID "98765," the affiliated store has performed credit authorization (see authorization information 178 in FIG. 10). However, the commission is 3,642 yen (sales amount × commission rate = 364,282 × 1%), while the excess amount + sales amount without authorization is 2,000 yen. Therefore, the whitelist condition "an affiliated store that uses an authorization that meets specified conditions within a specified period and whose commission is equal to or greater than the excess amount + sales amount without authorization" is met, and the affiliated store is registered in whitelist information 186.
[0096] 15 and 16, list information is generated for each affiliated store as an example. However, the present invention is not limited to such a configuration, and list information may be generated for each store, for example. More specifically, the generation unit 160 may tally the excess amount + sales amount without authorization for each store and compare the commission paid by each store with the excess amount + sales amount without authorization, or may identify stores where the number of messages not linked to a sales ID and an authorization ID exceeds a threshold. This configuration enables more precise selection of targets for which prepaid card usage is permitted.
[0097] As another example, the generation unit 160 may generate list information for a group of affiliated stores with the same business code. More specifically, the generation unit 160 may aggregate the excess amount + unauthorized sales amount for multiple affiliated stores with the same business code and compare the fees paid by the group of affiliated stores with the excess amount + unauthorized sales amount, or may identify a group of affiliated stores for which the number of messages not linked to a sales ID and an authorization ID is equal to or exceeds a threshold. Because affiliated stores that have experienced overdrafts or that issue authorization messages with authorization types that meet predetermined conditions tend to be similar in terms of business, this configuration allows for a unified decision on whether to permit or deny prepaid card use for affiliated stores in the same business category, preventing confusion for users.
[0098] 15 and 16 illustrate an example in which the list information is generated by comparing the fee with the excess amount plus the unauthorized sales amount. However, the present invention is not limited to such a configuration, and it is sufficient if the list information is generated by comparing at least the risk and return for the electronic payment service provider. For example, the generation unit 160 may compare the fee with either the excess amount or the unauthorized sales amount, or may compare the amount of the excess amount plus the unauthorized sales amount that the user did not repay (i.e., the amount of loss actually incurred by the electronic payment service provider) with the fee. Furthermore, for example, the generation unit 160 may compare the amount of the excess amount plus the unauthorized sales amount that the user did not repay within a predetermined period (e.g., within one week) after the occurrence of the overdraft with the fee. The excess amount plus the unauthorized sales amount and the loss amount are examples of the "determined amount taking into account the additional amount to be collected" in the claims.
[0099] [Processing flow] Fig. 17 is a flowchart showing an example of the flow of processing executed by the payment server 100. The processing shown in Fig. 17 is performed by the payment server 100 to determine whether or not to permit the use of a prepaid card at a certain affiliated store.
[0100] First, the payment server 100 receives first payment information related to the use of the prepaid card from the card company server 400 (step S300). Next, the payment server 100 determines whether the affiliated store linked to the first payment information is registered in the whitelist information 186 (step S302). If it is determined that the affiliated store linked to the first payment information is registered in the whitelist information 186, the payment server 100 permits the use of the prepaid card and executes authorization processing (step S304).
[0101] On the other hand, if it is determined that the affiliated store linked to the first payment information is not registered in the whitelist information 186, the payment server 100 next determines whether the affiliated store linked to the first payment information is registered in the blacklist information 184 (step S306). If it is determined that the affiliated store linked to the first payment information is registered in the blacklist information 184, the payment server 100 notifies the card company server 400 that use of the prepaid card is not permitted (step S308). This ends the processing of this flowchart.
[0102] In the above flowchart, as an example, the payment server 100 determines whether the affiliated store is registered in each of the whitelist information 186 and the blacklist information 184. However, the present invention is not limited to such a configuration, and the payment server 100 may determine only whether the affiliated store is registered in the blacklist information 184, and if it is determined that the affiliated store is not registered in the blacklist information 184, may permit the use of the prepaid card.
[0103] [Prepaid card payment overview (Example 2)] FIG. 18 is a diagram showing a second example of an outline of prepaid card payments. In the example shown in FIG. 8 above, an on-us transaction is performed in which the prepaid card issuer (issuer) and the affiliated store contract company (acquirer) are the same company. On the other hand, in the example shown in FIG. 18, an on-us transaction is not performed. For example, FIG. 18 shows an example in which a card company operating card company server 400 enters into a contract with an international brand credit card company, thereby enabling prepaid card payments at stores affiliated with the international brand credit card company. In FIG. 18, the prepaid card issuer (issuer) and the affiliated store contract company (acquirer) are different, so there is an affiliated store contract company (acquirer) between the affiliated store and the card company.
[0104] Therefore, the card store terminal device 300 does not send the payment information directly to the card company server 400, but instead sends the payment information to the card company server 400 via the acquirer server 500 operated by the acquirer (S303, S304).
[0105] Furthermore, the card company server 400 does not pay the payment amount directly to the affiliated store, but instead pays the payment amount via the acquirer (S308, S309). For example, the card company server 400 may transfer the payment amount to the acquirer's bank account. Alternatively, the acquirer server 500 may transfer the payment amount to the affiliated store's bank account. This allows the affiliated store to receive the payment amount corresponding to the user's purchase of a product (or use of a service).
[0106] Note that S301 and S302 in Fig. 18 are the same as S101 and S102 in Fig. 8, S306 and S307 in Fig. 18 are the same as S105 and S106 in Fig. 8, and S310 and S311 in Fig. 18 are the same as S108 and S109 in Fig. 8. Therefore, detailed explanation of these processes will be omitted.
[0107] According to the embodiment described above, the payment server 100 includes an acquisition unit 150 and a generation unit 160. The acquisition unit 150 acquires a history of at least credit card payments made at one or more affiliated stores of the electronic payment service. Based on the payment history, the generation unit 160 generates list information that identifies, among the one or more affiliated stores, those affiliated stores that do or do not permit the use of a prepaid card that processes payments using the electronic money balance of the electronic payment service that the user has charged. This makes it possible to appropriately select affiliated stores that permit the use of the prepaid card.
[0108] In the above description, the payment server 100 is described as an example of a payment processing device, and the payment server 100 and the card company server 400 are separate servers, but this is not limiting. For example, if the electronic payment service provider and the card company are the same company or a group of companies, a single server that integrates the payment server 100 and the card company server 400 may be provided as the payment processing device.
[0109] In the above embodiment, the payment server 100 generates the list information (blacklist information 184, whitelist information 186) and makes a determination using the list information. However, the present invention is not limited to this. For example, in a configuration where the payment server 100 and the card company server 400 are separated, the card company server 400 may make the determination.
[0110] In this case, the card company server 400 may make the determination based on the list information provided by the payment server 100. Alternatively, the card company server 400 may generate list information itself using a function similar to that of the generation unit 160 of the payment server 100 based on the authorization information 178 and sales confirmation information 180 (payment history) received from the card store terminal device 300, and make the determination using the list information. In either case, the card company server 400 transmits the first payment information to the payment server 100 (S204) only if it determines that the affiliated store included in the first payment information is authorized to use the prepaid card. If it determines that the use is not authorized, it may return a response denying the authorization at that time. This configuration reduces the processing load on the payment server 100 and increases the flexibility of the overall system design.
[0111] The above describes the form for carrying out the present invention using an embodiment, but the present invention is not limited to such an embodiment, and various modifications and substitutions can be made within the scope that does not deviate from the gist of the present invention. [Explanation of symbols]
[0112] 20. Payment App 50 First store terminal device 100 Payment Server 110 Communications Department 120 Payment Contents Department 130 Payment processing unit 140 Information Management Department 150 Acquisition Department 160 Generation part 170 Storage section 172 User information 178 Authorization Information 180 Sales Confirmation Information 182 Rules Information 184 Blacklist Information 186 Whitelist Information 200 User terminal device 210 Communications Department 220 Display section 230 Input section 240 Control Unit 250 Storage section 300 Card store terminal device 400 Card company server 500 Acquirer Server
Claims
1. an acquisition unit that acquires at least a credit card transaction history executed at one or more credit card member stores; a generating unit that generates list information that identifies, among the one or more affiliated stores, affiliated stores that are permitted or not permitted to use a prepaid card that performs payment processing using the electronic money balance of an electronic payment service that has been charged by the user, based on the payment history; The payment history includes, for payments using the credit card executed at the affiliated store, a first payment amount which is a payment amount at the time of authorization and a second payment amount which is a payment amount at the time of sale; the generating unit generates the list information based on a magnitude relationship between a determined amount taking into consideration an additional collection amount obtained by subtracting the first payment amount from the second payment amount and a payment amount to be paid by the affiliated store to the electronic payment service. Information processing device.
2. The acquisition unit further acquires a payment history of the prepaid card, The payment history includes, for payments using the credit card and the prepaid card executed at the affiliated store, a first payment amount which is the payment amount at the time of authorization and a second payment amount which is the payment amount at the time of sale; the generating unit generates the list information based on a magnitude relationship between a determined amount taking into consideration an additional collection amount obtained by subtracting the first payment amount from the second payment amount and a payment amount to be paid by the affiliated store to the electronic payment service. The information processing device according to claim 1 .
3. the list information includes a blacklist that identifies affiliated stores that do not permit the use of the prepaid card; The generation unit includes in the blacklist, among the one or more affiliated stores, an affiliated store whose determination amount is greater than the payment amount. The information processing device according to claim 1 .
4. The determination amount is the total amount of the additional collection amount and the sales amount of sales not linked to the authorization. The information processing device according to claim 3 .
5. the generation unit includes, in the blacklist, an affiliated store among the one or more affiliated stores, the affiliated store having a number of sales not linked to the authorization equal to or greater than a threshold; The information processing device according to claim 3 .
6. the list information includes a whitelist that identifies affiliated stores that permit the use of the prepaid card; The generation unit includes in the whitelist, among the one or more affiliated stores, an affiliated store whose authorization type satisfies a predetermined condition and whose determination amount is smaller than the payment amount. The information processing device according to claim 3 .
7. The computer Acquire at least a credit card transaction history executed at one or more credit card member stores; Based on the payment history, generate list information that identifies, among the one or more affiliated stores, affiliated stores that are permitted or not permitted to use a prepaid card that performs payment processing using the electronic money balance of the electronic payment service charged by the user; The payment history includes, for payments using the credit card executed at the affiliated store, a first payment amount which is a payment amount at the time of authorization and a second payment amount which is a payment amount at the time of sale; The generating step generates the list information based on a magnitude relationship between a determined amount that takes into account an additional collection amount obtained by subtracting the first payment amount from the second payment amount and a payment amount that the affiliated store pays to the electronic payment service. Information processing methods.
8. On the computer, Acquire at least a credit card transaction history executed at one or more credit card member stores; Based on the payment history, generate list information that identifies, among the one or more affiliated stores, affiliated stores that are permitted or not permitted to use a prepaid card that performs payment processing using the electronic money balance of the electronic payment service charged by the user; The payment history includes, for payments using the credit card executed at the affiliated store, a first payment amount which is a payment amount at the time of authorization and a second payment amount which is a payment amount at the time of sale; The generating step generates the list information based on a magnitude relationship between a determined amount that takes into account an additional collection amount obtained by subtracting the first payment amount from the second payment amount and a payment amount that the affiliated store pays to the electronic payment service. program.
Citation Information
Patent Citations
Information processing apparatus, information processing method, and program
JP2024041303A
Payment processing device, payment processing system, payment processing method, and program
JP7654876B1
Method and system for processing declined transactions
US20200027087A1
Payment management device, payment management method, and program
JP7311726B1
JPP7654876B
Cited By
Payment method, wallet system and storage medium
CN121391255A