Information processing method, information processing device, and program

Abstract

To improve user convenience regarding notifications about the use of payment methods. [Solution] The computer performs the following actions: acquires at least one transaction information obtained through the use of a payment medium; extracts at least one transaction information that satisfies notification conditions from the acquired at least one transaction information; and transmits a transaction notification regarding the extracted at least one transaction information, indicating that a transaction has occurred using a payment medium, to an information processing device associated with the payment medium.

Description

[Technical Field]

[0001] The present invention relates to an information processing method, an information processing apparatus, and a program. [Background Art]

[0002] Conventionally, a procedure called authorization has been known in transactions using payment media such as credit cards. This authorization is performed when a transaction using a credit card occurs, to confirm whether the card is valid and the transaction amount is within the available credit limit. For example, Patent Literature 1 discloses a system in which, when the use of a credit card as a payment medium is subject to authorization processing, an issuer-side system that acquires a message generated in accordance with the use from a member store performs predetermined authorization processing based on the message. [Prior Art Literature] [Patent Literature]

[0003] [Patent Literature 1] Japanese Unexamined Patent Publication No. 2020-042610 [Summary of the Invention] [Problem to be Solved by the Invention]

[0004] In the system disclosed in Patent Literature 1, when authorization processing is performed, information about the processing is notified to the user in real time, which allows the user to confirm information such as the use date and time and the amount of the payment medium in real time. However, since not all uses of the payment medium are subject to authorization processing, there has been an aspect where the system cannot fully meet users' needs such as a desire to grasp information about uses that are not subject to authorization processing.

[0005] Accordingly, an object of the present invention is to improve user convenience for notifications related to the use of a payment medium. [Means for Solving the Problem]

[0006] An information processing method according to one aspect of the present invention involves a computer performing the following actions: acquiring at least one transaction information obtained through the use of a payment medium; extracting at least one transaction information that satisfies notification conditions from the acquired at least one transaction information; and transmitting a transaction notification relating to the extracted at least one transaction information, which indicates that a transaction has occurred through the use of a payment medium, to an information processing device associated with the payment medium. [Effects of the Invention]

[0007] This invention makes it possible to improve user convenience regarding notifications about the use of payment media. [Brief explanation of the drawing]

[0008] [Figure 1] This is a schematic block diagram showing the system configuration of the payment system 100 according to this embodiment. [Figure 2] This is a schematic diagram showing an example of the hardware configuration of the computer 200 according to this embodiment. [Figure 3] This is a schematic diagram showing an example of the functional configuration of the management device 30 according to this embodiment. [Figure 4] This is a schematic diagram showing an example of the data structure of the transaction information table according to this embodiment. [Figure 5] This is a schematic diagram showing an example of the sequence of operations performed by the payment system 100 according to this embodiment. [Figure 6] This is a schematic diagram showing an example of a display screen for a non-authorization notification according to this embodiment. [Modes for carrying out the invention]

[0009] Embodiments of the present invention will be described below with reference to the drawings. To facilitate understanding of the description, the same reference numerals are used for identical components in each drawing whenever possible, and redundant explanations are omitted.

[0010] Figure 1 is a schematic block diagram showing the system configuration of the payment system 100 according to this embodiment. The payment system 100 comprises a merchant system 10, a user terminal 20, and a management device 30. The merchant system 10, the user terminal 20, and the management device 30 may each include one or more computers.

[0011] The payment system 100 enables payment using one or more types of payment schemes. In the payment schemes used in the payment system 100, transactions are conducted using a payment medium issued to the user. For example, if a deferred payment medium is used, payment processing using the payment medium is performed first, and then payment is made according to the payment medium. At the time of payment, a physical medium carried by the user (hereinafter referred to as "user medium") is used. In addition, information issued in association with the payment medium (hereinafter referred to as "medium information") is used at the time of payment and settlement. For example, if the payment medium is a credit card, the medium information is the actual card number (e.g., Funding Primary Account Number: FPAN), and the user medium may be a card medium such as a plastic card on which the actual credit card number is recorded, or an information device such as a smartphone on which a token corresponding to the actual card number is recorded may be used.

