NL2028777B1

NL2028777B1 - System for and method of providing a payment service

Info

Publication number: NL2028777B1
Application number: NL2028777A
Authority: NL
Inventors: Niknam Ali
Original assignee: Bunq B V
Priority date: 2021-07-19
Filing date: 2021-07-19
Publication date: 2023-01-25

Abstract

A method for providing a payment service by a payment server, the payment server comprising a processor and a ﬁrst database storing for at least one client a plurality of payment categories and a plurality of bank accounts, wherein the ﬁrst database stores a unique link between each payment category and a bank account of the plurality of bank accounts, the method comprising, by the processor: receiving transaction payment information including card information relating to one client, merchant information and costs from a payment terminal, acquiring a payment category from the merchant information, looking up the acquired payment category in the ﬁrst database and, if present, using said link for said payment category as well as said card information to identify a bank account among the plurality of bank accounts of said client, checking a balance in the identiﬁed bank account, and approving the costs and sending an approval signal to the payment terminal if it is determined that the balance is sufﬁcient for the payment.

Description

Title of Invention: System for and method of providing a payment service Field of the invention

[0001] The present invention relates to a system for a method of providing a payment service, for example, a payment service provided by a payment server such as a bank server for a card transaction.

Background art

[0002] Traditionally, a user has a payment card (e.g., a debit card) associated with one bank account managed by a bank server. To make purchase activities more convenient, a concept of a plurality of payment cards associated with one bank account has been introduced. For examples, two persons have their own payment cards and share one bank account associated with the two payment cards.

[0003] Sometimes, the users have a plurality of payment cards and each payment card is associated with a different bank account managed by a different bank server in order to categorize their payment. For example, “James” has three payment cards, card-A, card- B and card-C. Card-A is associated with a bank account of AA bank, card-B is associated with a bank account of BB bank, and card-C is associated with a bank account of CC bank.

[0004] In this situation, James can categorize his payment activities such that grocery item payments are made by use of the card-A, sport activities by use of the card-B and transportation by use of the card-C. However, James always needs to be aware which card is related with which payment category. He also needs to bring these payment cards and, probably, use them with different passwords. When he needs an additional payment card with a different payment category, he has to go through a series of processes in a traditional way to open a new bank account and obtain a new payment card which is associated with the new bank account. This is considered very inconvenient and inefficient.

Summary of the invention

[0005] Therefore, a new system for providing a payment service in a more efficient and convenient way is needed when it is necessary to categorize payment activities of the users.

[0006] According to the present invention, a method as defined in claim 1 is provided.

[0007] A payment server according to the invention is defined in an independent claim

9.

[0008] A computer program product comprising instructions and data which can be loaded by a processor in the payment server for providing a payment service according to the invention is defined in an independent claim 17.

[0009] The proposed method/payment server/computer program product may have at least one of the following advantages.

[0010] The present invention provides a more convenient and efficient way to categorize user’s payments automatically.

[0011] Managing a bank account which is categorized can be performed easily (e.g, when there is a need for creation of a new bank account for an additional payment category or when there is not sufficient balance in the bank account associated with a specific payment category).

[0012] The accumulated information in a database in a payment server can be processed for analyzing user’s purchase patterns and providing useful information to the users from this analysis.

Brief description of the drawings

[0013] Embodiments of the present disclosure will be described herein below with reference to the accompanying drawings. However, the embodiments of the present disclosure are not limited to the specific embodiments and should be construed as including all modifications, changes, equivalent devices and methods, and/or alternative embodiments of the present disclosure.

[0014] The terms “have,” “may have,” “include,” and “may include” as used herein indicate the presence of corresponding features (for example, elements such as numerical values, functions, operations, or parts), and do not preclude the presence of additional features.

[0015] The phrase “associated with” as well as derivatives thereof, means to connect to or with, couple to or with, be bound to or with, have a relationship to or with, interconnect with, or the like.

[0016] The terms “A or B,” “at least one of A or/and B,” or “one or more of A or/and B” as used herein include all possible combinations of items enumerated with them. For example, “A or B,” “at least one of A and B,” or “at least one of A or B” means (1) including at least one A, (2) including at least one B, or (3) including both at least one A and at least one B.

[0017] The terms such as “first” and “second” as used herein may modify various elements regardless of an order and/or importance of the corresponding elements, and do not limit the corresponding elements. These terms may be used for the purpose of distinguishing one element from another element. For example, a first element may be referred to as a second element without departing from the scope the present invention, and similarly, a second element may be referred to as a first element.

[0018] It will be understood that, when an element (for example, a first element) is “(operatively or communicatively) coupled with/to” or “connected to” another element (for example, a second element), the element may be directly coupled with/to another element, and there may be an intervening element (for example, a third element) between the element and another element. To the contrary, it will be understood that, when an element (for example, a first element) is “directly coupled with/to” or “directly connected to” another element (for example, a second element), there 1s no intervening element (for example, a third element) between the element and another element.

[0019] The expression “configured to (or set to)” as used herein may be used interchangeably with “suitable for” “having the capacity to” “designed to” “adapted to” “made to,” or “capable of” according to a context. The term “configured to (set to)” does not necessarily mean “specifically designed to” in a hardware level. Instead, the expression “apparatus configured to...” may mean that the apparatus is “capable of...” along with other devices or parts in a certain context.

[0020] The term “controller” or “processor” means any device, system or part thereof that controls at least one operation. Such a controller or a processor can be implemented in hardware or a combination of hardware and software and/or firmware. The functionality associated with any particular controller or processor can be centralized or distributed, whether locally or remotely.

[0021] Moreover, various functions described below can be implemented or supported by one or more computer programs, each of which is formed from computer readable program code and embodied in a computer readable medium. The terms “application” and “program” refer to one or more computer programs, software components, sets of instructions, procedures, functions, objects, classes, instances, related data, or a portion thereof adapted for implementation in a suitable computer readable program code.

[0022] The terms used in describing the various embodiments of the present disclosure are for the purpose of describing particular embodiments and are not intended to limit the present disclosure. As used herein, the singular forms are intended to include the plural forms as well, unless the context clearly indicates otherwise. All of the terms used herein including technical or scientific terms have the same meanings as those generally understood by an ordinary skilled person in the related art unless they are defined otherwise. The terms defined in a generally used dictionary should be interpreted as having the same or similar meanings as the contextual meanings of the relevant technology and should not be interpreted as having ideal or exaggerated meanings unless they are clearly defined herein. According to circumstances, even the terms defined in this disclosure should not be interpreted as excluding the embodiments of the present disclosure.