[0012] The payment scheme implemented in the payment system 100 according to this embodiment is not limited to those described above. For example, a payment scheme using electronic value or a debit card payment scheme may be used.

[0013] The merchant-side system 10 is configured to communicate with other devices such as user terminals 20 and management devices 30 via network N. Network N is a wide-area communication network such as the Internet, and may use either wireless or wired communication. It is also possible for multiple networks to be combined to form the network.

[0014] The merchant-side system 10 is a system used by merchants (hereinafter referred to as "merchants") that can accept payments from users using payment media based on the payment scheme. The payment system 100 may have multiple merchant-side systems 10. The merchant-side system 10 may be used, for example, by a store that has a contract with an acquirer associated with the payment system 100. The merchant-side system 10 generates transaction information based on the payment by accepting payments from users via payment media.

[0015] The merchant system 10 may accept credit card payments by, for example, reading a physical credit card or media information (such as a card number or token) stored on a smartphone. The reading of media information may be performed, for example, by a card reader installed in the physical store, or by a reader that communicates with an in-vehicle unit when passing through an ETC lane. Alternatively, the merchant system 10 may, for example, accept registration of media information from users in advance, and then generate transaction information on a specified date based on the pre-registered media information and process the payment.

[0016] The merchant system 10 transmits an authorization request along with the transaction information to the management device 30 for transactions subject to authorization processing. The authorization request is information used to confirm whether credit card payment processing is possible, and is used, for example, to determine whether the payment amount is within the available credit limit or whether the card is being used by the legitimate owner. The merchant system 10 may, for example, determine whether a transaction is subject to authorization processing by determining whether it meets predetermined conditions when it accepts the use of a credit card. These predetermined conditions may be obtained from a storage unit accessible to the merchant system 10. Alternatively, the merchant system 10 may, for example, assume that virtually all transactions are subject to authorization processing when it accepts the use of a credit card and transmit an authorization request to the management device 30.

[0017] FIG. 2 is a schematic diagram showing an example of the hardware configuration of a computer 200 according to the present embodiment. The member store-side system 10, user terminal 20, and management device 30 according to the present embodiment may each be configured to include one or more computers 200. As shown in FIG. 2, the computer 200 includes a processor 201, a storage device 202, an input I / F 203, a data I / F 204, a communication I / F 205, and a display device 206.

[0018] The processor 201 controls various processes in the computer 200 by executing programs stored in the storage device 202. For example, each functional unit included in the control unit 31 of the management device 30 can be implemented by the processor 201 executing a program stored in the storage device 202.

[0019] The storage device 202 is, for example, a storage medium such as RAM (Random Access Memory). The RAM temporarily stores program codes of programs executed by the processor 201 and data required when the programs are executed.

[0020] The storage device 202 may be, for example, a non-volatile storage medium such as a hard disk drive (HDD) or a flash memory. The storage device 202 stores an operating system and various programs for implementing each of the above configurations. The storage medium storing the various programs may be a non-transitory computer readable medium. In addition, the storage device 202 can also store a table for registering various types of information and a DB for managing the table. Such programs and data are referenced by the processor 201 by being loaded into the storage device 202 as needed.

[0021] The input I / F 203 is a device for accepting input from a user. Specific examples of the input I / F 203 include a camera, buttons, a microphone, a keyboard, a mouse, a touch panel, various sensors, and a wearable device. The input I / F 203 may be connected to the computer 200 via an interface such as USB (Universal Serial Bus).

[0022] The data I / F 204 is a device for inputting data from outside the computer 200. Specific examples of the data I / F 204 include a drive device for reading data stored in various storage media. It is also conceivable that the data I / F 204 is provided outside the computer 200. In this case, the data I / F 204 is connected to the computer 200 via an interface such as USB.