[0023] For the purpose of determining the extent of protection conferred by the claims of this document, due account shall be taken of any element which is equivalent to an element specified in the claims.

[0024] The present invention will be discussed in more detail below, with reference to the attached drawings, in which:

[0025] FIG. 1 shows a system for a first example of the present invention.

[0026] FIG. 2A shows an event flow for the system of FIG. 1.

[0027] FIG. 2B shows a configuration of a first database according to the present invention.

[0028] FIG. 3 shows a flow chart for account checking process (5240) of FIG. 2A.

[0029] FIG. 4A shows a flow chart for a first example of account managing process of FIG. 3.

[0030] FIG. 4B shows a flow chart for a second example of account managing process of FIG. 3.

[0031] FIG. 5 shows a flow chart for balance managing process of FIG. 3.

[0032] FIG. 6 show a system for a second example of the present invention.

[0033] FIG. 7A shows an event flow for the system of FIG. 6.

[0034] FIG. 7B shows another example of payments categories.

[0035] FIG. 8 shows a system for a third example of the present invention.

[0036] FIG. 9 shows an event flow for the system of FIG. 8.

[0037] FIG. 10A shows a block diagram of a first example for payment terminal (e.g., POS terminal) of the present invention.

[0038] FIG. 10B shows a block diagram of a second example for payment terminal (e.g, mobile device for online transaction) of the present invention.

5 [0039] FIG. 11 shows a block diagram of a payment server of the present invention.

[0040] FIG. 12 shows a block diagram of an external server of the present invention. Description of embodiments

[0041] The figures show different embodiments of the invention, which will be described in detail hereinafter. It is to be understood that elements / components shown in one or more of these embodiments and not in others may be used in those others too unless mechanical or other limitations prevent such an implementation. Moreover, describing features of different embodiments in a single paragraph does not automatically mean that those features are inextricably linked. They may be applied separately from one another.

[0042] Inthe specification below, the same reference numbers in different drawings refer tothe same elements/components.

[0043] FIG. 1 shows a system for a first example (100) of the present invention.

[0044] The system (100) comprises a plurality of network entities (120, 130, 170), and a network (160) through which the network entities communicate each other. The network entities comprise at least one payment terminal (120), at least one payment server (130) such as a bank server for a card holder and at least one bank server for an acceptant (170).

[0045] The payment terminal (120) provides a card holder a payment interface for making payments. When a card transaction occurs for payments by the card, transaction payment information according to the card transaction is created and sent to the payment server (130) for the card holder through the network (160).

[0046] The term “card” in this description can be considered as a physical card (e.g, debit card or credit card) or a virtual card which is implemented or installed on a device (e.g., a mobile phone) in a form of software, application, a barcode or image related to physical card.

[0047] The transaction payment information includes card information relating to one client (e.g., the card holder), merchant information and costs to be paid for a service or purchase.

[0048] For the physical card, card information may comprise card number, identification information of the card holder (e.g., person’s name) and an expiry date. For the virtual card, card information may comprise a unique number in the form of a token (e.g.

ApplePay™) or identification information for an executing payment application. If the virtual card is in the form of a barcode or image related to a specific physical card, card information may be the same as that of the specific physical card.

[0049] Merchant information may include a merchant’s name, a postal address of the merchant, the Merchant Category Code, bank information of a merchant such as an international bank account number, IBAN or business information of a merchant such as a business identifier code, BIC.

[0050] The payment server (130) receives the transaction payment information from the payment terminal (120) and acquires a payment category from the merchant information included in the transaction payment information. After that, the payment server (130) identifies a bank account by using the payment category and the card information included in the transaction payment information. To perform this process, the payment server (130) may refer to a first database (140) or a second database (150). In the present invention, the first database (140) and the second database (150) are distinguished from each other from a functional and logical perspective. Therefore, they can be merged in one physical database system or split into more than one physical database system.

[0051] The first database (140) may store for at least one client a plurality of payment categories and a plurality of bank accounts. The first database further stores a unique link between each payment category and a bank account of the plurality of bank accounts.

[0052] Namely, when a client has one debit card, a plurality of bank accounts associated with the one debit card as well as a plurality of payment categories are stored in the first database. The first database also stores a unique link between each payment category and a bank account of the plurality of bank accounts. The configuration of the first database including the unique link is shown in FIG. 2B.

[0053] Referring to FIG. 2B, the first database may be configured to store information on mapping or link between bank accounts and payment categories.

[0054] More specifically, the first database may comprise “payment category pool”, “card information”, “bank accounts”, “payment category” and “link information” as shown in FIG. 2B.

[0055] The “payment category pool” may include a variety of payment categories and the payment server may update the payment category pool by adding a new payment category, deleting an existing category, renaming a name of a payment category, merging a plurality of payment categories to one payment category or splitting one payment category into a plurality of payment categories.

[0056] The “card information” may include information on card number, name of card holder or expiry date. The “card information” may include information for identifying a specific card or distinguishing the specific card from others.

[0057] The “bank accounts” may include a plurality of bank accounts associated with card information of one specific card. The number of bank accounts may be varied by the payment server. Some of bank accounts associated with one specific card is linked to a unique payment category, but some of them is not as shown in FIG. 2B.

[0058] The “payment category” may include a payment category retrieved from the payment category pool and each payment category may be referred to by a plurality of bank accounts from different cards. For example, in FIG. 2B, if Jane assigns her fourth bank account as a payment category for taxes, the payment category “Taxes” may be referred to by the fourth bank account of Jane’s card as well as the third bank account of David’s card. In FIG. 2B, the “payment category” and the “payment category pool” are shown separately, however these may be integrated and managed by the payment server.

[0059] The “link information” may include information indicating “which bank account” is assigned to “which payment category”, namely “which bank account” is associated with “which payment category” and this information is uniquely configured. Namely, if one bank account is set for a payment account, it is linked to only one payment category. Some bank accounts may have no link information. One of them having no link information may be assigned as a reserved bank account or a default bank account.

[0060] The second database (150) may store mapping information between the payment categories and the merchant information. The second database may be configured by the payment server (130) or other network entities such as a category managing server (680- 2) as shown in FIG. 8.

[0061] The first database (140) may be directly accessed by the payment server (130). The second database (150) may be directly accessed by the payment server (130) or may be managed by other network entities.

[0062] When identifying the bank account, the payment server (130) checks the balance in the identified bank account and sends an approval signal to the payment terminal (120) if it is determined that the balance in the identified bank account is sufficient for the payment.

[0063] After approval, an approval signal is sent to the payment terminal (120), and money to be paid from the identified bank account is transferred to the bank server for acceptant (170) to be stored in an acceptant’s bank account.

[0064] More detailed interactions between the above network entities will be described in disclosed in FIG. 2A through FIG. 5.

[0065] FIG. 2A shows an event flow for the system of FIG. 1.

[0066] When a card transaction occurs in the payment terminal (120) (S210), the transaction payment information is created and sent to the payment server (130) (S220). The transaction payment information includes card information relating to one client (e.g., a card holder), merchant information and costs to be paid.

[0067] When the payment server (130) receives the transaction payment information from the payment terminal (120), the payment server (130) searches a payment category in the second database (150) by using the merchant information included in the transaction payment information and identifies the payment category corresponding to the merchant information (S230).

[0068] In this way, the payment server (130) acquires the payment category, after which the payment server (130) performs an account checking process. The account checking process starts by looking up the acquired payment category in the first database (140) (S240).

[0069] The first database (140) stores for at least one client a plurality of payment categories and a plurality of bank accounts. The first database (140) also stores a unique link between payment category and bank account. In this regard, some payment categories in the first database (140) may not have links to bank accounts yet in order to be set up afterwards.

[0070] If there exists a payment category in the first database (140), the payment server (130) identifies a bank account among the plurality of bank accounts of said client by using the unique link for the existing payment category and the card information included in the transaction payment information.

[0071] Then, the payment server (130) checks a balance in the identified bank account. If it 1s determined that the balance is sufficient for the payment, as an approval process, the payment server (130) approves the costs to be paid and creates an approval signal including information on the identified bank account and the approved costs (S260). Finally, the payment server (130) sends the created approval signal to the payment terminal (120) (S260) and makes payments to the bank server for acceptant (170) (S270).

[0072] An example is provided as follows in order to make the procedures shown in FIG. 2A clearer and easy to understand by using the first database (140) and the second database (150).

[0073] A client, called “David” has a “Handy” debit card from the AAA bank. Namely, David 1s a card holder for the “Handy” debit card. David has four bank accounts at the AAA bank which are associated with or connected to the “Handy” debit card. Three accounts out of the four bank accounts are assigned to make payments for 1) book, ii) sport activities and iil) taxes, respectively. The remaining account is assigned as a reserved account. The reserved account can be used as a default account as well.

[0074] Now, David enters a book store and selects two books. The total price is 100 Euros. To purchase the two books, David sweeps his “Handy” debit card at a payment terminal (120) such as Point of Sale, POS, installed in the book store. The POS terminal issues a card transaction and creates a transaction payment information including card information, merchant information and the cost as shown in the table below.

[0075] [Table-1] transaction payment Contents men card information Card number for “Handy” debit card Name on “Handy” debit card (e.g., David) Expiry date

[0076] The POS terminal in the book store sends the above transaction payment information to the AAA bank server (e.g., payment server for the “Handy” debit card).

[0077] A processor in the AAA bank server is capable of accessing a first database and a second database directly. FIG. 2B shows a configuration of the first database in this example.

[0078] When the AAA bank server receives transaction payment information from the payment terminal (120), the processor of the AAA bank server retrieves the merchant information from the transaction payment information and searches a payment category in the second database by using the merchant information.

[0079] In this example, the merchant information is “book store”, therefore, the processor of the AAA bank server identifies the payment category as “book”.

[0080] After acquiring “book” as a payment category, the processor of the AAA bank server looks up the “book” payment category in the first database. The first database can be structured as shown in FIG. 2B

[0081] If the “book” payment category is found in a payment category pool in the first database, the processor of the AAA bank server uses i) the card information in the transaction payment information and ii) link information to identify a bank account among the plurality of bank account for David.

[0082] The link information indicates that each bank account is uniquely linked with one or more specific payment categories. Some bank accounts may be the linked with payment categories, respectively, and some banks accounts may not. One of the bank accounts having no link information may be considered as a reserved bank account or a default bank account. The link information may be set when a card associated with a plurality of bank accounts 1s issued or activated.

[0083] In this example, the processor of the AAA bank server confirms that 1) David's “Handy” debit card matches card information in the first database, 11) the “Handy” debit card is associated with four bank accounts, and iii) three bank accounts have the link information. The link information shows that the first bank account is linked with “book” payment category, the second bank account is linked with “sport activities” payment category, and the third bank account is linked with “taxes” payment category. The processor of the AAA bank server also confirms that the fourth bank account has no link information.

[0084] Therefore, the processor of the AAA bank server identifies the first bank account as a payment account for the two books and checks a balance in the first bank account.

The processor of the AAA bank server confirms the balance in the first bank account as 150 Euro and approves the costs. And then, the AAA bank server sends an approval signal to the POS terminal in the book store. The POS terminal in the book store may display information on “which bank accounts (first bank account in this example)”, “which category (book in this example)” and “how much (100 Euro)” for the purchase of the two books. The POS terminal in the book store may further display information on the balance after deduction from the identified bank account (50 Euro in this example). As David uses a debit card, the processor of AAA bank server deducts 100 Euro from the first bank account and performs payments to a bank server for acceptant.

[0085] FIG. 3 shows a flow chart for account checking the process of FIG. 2A.

[0086] When the processor of the payment server (130) looks up the acquired payment category in the first database (S310), identifies a bank account corresponding to the acquired payment category among the plurality of bank accounts (S320), and confirms that a balance in the identified bank account is sufficient for the payment (S330), the processor performs the approval process (S250) as in FIG. 2A.

[0087] However, when the processor of the payment server (130) looks up the acquired payment category in the first database but confirms that a bank account corresponding to the acquired payment category does not exist among the plurality of bank accounts for the card, the processor performs an account managing process as shown in FIG. 4A and FIG. 4B (S320 and S340).

[0088] FIG. 4A shows a flow chart for a first example of account managing process (S340) of FIG. 3.