[0023] The communication I / F 205 is a device for performing data communication via the communication network N10 with an external device of the computer 200 by wire or wireless. It is also conceivable that the communication I / F 205 is provided outside the computer 200. In this case, the communication I / F 205 is connected to the computer 200 via an interface such as USB.

[0024] The display device 206 is a device for displaying various types of information. Specific examples of the display device 206 include a liquid crystal display, an organic EL (Electro-Luminescence) display, and a display of a wearable device. The display device 206 may be provided outside the computer 200. In this case, the display device 206 is connected to the computer 200 via, for example, a display cable. Furthermore, when a touch panel is employed as the input I / F 203, the display device 206 can be configured integrally with the input I / F 203.

[0025] The components of the device included in the information processing system 10 of the above embodiment may be such that a program stored in the storage device 202 is executed by the processor 201, thereby realizing a defined process in cooperation with other hardware. In other words, these components are conceived as software or firmware, and also as corresponding hardware. Furthermore, these components are also described and interpreted as "function," "means," "part," "processing circuit," "unit," or "module" in both of these concepts.

[0026] Figure 3 is a schematic diagram showing an example of the functional configuration of the management device 30 according to this embodiment. The management device 30 is configured using, for example, one or more computers. The management device 30 comprises a control unit 31 and a transaction information storage unit 32.

[0027] The transaction information storage unit 32 is comprised of the storage device 202 and stores a history of information regarding payment transactions made using a payment medium in the settlement system 100. For example, the transaction information storage unit 32 stores a transaction information table, which will be described later.

[0028] The control unit 31 includes, as functional units, an authorization processing unit 311, a transaction information management unit 312, a transaction information extraction unit 313, and a non-authorization notification processing unit 314. These functional units can be implemented, for example, by the processor 201 executing a program stored in the storage device 202 in the management device 30.

[0029] The authorization processing unit 311 performs authorization-related processing. For example, the authorization processing unit 311 performs authorization processing based on an authorization request received from the merchant system 10. The authorization processing may include, for example, a determination of whether payment is possible. In this determination process, the authorization processing unit 311 may determine the validity of the information (card number, expiration date, security code, etc.) included in the authorization request by comparing it with predetermined reference information. The authorization processing may also include, for example, a determination of whether the transaction amount is within the limit. In this determination process, the authorization processing unit 311 may determine, for example, whether the transaction amount included in the authorization request is within a predetermined limit. If the authorization processing results in no problems being found with respect to the transaction, the authorization processing unit 311 generates an "approved" (payment possible) response and sends it to the merchant system 10. On the other hand, if a problem is found, the authorization processing unit 311 returns a "rejected" (payment impossible) response and adds an error code and reason for rejection as necessary. Furthermore, the authorization processing unit 311 may transmit the result of the authorization process to the user terminal 20. This allows the user to check the status of payment approval or rejection in real time. The authorization processing unit 311 may also determine, for example, whether a transaction is subject to authorization processing based on the transaction information included in the authorization request obtained from the merchant system 10. This determination process may include, for example, determining whether the transaction information included in the authorization request meets predetermined conditions.

[0030] The transaction information management unit 312 manages the transaction information table stored in the transaction information storage unit 32. Figure 4 is a schematic diagram showing an example of the data structure of the transaction information table according to this embodiment. Each row (record) included in the transaction information table is an example of transaction information. The transaction information includes information about a single payment transaction made using a payment medium such as a credit card.

[0031] The transaction information table includes the following items: "Transaction ID," "Transaction Date," "Transaction Amount," "Card Number," "Merchant ID," "Payment Scheme," "Brand," and "Authorization-Related Information."

[0032] The "Transaction ID" is a unique identifier used to identify each transaction. The "Transaction Date" indicates the date and time the payment was made for that transaction. The "Transaction Amount" represents the amount paid for each transaction. The "Card Number" is the number of the credit card or other payment method used in the transaction. The transaction information table may also include other identifiers to identify the payment medium, depending on the payment scheme.