[0089] As a first example of the account managing process, the processor checks a balance of a reserved bank account among the plurality of bank accounts (S410). The reserved bank account may be determined in advance by the card holder or the payment server (130), and considered as a bank account having no unique link to a specific payment category. The reserved bank account may be considered as a default bank account.

[0090] If it is determined that there is a sufficient balance for the payment in the reserved bank account (S420), the processor of the payment server (130) approves the costs to be paid and creates an approval signal including information on the reserved bank account as an identified bank account and the approved costs. And then, the payment server (130)

sends the created approval signal to the payment terminal (120). The payment terminal (120) displays information on the reserved bank account and the approved costs. The payment terminal (120) may further display the reason why the reserved bank account is used for the payment. The payment terminal (120) may further display the balance after a deduction in the reserved bank account.

[0091] If it is determined that there is not a sufficient balance for the payment in the reserved bank account, the process or the payment server (130) checks a balance in other bank account (S420 and S430). The other bank account comprises linked account, other reserved account if there are more than one reserved account. The linked account may be checked first and then the other reserved account may be checked. When there is insufficient balance in the other account, the processor of the payment server (130) considers the current card transaction as a failure.

[0092] When the balance in the other bank account is sufficient for the payment, the processor of the payment server (130) approves the costs to be paid and creates an approval signal including information on the other bank account as an identified bank account and the approved costs. The payment server (130) then sends the created approval signal to the payment terminal (120). The payment terminal (120) displays information on the other bank account and the approved costs. The payment terminal (120) may further display the reason why the other bank account is used for the payment. The payment terminal (120) may further display the balance after a deduction in the other bank account.

[0093] When the balance in the other bank account is not sufficient for the payment, the processor of the payment server (130) does not approve the costs to be paid and creates a signal including information on the disapproval. The payment server (130) then sends the created signal to the payment terminal (120). The payment terminal (120) displays information on the disapproval. The payment terminal (120) may further display the reason why the payment is rejected. The payment terminal (120) may further display the balance for each bank account associated with the card.

[0094] In the above case of the “Handy” debit card, for example, if David uses the “Handy” debit card to pay 40 Euros for the purchase of some vegetables in a grocery store, the processor of the AAA bank server acquires “Grocery” as a payment category in the payment category pool in the first database. However, none of bank accounts associated with David’s “Handy” debit card has link information on the “Grocery” payment category.

[0095] Therefore, the processor of the AAA bank server checks a balance of the fourth bank account which is a reserved bank account. If it 1s determined that there 1s sufficient balance in the fourth bank account enough to pay 40 Euros, the process of the AAA bank server performs the approval process as shown in FIG. 2A for the reserved bank account.

[0096] If it is determined that there is not a sufficient balance in the fourth bank account enough to pay 40 Euros, the process of the AAA bank server checks a balance in the other bank account. The other bank account, in this example, is considered as one of the first bank account, the second bank account, and the third bank account. As an another example, the process of the AAA bank server may consider the current card transaction as a failure if it is determined that there is not a sufficient balance in the fourth bank account enough to pay 40 Euros.

[0097] If the process of the AAA bank server confirms that the first bank account has enough balance for the payment of 40 Euros, the process of the AAA bank server performs the approval process as shown in FIG. 2A for the first bank account.

[0098] If the process of the AAA bank server confirms that none of the three bank accounts has enough balance for the payment of 40 Euros, the process of the AAA bank disapproves the payment. As another example, the disapproval for the payment may occur when the reserved bank account does not have a balance enough to make payments, without checking the other bank accounts.

[0099] FIG. 4B shows a flow chart for a second example of account managing process of FIG. 3.

[00100] As a second example of the account managing process, the processor of the payment server (130) creates a new bank account corresponding to the acquired payment category (S440). The new bank account may be created, by the processor of the payment server (130), among an existing plurality of bank accounts which have no link information on a payment category. The new bank account may also be created, by the process of the payment server (130), by adding a new account to existing plurality of bank accounts. The processor of the payment server (130) set link information between the new bank account and the acquired payment category.

[00101] When the new bank account corresponding to the acquired payment category is created, the processor of the payment server (130) checks a balance of a reserved bank account among a plurality of the bank accounts (S450).

[00102]If it 1s determined that there is a sufficient balance in the reserved bank account, the processor of the payment server (130) transfer currency from the reserved bank account to the new created bank account (S460 and S470) and performs the approval process as shown in FIG. 2A.

[00103]1f it is determined that there is not a sufficient balance in the reserved bank account, the processor of the payment server (130) checks in the other bank account (S460 and S480). If it is determined that there is a sufficient balance in the other bank account, the processor of the payment server (130) transfer currency from the other bank account to the new created bank account (S485 and S490) and performs the approval process as shown in FIG. 2A.

[00104]If it is determined that there is not a sufficient balance in the other bank account, the processor of the payment server (130) does not approve the costs to be paid and creates an approval signal including information on the disapproval in the approval process in FIG. 2A.

[00105]In the above case of the “Handy” debit card, for example, if David uses the “Handy” debit card to pay 40 Euros for the purchase of some vegetables in a grocery store, the processor of the AAA bank server acquires “Grocery” as a payment category in the payment category pool in the first database. However, none of bank accounts associated with David’s “Handy” debit card has link information for the “Grocery” payment category.

[00106] Therefore, the processor of the AAA bank server creates a fifth bank account and sets a link information between the fifth bank account and the “Grocery” payment category. Hence, the fifth bank account is now used for payments which belong to the “Grocery” payment category.

[00107] Then, the processor of the AAA bank server checks a balance of the fourth bank account which is a reserved bank account.

[00108]If it is determined that there is a sufficient balance enough to pay 40 Euros in the fourth bank account, the processor of the AAA bank server transfer at least 40 Euros from the fourth bank account to the fifth bank account.

[00109] However, if it is determined that there is not a sufficient balance to pay 40 Euros in the fourth bank account, the processor of the AAA bank server checks balances of other bank accounts (e.g., the first bank account, the second bank account and the third bank account). For example, if it is determined that there is a sufficient balance in the third bank account associated with the “Taxes” payment category, the processor of the AAA bank server transfer 40 Euros in the third bank account to the new created fourth bank account and performs the approval process shown in FIG. 2A. If none of other bank accounts has a sufficient balance, the processor or the AAA bank server determines a rejection to the payment and performs the approval process shown in FIG. 2A.