[0033] "Merchant ID" is information that identifies a merchant that accepts payments using a payment medium. "Payment Scheme" is information that indicates which payment scheme is used for the transaction, and may include, for example, credit card, electronic money (prepaid), post-pay, etc. The value that "Payment Scheme" takes may be a classification set by the acquirer or a classification set by the issuer. "Brand" indicates the brand of the payment medium used, such as a credit card, and may include VISA, Mastercard, etc.

[0034] "Authorization-related information" refers to information regarding the authorization of the transaction in question. This information includes, for example, whether the transaction is subject to authorization processing, whether it is subject to authorization notification, whether authorization processing has been performed, the result of the authorization processing, and the authorization number based on that result. The "authorization number" is a number assigned by the issuer (card issuing company) when payment is authorized using a card, and is one of the payment identification numbers in cashless payments.

[0035] Refer to Figure 2 again. The transaction information extraction unit 313 extracts at least one transaction information from the transaction information table that satisfies predetermined conditions (non-authorization notification conditions) for extracting transaction information subject to non-authorization notification at a predetermined timing. Here, non-authorization notification is a transaction notification concerning the extracted at least one transaction information, and is an example of a transaction notification indicating that a transaction has occurred using a settlement medium. The non-authorization notification processing unit 314 also sends a non-authorization notification to the user terminal 20 for the extracted transaction information. The timing of extracting transaction information subject to non-authorization notification and sending the non-authorization notification can be set arbitrarily, but may be, for example, when a periodic deadline arrives (weekly, monthly, every few months, etc.).

[0036] Non-authorization notification conditions may include conditions related to the "transaction date," specifically, for example, "the transaction date falls within a specified period" or "the transaction date is a specific date," meaning that the transaction date must fall within a specified period or coincide with a specific date. This makes it possible to specify whether or not to send a non-authorization notification depending on the value of the "transaction date." In particular, when the scope of authorization notifications is defined by the "transaction date," defining the non-authorization notification conditions by the "transaction date" makes it possible to efficiently send non-authorization notifications for transactions that are not subject to authorization notifications.

[0037] Non-authorization notification conditions may include conditions related to the "transaction amount," specifically, for example, "the transaction amount is less than a predetermined amount (e.g., 5,000 yen)" or "the transaction amount is 10,000 yen or more," meaning that the transaction amount must be above or below a predetermined threshold. This makes it possible to specify whether or not to send a non-authorization notification depending on the value of the "transaction amount." In particular, when the scope of authorization notifications is defined by the "transaction amount," defining the non-authorization notification conditions by the "transaction amount" makes it possible to efficiently send non-authorization notifications for transactions that are not subject to authorization notifications.

[0038] Non-authorization notification conditions may include conditions related to the "card number," specifically, for example, "the card number is a specific value (e.g., XXXX-XXXX-XXXX-1234)," meaning that the card number must take a predetermined value. This makes it possible to specify whether or not to send a non-authorization notification depending on the value of the "card number." In particular, when the scope of authorization notifications is defined by the "card number," defining the non-authorization notification conditions by the "card number" makes it possible to efficiently send non-authorization notifications for transactions that are not subject to authorization notifications.

[0039] Non-authorization notification conditions may include conditions related to the "Merchant ID," specifically, for example, "the Merchant ID is a specific store (e.g., Store A)," meaning that the trading partner's merchant must be a designated merchant. This makes it possible to specify whether or not to send a non-authorization notification depending on the value of the "Merchant ID." In particular, when the target of authorization notifications is defined by the "Merchant ID," defining the non-authorization notification conditions by the "Merchant ID" makes it possible to efficiently send non-authorization notifications for transactions that are not subject to authorization notifications.