[00110]In the meanwhile, in FIG. 3, when the processor of the payment server (130) looks up the acquired payment category in the first database and identifies a bank account corresponding to the acquired payment category among the plurality of bank accounts but confirms that a balance in the identified bank account is not sufficient for the payment, the processor performs a balance managing process (S350) as shown in FIG. 5.

[00111]FIG. 5 shows a flow chart for balance managing process of FIG. 3.

[00112] The processor of the payment server (130) checks a balance of a reserved bank account (S510). If it is determined that a sufficient balance in the reserved bank account exists (S520), the processor of the payment server (130) performs the approval process as shown in FIG. 2A. In this case, the processor of the payment server (130) may transfer currency in the reserved bank account to the identified bank account.

[00113]1f it is determined that there is not a sufficient balance in the reserved bank account, the processor of the payment server (130) checks in the other bank account (S520 and S530). If it is determined that there is a sufficient balance in the other bank account, the processor of the payment server (130) transfer currency from the other bank account to the identified bank account (S540 and S550) and performs the approval process as shown in FIG. 2A.

[00114]If it is determined that there is not a sufficient balance in the other bank account, the processor of the payment server (130) does not approve the costs to be paid and creates an approval signal including information on the disapproval in the approval process in FIG. 2A.

[00115] In the above case of the “Handy” debit card, for example, if Jane uses the “Handy” debit card to pay 100 Euros for a registration of online education, the processor of the

AAA bank server acquires “Education” as a payment category in the payment category pool in the first database as shown in FIG. 2B and determines the second bank account associated with the “Education” payment category as a payment account for the registration of online education.

[00116]However, the processor of the AAA bank server confirms that a balance in the second bank account is not sufficient for the payment. Therefore, the processor of the AAA bank server checks a balance of the third bank account which has been assigned as a reserved bank account.

[00117]1f it is determined that there is a sufficient balance enough to pay 100 Euros in the third bank account, the processor of the AAA bank server determines the third bank account as a payment account for the registration of online education. Alternatively, the processor of the AAA bank server transfer at least 100 Euros from the third bank account to the second bank account for making payments through the second bank account.

[00118] However, if it is determined that there is not a sufficient balance to pay 100 Euros in the third bank account, the processor of the AAA bank server checks balances of other bank accounts (e.g., the first bank account, and the fourth bank account). For example, if it is determined that there is a sufficient balance in the first bank account associated with the “Grocery” payment category, the processor of the AAA bank server transfer 100 Euros in the first bank account to the second bank account and performs the approval process shown in FIG. 2A. If none of other bank accounts has a sufficient balance, the processor or the AAA bank server determines a rejection to the payment and performs the approval process shown in FIG. 2A.

[00119]FIG. 6 show a system for a second example (100-1) of the present invention.

[00120] Compared with the system architecture as shown in FIG. 1, FIG. 6 shows that the second database (150) is controlled by a third party such as a category managing server as an external server (680-1). Therefore, the bank server for the card holder as payment server (130-1) needs to communicate with the category managing server as external server (680-1) in order to acquire a payment category.

[00121]FIG. 7A shows an event flow for the system of FIG. 6.

[00122]When a card transaction occurs in the payment terminal (120) (S210-1), the transaction payment information is created and sent to the payment server (130-1) (S220-

1). The transaction payment information includes card information relating to one client (e.g., a card holder), merchant information and costs to be paid.

[00123] When the payment server (130-1) receives the transaction payment information from the payment terminal (120), the payment server (130-1) sends a category request message including the merchant information to an category managing server (680-1) (S710).

[00124] Then, the category managing server (680-1) searches a payment category in the second database (150) by using the merchant information included in the category request message and identifies the payment category corresponding to the merchant information (S720).

[00125] The category managing server (680-1) sends a category response message responding to the category request message to the payment server (130-1) (S730). The category response message includes information on the identified payment category.

[00126]In this way, the payment server (130-1) acquires a payment category corresponding to the merchant information and then the payment server (130-1) performs the account checking process and the approval process in the same way as shown in FIG. 2A. Namely, the account checking process (5240-1), the approval process (S250-1), sending of approval signal (S260-1) and making a payment (S270-1) in FIG. 7A operate the same way as the account checking process (S240), the approval process (S250), sending of approval signal (S260) and making a payment (S270) in FIG. 2A, respectively.

[00127] As another example of FIG. 7A, the category managing server (680-1) sets payment categories and each payment category is linked to different bank accounts.

[00128] For examples, as shown in FIG. 7B, card holder “David” has four bank accounts connected to the card “AAANL12320332” and each bank account is linked to four different payment categories “NEEDS”, “WANTS”, “FALLBACK” and “SAVINGS”, respectively.

[00129] “NEEDS” payment category can be used for purchase of necessary items or services considered by a card user, such as groceries or house rents.

[00130] “WANTS” payment category can be used for purchase of items or services which auser wants to purchase. The “WANTS” payment category can be also used for purchase of items or services which do not belong to the “NEEDS” payment category.

[00131] “FALLBACK” payment category can be used when either a bank account linked to the “NEEDS” payment category or a bank account linked to the “WANTS” payment category does not have enough money or funds for purchase.

[00132] “SAVINGS” payment category can be used for the purpose of savings. A bank account linked to the “SAVINGS” payment category is not be directly debited and receives any leftover money or funds in the “WANTS” payment category at a specified time, e.g., at the end of month.

[00133] Payments are divided between the “NEEDS” payment category and the “WANTS” payments category.

[00134] When either a bank account for the “NEEDS” payment category or a bank account for the “WANTS” payments category has enough money or funds to pay for a purchase, a transaction for the purchase is determined as a success. Otherwise, a bank account assigned to the “FALLBACK” payment category is checked.

[00135] If the bank account assigned to the “FALLBACK” payment category has enough money or funds to pay for the purchase, the transaction for the purchase is determined as a success. If the bank account assigned to the “FALLBACK” payment category does not have enough money or funds to pay for the purchase, the transaction for the purchase is determined as a failure.

[00136] FIG. 7B shows four different payment categories, but the number of payment categories can be set differently by the category managing server (680-1). For examples, FIG. 7B shows two different payment categories “NEEDS” and “WANTS”, but these two payment categories are combined into one payment category “MAIN”. In this case, the number of payment categories can be set as three.

[00137]FIG. 8 shows a system for a third example (100-2) of the present invention.

[00138]In FIG. 8, a category managing server (680-2) plays a role as an agent which connects payment terminal (120) and the a plurality of bank servers (130-2a, 130-2b, 130-2c, ...). The category managing server (680-2) is also considered as a hub or a gateway between the payment terminal (120) and the plurality of bank servers (130-2a, 130-2b, 130-2c, ...).

[00139] The category managing server (680-2) includes a first database (140) and a second database (150). The first database (140) has a data structure in a way as shown in FIG. 2B.

[00140] A card (110) is associated with a plurality of bank accounts and the plurality of bank accounts may be managed or controlled by different bank servers.

[00141]F1G. 9 shows an event flow for the system of FIG. 8.

[00142]When a card transaction occurs in the payment terminal (120) (S210-2), the transaction payment information is created by the payment terminal (120) and sent to the category managing server (680-2) (5220-2). The transaction payment information includes card information relating to one client (e.g., a card holder), merchant information and costs to be paid.

[00143] When the category managing server (680-2) receives the transaction payment information from the payment terminal (120), the category managing server (680-2) searches a payment category in the second database (150) by using the merchant information included in the transaction payment information and identifies the payment category corresponding to the merchant information (S230-2).

[00144] And then, the category managing server (680-2) determines a bank account corresponding to the acquired payment category by using the first database (140) (S240- 2).

[00145] The category managing server (680-2) sends a payment request message to a payment server which is associated with the determined bank account corresponding to the acquired payment category (S950). The payment request message may include information on the determined bank account and costs to be paid. For example, the FIG.

9 shows that the determined bank account is associated with the first bank server (130- 2a) as a payment server.

[00146] When the payment server (130-2a) receives the payment request message from the category managing server (680-2), the payment server (130-2a) checks a balance in the determined bank account (S955) and sends a payment response message to the category managing server (680-2) (S960). The payment response message may include information on the balance in the determined bank account. The payment response message may include information on a status of the determined bank account, amount of money in the determined bank account, approval of the card transaction, or availability of deduction for the payment.

[00147]In this way, category managing server (680-2) acquires a payment category corresponding to the merchant information and confirms availability of the determined bank account for the payment.

[00148] After receiving the payment response message from the payment server (130-2a), the category managing server (680-2) sends a notification signal to the payment terminal (120) (S260-2).

[00149] The notification signal may include information on approval for the card transaction. The information on approval may include at least one of the acquired payment category, the determined bank account and whether or not to approve the card transaction. The information in the notification signal is displayed on the payment terminal (120).

[00150]1f it is determined that the card transaction is approved by the payment server (130-2a), the corresponding amount of money is transferred to the bank server for acceptant (170) (S270-2).

[00151]FIG. 10A shows a block diagram of a first example for payment terminal (120-1) (e.g., POS terminal) of the present invention.

[00152] The POS terminal (120-1) is normally located in the offline store and used for payment by clients. The POS terminal (120-1) comprises a card interface (120-1a), an input/output interface (120-1b), a memory (120-1c¢), a network interface (120-1d) and a controller (120-1e).

[00153] The card interface (120-1a) receives card information from a card which is a physical card or a virtual card. To receive the card information from the card, the card interface (120-1a) includes wireless or wired communication circuitry to interact with the card such as magnetic secure transmission, MST, Bluetooth, radio frequency, RF, NFC module, etc. The card interface delivers the received card information to the controller (120-1e).

[00154] The input/output interface (120-1b) receives cost information and displays purchase information. The cost information may be provided in a form of barcode which is attached to products or numbers input by users of the POS terminal (120-1). The purchase information may include information on purchased products, a bank account associated with the card for payment, a payment category for the purchase, whether or not to be approved for the payment. The card interface (120-1a) may be configured as a part of the input/output interface (120-1b).

[00155] The memory (120-1c) stores a program to operate the POS terminal (120-1) and merchant information.

[00156] The network interface (120-1d) may communicate with a payment server such as a bank server associated with the card for payment. The network interface (120-1d) may also communicate with a network entity which performs a payment processing, especially disclosed in FIG. 9. (e.g., a category managing server)

[00157] The controller (120-1e) controls the card interface (120-1a), the input/output interface (120-1b), the memory (120-1c) and the network interface (120-1d). The controller (120-1e) receives the card information from the card interface (120-1a) and cost information from the input/output interface (120-1b). The controller (120-1e) then retrieves the merchant information and creates a transaction payment information by combining the card information, the cost information and the merchant information. The controller (120-1e) sends the transaction payment information to the payment server or the network entity via the network interface (120-1d).

[00158] When the controller (120-1e) receive an approval signal which is disclosed in this description via the network interface (120-1d), the controller (120-le) displays information in the received approval signal such as whether or not to be approved, a payment category or bank account of the card for payment. [00159JFIG. 10B shows a block diagram of a second example (120-2) for payment terminal (e.g., mobile device for online transaction) of the present invention.

[00160] These days, a lot of customers do online shopping and make payments online. In this case, a mobile device such as a smart phone, a laptop, etc. can be considered as a payment terminal. For examples, a smart phone can be used a replacement of a physical credit card or a virtual card (e.g, ApplePay™ or SamsungPay™) can be stored, downloaded or installed in the mobile device. Even a desktop personal computer can be the payment terminal. Therefore, the block diagram shown in FIG. 10B is considered as a configuration for purchasing and payment online. For explanation, FIG. 10B shows a block diagram of a mobile phone ((120-2)). However, it can be applied to other devices capable of performing online payment.

[00161] The mobile phone (120-2) comprises a card database (120-2a), an input/output interface (120-2b), a memory (120-2c}), a network interface (120-2d) and a controller (120-2e).

[00162] The card database (120-2a) stores card information on a card. When a user of the mobile phone (120-2) has information on a plurality of cards in the mobile phone, the card database (120-2a) stores each card information for the plurality of cards, respectively. The card information may comprise card number, identification information of the card holder (e.g., person’s name) and a expiry date. The card information may also comprise a unique number in the form of a token (e.g. ApplePay™) or identification information for an executed payment application. The card information may be in a form of image such as a barcode.

[00163] The input/output interface (120-2b) interacts with a user of the mobile phone (120-2). The input/output interface (120-2b) provides an interface (e.g., touch screen) for the user to browse purchase items and select a card for the payment.

[00164] The memory (120-2c) stores a program to operate the mobile phone (120-2).