[0040] The non-authorization notification conditions may include conditions relating to the "payment scheme," specifically, for example, whether the "payment scheme" is a credit card, electronic money (prepaid), or post-pay. This makes it possible to specify whether to send a non-authorization notification depending on the value of the "payment scheme." In particular, when the scope of authorization notifications is defined by the "payment scheme," defining the non-authorization notification conditions by the "payment scheme" makes it possible to efficiently send non-authorization notifications for transactions that are not subject to authorization notifications.

[0041] Non-authorization notification conditions may include conditions related to "brand," specifically, for example, "the brand is XX," meaning that the brand of the credit card used in the transaction must be a specified brand. This makes it possible to specify whether or not to send a non-authorization notification depending on the value of "brand." In particular, when the scope of authorization notifications is defined by "brand," defining the non-authorization notification conditions by "brand" makes it possible to efficiently send non-authorization notifications for transactions that are not subject to authorization notifications.

[0042] Non-authorization notification conditions may include conditions related to "authorization-related information," specifically, conditions can be set based on the authorization-related information indicating a specific state, such as "extract only transactions that have been successfully authorized" or "transactions that do not require authorization." Authorization-related information may include information related to payment authorization, such as whether a transaction is subject to authorization processing, whether authorization processing has been performed, the result, and the authorization number assigned based on that result. The authorization number is a number issued by the issuer (card issuing company) when a payment using a card is authorized, and is one of the payment identification numbers in cashless payments. This makes it possible to specify whether to send a non-authorization notification depending on the value of "authorization-related information," enabling efficient and direct non-authorization notifications for transactions that are not subject to authorization notification.

[0043] In this way, by setting arbitrary conditions, it becomes possible to perform detailed filtering of transaction information. In particular, by setting conditions for transactions that are not subject to authorization processing, notifications can be sent for those transactions. For example, it becomes possible to extract "transactions that do not require authorization and are below a certain amount" and process them under specific management. This enables flexible operation of the settlement system and efficient management based on specific conditions.

[0044] In non-authorization notification conditions, the above-mentioned conditions can be used individually, or multiple conditions can be combined using logical AND or OR operators to define complex conditions. This allows for the narrowing down of specific transaction patterns.

[0045] Specific examples of such complex conditions are shown below. Example 1: "The transaction amount is less than a specified amount" AND "The settlement scheme is of a specified value" Example 2: "The transaction amount is less than a specified amount" AND "The brand is of a specified value"

[0046] Figure 4 is a schematic diagram showing an example of the sequence of operations performed by the payment system 100 according to this embodiment.

[0047] (S1-1) The merchant system 10 accepts the use of payment media at predetermined times. For example, when a user presents payment media at a store or passes through an ETC (Electronic Toll Collection) system, the merchant system 10 accepts the use of the payment media, such as a credit card or ETC card, by reading it with a reader. Alternatively, if the payment media information has been registered in advance (registration type), the merchant system 10 accepts the use of the payment media when a predetermined date arrives. As a result, the merchant system 10 generates transaction information.

[0048] If the usage accepted in step S1-1 is subject to authorization processing, then, for example, the following processes S2-1 to S2-4 will be executed.

[0049] (S2-1) When the merchant system 10 accepts the use of a payment medium, it generates an authorization request for transactions that are subject to authorization processing. The authorization request may include transaction information necessary for authorization processing, such as the card number, transaction amount, and transaction date and time. The merchant system 10 may, for example, determine whether a transaction is subject to authorization processing by determining whether it satisfies predetermined conditions when it accepts the use of a payment medium. These predetermined conditions may be obtained from a storage unit accessible to the merchant system 10. Alternatively, the merchant system 10 may, for example, assume that basically all transactions are subject to authorization processing when it accepts the use of a payment medium and send an authorization request to the management device 30.

[0050] (S2-2) The management device 30 performs authorization processing based on authorization requests sent from the merchant system 10. The management device 30 may, for example, determine the validity of information (card number, expiration date, security code, etc.) included in the authorization request by comparing it with predetermined reference information. The management device 30 may also include, for example, determining whether the transaction amount is within a predetermined limit. If the management device 30 does not find any problems with the transaction as a result of the authorization processing, it generates information indicating "approved" (payment possible) as the result of the authorization processing. On the other hand, if the management device 30 finds a problem, it generates information indicating "rejected" (payment impossible) as the result of the authorization processing. The management device 30 may add predetermined codes (codes related to approval and codes related to rejection) and reasons for approval or rejection to the result of the authorization processing.

[0051] (S2-3) The management device 30 notifies the merchant system 10 of the result of the authorization process. The merchant system 10 may determine the content of the transaction based on the result of the authorization process. If the result of the authorization process is "approved" (payment possible), the merchant system 10 may execute the process to proceed with the transaction. On the other hand, if the result of the authorization process is "rejected" (payment impossible), the merchant system 10 executes a predetermined error process. In this case, the merchant system 10 may send an error notification to the user terminal 20.

[0052] (S2-4) The management device 30 sends an authorization notification to the user terminal 20. The authorization notification may include information indicating, for example, that a payment medium has been used. The authorization notification may also include the results of the authorization process, such as whether the transaction was approved or not, and the reason if approval was not obtained. This allows the user to check the progress of the transaction in real time. Depending on the type of transaction, the management device 30 may notify the merchant system 10 of the results of the authorization process, but it is not necessary to notify the user terminal 20 (authorization notification). Furthermore, the user may be able to select which users receive authorization notifications.

[0053] (S3-1) The merchant system 10 generates transaction information based on the use of the accepted payment medium at a predetermined timing after step S1-1 or S2-5. The information included in the transaction information may include, for example, at least some of the items included in the transaction information table described above. Specifically, the transaction information may include transaction ID, transaction date, transaction amount, card number, merchant ID, payment scheme, brand, and authorization-related information.

[0054] (S3-2) The merchant system 10 transmits the transaction information generated in step S3-1 to the management device 30. If the transaction information pertains to a transaction subject to authorization processing, the merchant system 10 may transmit the information after, for example, receiving the result of the authorization processing in step S2-3. If the transaction information pertains to a transaction not subject to authorization processing, the merchant system 10 transmits the generated transaction information to the management device 30 after, for example, accepting the use of the payment medium in step S1-1 and after a predetermined lead time has elapsed. The length of this lead time may be set arbitrarily and may be several hours, several days, several weeks, etc. Alternatively, the lead time may be until a predetermined periodic closing date (date and time) arrives.

[0055] (S3-3) The management device 30 stores the received transaction information in the transaction information table of the transaction information storage unit 32. In this way, steps S1-1 to S3-3 (however, steps S2-1 to S2-5 are limited to transactions subject to authorization processing) are executed each time a settlement medium is used. As a result, transaction information for each use of the settlement medium is accumulated in the transaction information table stored in the transaction information storage unit 32 of the management device 30.

[0056] (S4-1) The management device 30 extracts transaction information that satisfies the non-authorization notification conditions from the transaction information stored in the transaction information storage unit 32 at a predetermined timing. This predetermined timing can be set arbitrarily, but may be, for example, at the arrival of periodic expiration dates (weekly, monthly, every few months, etc.).

[0057] (S4-2) The management device 30 generates a non-authorization notification for at least one of the extracted transaction information and sends it to the user terminal 20.

[0058] (S4-3) The user terminal 20 displays the non-authorization notification received from the management device 30. This display allows the user to check the completion status and results of transactions that have not undergone authorization, and to check the transaction details as needed.

[0059] Figure 5 is a schematic diagram showing an example of a display screen for a non-authorization notification according to this embodiment. Figure 5 shows screen 500 as an example of the display screen. Screen 500 includes the text "...Transaction information has been registered, so we would like to inform you" as information indicating that a transaction has occurred using a credit card. Note that the content of this text is just an example, and the content, format, and style are not particularly limited as long as it indicates that a transaction has occurred using a credit card. This makes it possible for users to understand the transactions that are subject to non-authorization notifications.