[00165] The network interface (120-2d) may communicate with a payment server such as a bank server associated with the card for payment. The network interface (120-2d) may also communicate with a network entity which performs a payment processing, especially disclosed in FIG. 9. (e.g., a category managing server)

[00166] The controller (120-2e) controls the card database (120-2a), the input/output interface (120-2b), the memory (120-2c) and the network interface (120-2d). The controller (120-2e) retrieves the card information from the card database (120-2a). The controller (120-2e) may acquire cost information and merchant information from a user’s interaction with, for example, an online shopping mall. And then, the controller (120-2¢) creates a transaction payment information by combining the card information, the cost information and the merchant information. The controller (120-2e) sends the transaction payment information to the payment server or the network entity via the network interface.

[00167] As another example, the controller (120-2e) sends the card information to the online shopping mall and the online shopping mall creates a transaction payment information by combining the card information, the cost information and the merchant information. In this case, the online shopping mall sends the transaction payment information to the payment server or the network entity. The online shopping mall and the mobile phone may be considered seen as a “payment terminal” in a way of broader concept form the perspective of the payment server or the network entity.

[00168] When the controller (120-2e) receives an approval signal which 1s disclosed in this description via the network interface (120-2d), the controller (120-2e) displays information included in the received approval signal such as whether or not to be approved, a payment category or bank account of the card for payment.

[00169] FIG. 11 shows a block diagram of a payment server of the present invention.

[00170] The payment server (130) comprises a database (130-a), a memory (130-b), an external network interface (130-c) and a processor (130-d).

[00171] The external network interface (130-c} is used for communicating with payment terminals or other external server such as a category managing server as shown in FIG. 6 or FIG. 8.

[00172] The database (130-a) may be configured as a plurality of record items such as “card information”, “bank accounts”, “payment category” and link information between “bank accounts” and “payment category”. The record item may further comprise “payment category pool”. These records are shown in FIG. 2B as a first database.

[00173] The database (130-a) may further comprise a second database configured in such a way that merchant information is mapped to payment category.

[00174] The database (130-a) may comprise general financial information for each bank account.

[00175] The memory (130-b) may store a computer program to execute instructions and data which can be loaded by the processor (130-d). Once the processor (130-d) loads the computer program, the processor (130-d) receives transaction payment information including card information relating to one client, merchant information and costs from a payment terminal, acquires a payment category from the merchant information, looks up the acquired payment category in the database and, if present, using said link for said payment category as well as said card information to identify a bank account among the plurality of bank accounts of said client, checks a balance in the identified bank account, and approves the costs and sending an approval signal to the payment terminal via the external network interface if it is determined that the balance is sufficient for the payment.

[00176] The structure of the payment server (130) shown in FIG. 11 may be applied similarly to payment servers (130-1, 130-2a, 130-2b and 130-2¢) shown in FIG. 6 and FIG. 8.

[00177]FIG. 12 shows a block diagram of an external server (680) of the present invention.

[00178] The structure of the external server (680) shown in FIG. 12 may correspond to external servers (680-1, 680-2) shown in FIG. 6 and FIG. 8.

[00179] The external server (680) comprises a database (680-a), a memory (680-b), a network interface (680-c) and a controller (680-d).

[00180] The external network interface (680-c) is used for communicating with payment terminals or payments servers as shown in FIG. 7A or FIG. 9.

[00181] The database (680-a) may comprise at least a second database in such a way that merchant information is mapped to payment category and further comprise a first database as shown in FIG. 2B. The database (680-a) may further comprise a plurality of bank accounts associated with a plurality of payment server (e.g., bank servers), respectively.

[00182] The memory (680-b) may store a computer program to execute instructions and data which can be loaded by the controller (680-d). Once the controller (680-d) loads the computer program, the controller (680-d) receives a category request message including the merchant information from a payment server via the network interface (680-c), searches a payment category in the database (680-a) by using the merchant information included in the category request message and identifies the payment category corresponding to the merchant information, and sends a category response message responding to the category request message to the payment server via the network interface (680-c). The category response message includes information on the identified payment category.

[00183] The memory (680-b) may also store a computer program to execute instructions and data which can be loaded by the controller (680-d). Once the controller (680-d) loads the computer program, the controller (680-d) receives a transaction payment information from a payment terminal (120), searches a payment category in the database (680-a) by using the merchant information included in the transaction payment information and identifies the payment category corresponding to the merchant information. And then,

the controller (680-d) determines a bank account corresponding to the acquired payment category by using the database (680-a). And then, the controller (680-d) sends a payment request message to a payment server which is associated with the determined bank account corresponding to the acquired payment category and receives a payment response message from the payment server. The payment response message may include information on the balance in the determined bank account. The payment response message may include information on a status of the determined bank account, amount of money in the determined bank account, approval of the card transaction, or availability of deduction for the payment. After receiving the payment response message from the payment server, the controller (680-d) sends a notification signal to the payment terminal (120). The notification signal may include information on the acquired payment category, determined bank account or whether or not to approve the card transaction. The information in the notification signal 1s displayed in the payment terminal (120).

[00184] As apparent from the above description, all devices used in the invention are computer based devices having a processor unit running some software to perform the functions explained with reference to the flowcharts. The software, which includes instructions and data, needed to be loaded and run by such processor unit can be stored on any suitable physical data carrier and/or transmitted from one location to another via any suitable data carrier as defined in any suitable communication standard.

[00185] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments, as claimed in the appended claims. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation.

Claims

Conclusions

A method for providing a payment service by a payment server, the payment server comprising a processor and a first database storing, for at least one client, a plurality of payment categories and a plurality of bank accounts, the first database providing a unique link between has stored each payment category and a bank account of the plurality of bank accounts, the method comprising, by the processor: receiving (S220, $210-1) transaction payment information including card information related to one client, merchant information and charges from a payment terminal; acquiring a payment category from the merchant information; looking up (S310) the acquired payment category in the first database and, if any, using the payment category link and the card information to identify (S320) a bank account from the plurality of bank accounts of the client; checking (S330) a balance in the identified bank account; and approving (S250, S250-1) the charge and sending an approval signal to the payment terminal if it is determined that the balance is sufficient for the payment.

The method of claim 1, wherein the approval signal includes information about the identified bank account and the approved charges.

The method of claim 1, wherein the method further comprises: if a bank account corresponding to the acquired payment category is not identified, a reserved bank account is assigned as the identified bank account.