[0060] Screen 500 includes the text, "Regarding transactions for which an immediate usage notification was not delivered at the time of use..." This text is an example of information indicating that the credit card usage notified by Screen 500 is not subject to authorization processing. Thus, Screen 500 may include information indicating that the credit card usage related to the notification is not subject to authorization processing. The content of this text is just an example, and there are no particular limitations on the content, format, or style of the text, as long as it indicates that the credit card usage related to the notification is not subject to authorization processing. This allows users to understand that transactions subject to non-authorization notifications are not subject to authorization processing. The purpose is to improve user convenience regarding notifications about credit card usage.

[0061] Screen 500 contains transaction information for at least one use. Specifically, Screen 500 shows the transaction information for four transactions, from Use 1 to Use 4, including the date and time of use (transaction date and time), the amount used (transaction amount), and the merchant where the transaction took place. Note that the number of transactions shown in the transaction information included in Screen 500 is not limited to four; it can be any number of transactions extracted in step S4-1 described above. Also, the items of the transaction information displayed are not limited to those shown in the diagram; other arbitrary items may be included.

[0062] While embodiments of this invention have been described in detail above with reference to the drawings, the specific configuration is not limited to these embodiments and includes designs and the like that do not depart from the spirit of this invention. [Explanation of symbols]

[0063] 100...Payment system, 10...Merchant-side system, 20...User terminal, 30...Management device, 200...Computer, 201...Processor, 202...Storage device, 203...Input I / F, 204...Data I / F, 205...Communication I / F, 206...Display device, 31...Control unit, 32...Transaction information storage unit, 311...Authorization processing unit, 312...Transaction information management unit, 313...Transaction information extraction unit, 314...Non-authorization notification processing unit

Claims

1. Computers Obtaining at least one transaction information through the use of a payment medium, Extracting at least one transaction from the acquired transaction information that satisfies the notification conditions, A transaction notification relating to the extracted at least one transaction information, indicating that a transaction has occurred using the payment medium, is transmitted to an information processing device associated with the payment medium. An information processing method that performs the following.

2. The information processing method according to claim 1, wherein the notification conditions include at least one of the following: conditions relating to the transaction amount, conditions relating to the merchant, conditions relating to the payment scheme, and conditions relating to the brand of the payment medium.

3. The conditions relating to the transaction amount include the transaction amount being equal to or less than a predetermined threshold, The conditions relating to the aforementioned member store include the fact that the member store is a designated member store. The conditions relating to the aforementioned settlement scheme include the fact that the settlement scheme is a specified settlement scheme, The information processing method according to claim 2, wherein the condition relating to the brand of the payment medium includes that the brand of the payment medium is a predetermined brand.

4. The information processing method according to claim 1, wherein the notification conditions include conditions relating to authorization processing for the use of the payment medium.

5. The information processing method according to claim 4, wherein the conditions for authorization processing regarding the use of the payment medium include at least one of the following: the use of the payment medium is not subject to authorization processing, and no notification regarding authorization processing has been sent.

6. The information processing method according to claim 1, wherein the transaction notification includes information indicating that an immediate notification regarding the use of the payment medium has not been sent.

7. The information processing method according to claim 6, wherein the immediate notification is a notification relating to authorization processing for the use of the payment medium.

8. An acquisition unit that acquires at least one transaction information through the use of a payment medium, An extraction unit that extracts at least one transaction information that satisfies the notification conditions from the acquired at least one transaction information, A notification unit that transmits a transaction notification relating to at least one extracted transaction information, indicating that a transaction has occurred using the payment medium, to an information processing device associated with the payment medium, An information processing device equipped with the following features.

9. On the computer, Obtaining at least one transaction information through the use of a payment medium, Extracting at least one transaction from the acquired transaction information that satisfies the notification conditions, A transaction notification relating to the extracted at least one transaction information, indicating that a transaction has occurred using the payment medium, is transmitted to an information processing device associated with the payment medium. A program to execute.

Images