The method of claim 1, wherein the method further comprises: if it is determined that the balance is not sufficient for payment, money in a reserved bank account is transferred to the identified bank account.

The method of claim 1, wherein acquiring a payment category comprises: searching for a payment category in a second database using the merchant information (S230); and identifying the payment category corresponding to the merchant information (8230).

The method of claim 1, wherein acquiring a payment category comprises: sending (8710) a category request message including the merchant information to an external server, and receiving (8730) a category response message in response to the category request message from the external server, wherein the category response message includes information about the payment category corresponding to the merchant information.

7. A payment server (130, 130-1) for providing a payment service, comprising a processor (130-d) and a first database (140), connected to the processor and providing, for at least one client, a has stored a plurality of payment categories and a plurality of bank accounts, the first database having stored a unique link between each payment category and a bank account of the plurality of bank accounts, and a memory (130-b) connected to the processor (130-d), wherein the memory (130-b) has stored a computer program which, once loaded by the processor, provides the processor (130-d) with the ability to perform the following actions: receive transaction payment information including card information related to one client, merchant information and charges from a payment terminal (120); acquiring a payment category from the merchant information; looking up the acquired payment category in the first database (140) and, if any, using the payment category link and card information to identify a bank account from the plurality of customer bank accounts; checking a balance on the identified bank account; and approving the charge and sending an approval signal to the payment terminal (120) if it is determined that the balance is sufficient for payment.

The payment server of claim 7, wherein the approval signal includes information about the identified bank account and the approved charges.

The payment server of claim 7, wherein the processor assigns a reserved bank account as the identified bank account if a bank account corresponding to the acquired payment category is not identified.

The payment server of claim 7, wherein the processor searches a payment category in a second database using the merchant information, and identifies the payment category corresponding to the merchant information.

The payment server of claim 7, wherein the processor sends a category request message including the merchant information to an external server, and receives a category response message in response to the category request message from the external server, the category response message including information about the payment category that corresponds to the merchant information.

40

12. A computer program product comprising instructions and data that can be loaded by a processor into a payment server to provide a payment service, the payment server including a first database connected to the processor and containing, for at least one client, a plurality of payment categories and has stored a plurality of bank accounts, the first database having stored a unique link between each payment category and a bank account of the plurality of bank accounts, the computer program product, once loaded by the processor, providing the processor with the ability to perform the following actions: perform: receiving transaction payment information including card information related to one client, merchant information and charges from a payment terminal; acquiring a payment category from the merchant information; looking up the acquired payment category in the first database and, if any, using the payment category link and the card information to identify a bank account from the plurality of customer bank accounts; checking a balance on the identified bank account; and approving the charge and sending an approval signal to the payment terminal if it is determined that the balance is sufficient for payment.

A method for providing a payment service according to a card transaction by an external server, the external server comprising: a controller, a first database having stored, for at least one client, a plurality of payment categories and a plurality of bank accounts, the first database has stored a unique link between each payment category and a bank account of the plurality of bank accounts, and a second database, which has stored mapping information between the plurality of payment categories and merchant information, the method comprising, by the control unit: receiving (S220-2) transaction payment information including card information related to one customer, merchant information and charges from a payment terminal; acquiring (S230-2) a payment category from the merchant information; determining (S240-2) a bank account corresponding to the acquired payment category; sending (8950) a payment request message to a payment server associated with the particular bank account corresponding to the acquired payment category; receiving (S960) a payment response message in response to the payment request message from the payment server, the payment response message including information about a balance of the particular bank account; and sending (8260-2) a notification signal including information about the approval of the card transaction to the payment terminal.

The method of claim 13, wherein the payment response message further includes information on at least one of a status of the particular bank account, amount of money in the particular bank account, approval of the card transaction, and availability of deduction for the payment.

The method of claim 13, wherein the card transaction approval information includes at least one of the acquired payment category, the particular bank account, and whether or not the card transaction is to be approved.

The method of claim 13, wherein acquiring the payment category comprises: searching for a payment category in a second database using the merchant information contained in the transaction payment information; and identifying the payment category corresponding to the merchant information.

17. An external server (680-2) for providing a payment service, comprising a controller (680-d) and a database (680-a) connected to the controller (680-d), the database (680 -a) includes a first database storing, for at least one customer, a plurality of payment categories and a plurality of bank accounts, the first database storing a unique link between each payment category and a bank account of the plurality of bank accounts, and a second database , which has stored assignment information between the plurality of payment categories and merchant information, and a memory (680-b) connected to the control unit (680-d), the memory (680-d) storing a computer program that, once run by the control unit (680-d) is loaded, provides the control unit (680-d) with the ability to perform the following actions: receive transaction payment i information including card information related to one customer, merchant information and charges from a payment terminal; acquiring a payment category from the merchant information; determining a bank account corresponding to the acquired payment category; sending a payment request message to a payment server associated with the particular bank account corresponding to the acquired payment category; receiving a payment response message in response to the payment request message from the payment server, the payment response message including information about a balance of the particular bank account; and sending a notification signal including information about the approval of the card transaction to the payment terminal. 40

The remote server of claim 17, wherein the payment response message further includes information on at least one of a status of the particular bank account, amount of money in the particular bank account, approval of the card transaction, and availability of deduction for the payment.

The remote server of claim 17, wherein the card transaction approval information includes at least one of the acquired payment categories, the particular bank account, and whether or not the card transaction is to be approved.

The remote server of claim 17, wherein acquiring the payment category comprises: searching for a payment category in the second database using the merchant information contained in the transaction payment information; and identifying the payment category corresponding to the merchant information.

21. Computer program product comprising instructions and data loadable by a controller into an external server for providing a payment service, the external server comprising a first database storing, for at least one client, a plurality of payment categories and a plurality of bank accounts wherein the first database stores a unique link between each payment category and a bank account of the plurality of bank accounts, and a second database stores mapping information between the plurality of payment categories and merchant information, wherein the computer program product, once loaded by the controller, provides the control unit with the ability to perform the following operations: receiving transaction payment information including card information related to one client, merchant information and charges from a payment terminal; acquiring a payment category from the merchant information; determining a bank account corresponding to the acquired payment category; sending a payment request message to a payment server associated with the particular bank account corresponding to the acquired payment category; receiving a payment response message in response to the payment request message from the payment server, the payment response message including information about a balance of the particular bank account; and sending a notification signal including information about the approval of the card transaction to the payment terminal.