CA2799237A1 - Multicard payment artifact for managing a set of user-owned payment artifacts - Google Patents
Multicard payment artifact for managing a set of user-owned payment artifacts Download PDFInfo
- Publication number
- CA2799237A1 CA2799237A1 CA 2799237 CA2799237A CA2799237A1 CA 2799237 A1 CA2799237 A1 CA 2799237A1 CA 2799237 CA2799237 CA 2799237 CA 2799237 A CA2799237 A CA 2799237A CA 2799237 A1 CA2799237 A1 CA 2799237A1
- Authority
- CA
- Canada
- Prior art keywords
- backend
- cards
- multicard
- service
- good
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
A physical payment artifact is provided for the purchase of goods and services. The physical artifact can be referred to as a multicard. The multicard can be linked to a set of different payment artifacts, which are referred to as backend cards.
Each backend card can be a payment artifact for the purchase of goods and services. A
set of rules can be established for selecting which of the set of different backend cards the multicard draws from for a purchase. A good or service can be purchased from a retailer using the multicard. A set of the backend cards linked to the multicard can be automatically charged for amounts incurred by purchasing the good or service.
Each backend card can be a payment artifact for the purchase of goods and services. A
set of rules can be established for selecting which of the set of different backend cards the multicard draws from for a purchase. A good or service can be purchased from a retailer using the multicard. A set of the backend cards linked to the multicard can be automatically charged for amounts incurred by purchasing the good or service.
Description
MULTICARD PAYMENT ARTIFACT FOR MANAGING A SET OF USER-OWNED
PAYMENT ARTIFACTS
BACKGROUND
[0001] The present invention relates to the field of payment artifacts, such as credit cards, debit cards, check cards, and gift cards.
PAYMENT ARTIFACTS
BACKGROUND
[0001] The present invention relates to the field of payment artifacts, such as credit cards, debit cards, check cards, and gift cards.
[0002] Most consumers possess and utilize a set of different payment artifacts for purchases. These payment artifacts include credit cards, debit cards, check cards, gift cards, and the like. People use these different payment artifacts for a number of reasons.
For example, not all retailers accept all payment artifacts or payment artifact types, so user select among their possessed artifacts that are accepted by a particular retailer.
Further, consumers are often incentivized to utilize a particular payment artifact, where the incentives include "cash-back" on purchases, "reward points" paid toward plane tickets or other goods, extended warrantees, buyer insurance against defective goods/services, delayed periods of re-payment with favorable interest rates, and the like.
For example, not all retailers accept all payment artifacts or payment artifact types, so user select among their possessed artifacts that are accepted by a particular retailer.
Further, consumers are often incentivized to utilize a particular payment artifact, where the incentives include "cash-back" on purchases, "reward points" paid toward plane tickets or other goods, extended warrantees, buyer insurance against defective goods/services, delayed periods of re-payment with favorable interest rates, and the like.
[0003] From a card provider perspective, payment artifacts represent big business. Card providers are often compensated with relatively high interest rates (up to 21 percent) on unpaid balances, for example. The card providers also often charge venders a percentage of a sale, with three percent being common, at the time of a purchase for use of the payment artifact.
[0004] From a retailer perspective, despite the usage charge often incurred for usage of the payment artifacts, consumers are much more likely to complete purchases when using these artifacts. Further, the quantities of purchases are often greater than what would occur should consumers be forced to pay for all goods/services in cash.
Additionally, the retailers receive money from the card providers within a known time frame, whether the customer pays the card provider by that time period or not.
Thus, the retailers do not have to "float" the money for purchases, which many retailers cannot afford to do own their own. From a retailer perspective, the payment of a payment artifact charge is offset by gains from additional sales, which would otherwise be lost.
Additionally, some retailers extract a service charge for use of the payment artifacts, which compensates for their charge, which the consumer is responsible to pay at a time of purchase.
Additionally, the retailers receive money from the card providers within a known time frame, whether the customer pays the card provider by that time period or not.
Thus, the retailers do not have to "float" the money for purchases, which many retailers cannot afford to do own their own. From a retailer perspective, the payment of a payment artifact charge is offset by gains from additional sales, which would otherwise be lost.
Additionally, some retailers extract a service charge for use of the payment artifacts, which compensates for their charge, which the consumer is responsible to pay at a time of purchase.
[0005] From a customer perspective, payment artifacts represent a convenience when shopping. There is also a significant reward in personal safety, as consumers are often at risk when carrying large amounts of cash, which would be required in absence of the payment artifacts. In contrast, should a payment artifact be lost or stolen, the consumer is not responsible for charges that they did not approve. Further, many consumers are extremely happy to receive the incentives (or perks) related to using a payment artifacts, as these perks are often looked upon as "free money" or the equivalent.
BRIEF SUMMARY
BRIEF SUMMARY
[0006] One embodiment of the disclosure can include a system, an apparatus, a computer program product, and a method for paying for goods and/or services.
In the embodiment, a physical payment artifact is provided for the purchase of goods and services. The physical artifact can be referred to as a multicard. The multicard can be linked to a set of different payment artifacts, which are referred to as backend cards.
Each backend card can be a payment artifact for the purchase of goods and services. A
set of rules can be established for selecting which of the set of different backend cards the multicard draws from for a purchase. A good or service can be purchased from a retailer using the multicard. A set of the backend cards linked to the multicard can be automatically charged for amounts incurred by purchasing the good or service.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS
In the embodiment, a physical payment artifact is provided for the purchase of goods and services. The physical artifact can be referred to as a multicard. The multicard can be linked to a set of different payment artifacts, which are referred to as backend cards.
Each backend card can be a payment artifact for the purchase of goods and services. A
set of rules can be established for selecting which of the set of different backend cards the multicard draws from for a purchase. A good or service can be purchased from a retailer using the multicard. A set of the backend cards linked to the multicard can be automatically charged for amounts incurred by purchasing the good or service.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS
[0007] FIG. 1 shows a use case for a multicard in accordance with an embodiment of the inventive arrangements disclosure herein.
[0008] FIG. 2 illustrates a multicard payment artifact in accordance with an embodiment of the disclosure.
[0009] FIG. 3 shows a schematic diagram of a system within which a multicard is used in accordance with an embodiment of the inventive arrangements disclosed herein.
[0010] FIG. 4 is a flow chart for a method for configuring setting of a multicard via a user interface in accordance with an embodiment of the disclosure.
[0011] FIG. 5 provides flowcharts for usage of the multicard in accordance with embodiment of the disclosure.
DETAILED DESCRIPTION
DETAILED DESCRIPTION
[0012] Despite the numerous advantages achieved through payment artifacts (as detailed in the background for example), these payment artifacts have numerous disadvantages. For example, when payment artifacts are lost or stolen, these artifacts must be canceled and any recurring payments with retailers will be disallowed.
Thus, an owner of the lost credit card must contact all retailers associated with recurring payments and establish a different payment card for future recurring payments. The same problem occurs when a user changes their credit card companies, which results in a level of "lock in" inhibiting users from taking advantage of their best deals.
Thus, an owner of the lost credit card must contact all retailers associated with recurring payments and establish a different payment card for future recurring payments. The same problem occurs when a user changes their credit card companies, which results in a level of "lock in" inhibiting users from taking advantage of their best deals.
[0013] Additionally, management and payment of a set of credit cards incurs a level of management overhead. It is common for artifact owners to forget to pay fees, a balance, or a minimum payment on one of their payment artifacts, which results in late fees, excessive interest, and sometimes having their credit score tarnished.
Payment card owners often limit the amount of payment artifacts they maintain, as the management overhead for this set increases in direct proportion to an increase in quantity of artifact ownership. Additionally, it can become cumbersome to carry a significant quality of payment artifacts within a wallet/purse so that a desired artifact is available for retail purchases.
Payment card owners often limit the amount of payment artifacts they maintain, as the management overhead for this set increases in direct proportion to an increase in quantity of artifact ownership. Additionally, it can become cumbersome to carry a significant quality of payment artifacts within a wallet/purse so that a desired artifact is available for retail purchases.
[0014] During the course of the disclosure, the innovators - recognized these disadvantages associated with conventional payment artifact practices, and devised the presently disclosed solution that overcomes these disadvantages. In the solution, a multicard is established, which is a payment artifact having card-specific identification information. The multicard can be accepted by retailers for paying for goods and services. One or more backend cards or payment artifacts can be linked to the multicard.
Each purchase via the multicard is actually charged to one or more of the backend cards.
A set of rules/logic can be established to determine which of the backend cards are to be charged when the multicard is used. A user interface can be provided for establishing and modifying multicard settings. Further, the management options, such as a payment option, can exist for the multicard, which minimizes management overhead for maintaining a set of backend payment artifacts linked to the multicard.
Each purchase via the multicard is actually charged to one or more of the backend cards.
A set of rules/logic can be established to determine which of the backend cards are to be charged when the multicard is used. A user interface can be provided for establishing and modifying multicard settings. Further, the management options, such as a payment option, can exist for the multicard, which minimizes management overhead for maintaining a set of backend payment artifacts linked to the multicard.
[0015] As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product.
Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit," "module" or "system."
Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit," "module" or "system."
Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
[0016] Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
[0017] A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
[0018] Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
[0019] Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions.
[0020] These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
[0021] These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
[0022] The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
[0023] FIG. 1 shows a use case for a multicard in accordance with an embodiment of the inventive arrangements disclosure herein. As shown by drawing 102, the multicard 140 can be linked to a set of 0...N backend cards 150 in accordance with a set of consumer 110 established rules 160. For example, a consumer 110 can utilize a Web site or other user interface 130 linked to the multicard 140 to establish which set of back-end cards 150 are associated with the multicard 140. The Web site or user interface 130 can also establish usage rules 160 and consumer specified constraints 142 and alerts 143 for the multicard 140.
[0024] The user interface 130 can take a variety of forms. In contemplated embodiments, a consumer 110 can use a telephone interface , can interact with a customer service representative of the multicard, or can use some other communication means (e.g., postal mail, email to establish multi-card configuration settings) in lieu or in addition to the Web site described herein.
[0025] In the use-case, the backend cards 150 can include a personal VisaTM card 152, an American ExpressTM 153, a prepaid store card 154, a debit card 155, a rewards-incurring (rewards are also referred to as perks, herein) personal credit card 156, a membership card 157 that provides a discount on purchases for a specific vender, and the like. Any quantity and type of payment artifacts can be accommodated as backend cards 150, which can include for example bank accounts, internet payment sources (PayPalTM, Google WalletTm, Google Check-outTm), and other non-traditional fund sources.
Each of the backend cards 150 can be linked to a backend payment account 171.
Additionally, a set of usage rules 160 can be established for each of the backend cards 150.
Each of the backend cards 150 can be linked to a backend payment account 171.
Additionally, a set of usage rules 160 can be established for each of the backend cards 150.
[0026] The usage rules 160 can determine which of the backend cards 150 are to be used as a funding source for purchases made via the multicard 140. Sample usage rules include, but are not limited to, setting a backend card 152 as a default payment card 162, associating a back-end card 153 for purchases made for a business 163, associating a back-end card 154 for purchases with a specific retailer 164, determining which backend card 155, 156 to utilize based on a computed incentive value 165, 166, and using a backend card 157 in cooperation with another card (152-156) for retailer specific purchases 167. Rules 160, constraints 142, and alerts 143 can be of arbitrary complexity from rudimentary to highly complex depending on implementation choices for embodiments of the disclosure.
[0027] Diagram 104 shows a usage situation for the multicard 140.
Specifically, a consumer 110 provides the multicard 140 to a retailer for a purchase 122 of a good or service. The consumer 110 receives the goods or service in return for payment provided via the multicard 140. In one embodiment, the payment is sent to a retailer 120 account from a multicard funding source or multicard processing center/system/server 170. The multicard processing system 170 can utilize any of a set of backend payment accounts 171 for the funds that it provides to the retailer account 124. The back-end accounts 171 can include an account that corresponds to each of the back-end cards 150. For example, account 172 can correspond to an account for backend card 152, account 173 can correspond to an account for back-end card 153, account 174 can correspond to an account for backend card 154, account 175 can correspond to an account for backend card 155, account 176 can correspond to an account for backend card 156.
Additionally, it is possible that one or more back-end cards 150 are not directly linked to a payment account, as it the case with the member's card 157. Member's card 157 is not a fund source per se, but is a card that is used to receive a discount on a purchase and is therefore able to be combined with another backend card 152-156, which is linked to a backend account 172-176.
Specifically, a consumer 110 provides the multicard 140 to a retailer for a purchase 122 of a good or service. The consumer 110 receives the goods or service in return for payment provided via the multicard 140. In one embodiment, the payment is sent to a retailer 120 account from a multicard funding source or multicard processing center/system/server 170. The multicard processing system 170 can utilize any of a set of backend payment accounts 171 for the funds that it provides to the retailer account 124. The back-end accounts 171 can include an account that corresponds to each of the back-end cards 150. For example, account 172 can correspond to an account for backend card 152, account 173 can correspond to an account for back-end card 153, account 174 can correspond to an account for backend card 154, account 175 can correspond to an account for backend card 155, account 176 can correspond to an account for backend card 156.
Additionally, it is possible that one or more back-end cards 150 are not directly linked to a payment account, as it the case with the member's card 157. Member's card 157 is not a fund source per se, but is a card that is used to receive a discount on a purchase and is therefore able to be combined with another backend card 152-156, which is linked to a backend account 172-176.
[0028] Diagram 106 shows a repayment situation for charges incurred using the multicard 140. The consumer 110 can utilize the multicard Web site or other user interface 130 to receive an outstanding balance invoice 180. The invoice 180 can indicate a minimum monthly balance owed 182, an interest charge incurred 184 or that will be incurred due to an outstanding balance 188, an amount of rewards, perk, or incentive value received 186, an outstanding balance 188, and other such data pertinent to the multicard 140. The overall amounts can be broken down by backend card 150 in one embodiment, as shown.
[0029] The consumer 110 can pay or schedule payment via invoice 180 screen in one embodiment. Various non-conventional options can be provided to the consumer 110 for payment, which are designed to maximize benefits to the consumer 110 and/or minimize costs incurred through the set of backend cards 152-157. For example, a consumer 110 can be permitted to repay a portion of a balance owned on one back-end card 150 with another, different back end card 150. Such "rotating payments"
can be useful in avoiding or minimizing interest charges and/or to maximize benefits/perks from the various back-end cards 150. Thus, a consumer 110 is not only provided a single, convenient invoice 180 for managing the overhead of multiple band-end cards 150.
Management of overhead can include tools for maximizing the consumer's benefit while minimizing consumer's cost.
can be useful in avoiding or minimizing interest charges and/or to maximize benefits/perks from the various back-end cards 150. Thus, a consumer 110 is not only provided a single, convenient invoice 180 for managing the overhead of multiple band-end cards 150.
Management of overhead can include tools for maximizing the consumer's benefit while minimizing consumer's cost.
[0030] Before elaborating further on the multicard disclosed herein, a number of points in its regard should be emphasized to clarify advantages and flexibility of the multicard as detailed herein. Concepts addressed by embodiments of the disclosure include management of complexity, information obscuring, optimization of consumer value, minimization of consumer costs, lock-in prevention, accounting/reporting advantages, and the like.
[0031] The management of complexity refers to an ability of a user to simplify use and management of a set of backend cards 150 by being able to treat them as a single card, the multicard 140. Normal management overhead, which grows with each backend card 150 can be managed through tools, user interfaces, reports, and the like of the multicard 140. Thus, a consumer 110 can effectively manage an arbitrarily large set of payment artifacts or backend cards 150 while incurring management overhead commiserate with that of managing a single card, in this case the multicard 140.
[9032] Information obscuring refers to a fact that embodiments the multicard 140 permit backend cards 150 to be used, without any information of the backend cards 150 being provided to a retailer 120. Further, retailer 120 specifics can be hidden from the providers of the backend cards 150. One advantage of this obscuring is that a consumer 110 can change backend cards 150 used to pay for reoccurring bills (e.g., monthly charges) without changing information provided to the retailer 120. Similarly, user identity and confidentiality can be preserved (by the multicard 140 protecting identity, address, and other personal information of the consumer 110), which may not be possible when using backend cards 150, which each have different confidentiality and disclosure standards for conveying information to the retailers 120.
[0033] Optimization of consumer value refers to an ability to select which of the business cards 150 are to be charged for purchases with the retailer 120 to maximize received perks. These perks can be received from the various providers of the backend cars 150, where perks can vary based on usage specifics. Perks and their accumulation can be earned through complex rules, which are difficult for consumers 110 to manage, yet which can be automatically managed and optimized through use of the rules 160.
[0034] Minimization of consumer costs refers to an ability to ensure consumers 110 pay a minimum of interest and fees for the use of the backend cards 150 and/or interest owed for balances maintained on the backend accounts 171, which can be based on due dates, and other factors. Consumers 110 can input (via user interface 130) forecasted payment amounts verses balances to be maintained, which can help the multicard processing system 170 determine an optimal distribution of debt across the set of bank cards 150.
[0035] Lock-in prevention refers to an ability of the disclosure to add and remove backend cards 150 with relative ease. This permits consumers 110 to take advantage of special incentive offers on new backend cards 150, which may be discarded when their terms are no longer beneficial relative to other ones of the backend cards 150 in the set.
Reports and tools provided through a user interface 130 can even help a consumer 110 plan which backend cards 150 should be maintained, discarded, or acquired based on their relative advantages and disadvantages as determined by the terms of each of the backend cards 150.
[0036] Accounting/reporting advantages of the disclosure refers to an ability to be able to view, group, predict, and change payment charges of the entire set of backend cards 150 through a single interface. It is common for consumers 110 to forget which charges are being accrued on which backend cards over time, which is why some services provide discounts for auto-payment from a credit card. These oversights are minimized through the multicard, as an easily digestible and comprehensive report of charges against a set of backend cards 150 are reported to the consumer 110.
[0037] FIG. 2 illustrates a multicard payment artifact in accordance with an embodiment of the disclosure. The multicard payment artifact 210 can include a graphic 212 printed on the front and/or back of the card 210. An optional graphic 215 can be part of graphic 212. Graphic 215 can indicates a set of systems that the multicard is accepted by. For example, the graphic can indicate MasterCardTM, VisaTM, DiscoverTM, American ExpressTM, debit, and gift card, in one embodiment. The graphic 215 can also be one specific to the multicard 210. The graphic 212 can also optionally include a photograph 214 of an authorized user, a set of numbers (which represent the access number of the multicard.
[0038] The backside 220 of the multicard can include a signature section, indicia of systems that accept the multicard, and a storage medium 216. The storage medium 216 can be one within which access information needed for utilizing the credit value is stored. Commonly, component 216 is implemented as a magnetic strip, which contains digitally encoded identification information for accessing the credit value.
Component 216 can also (or alternatively include) a barcode, a radio frequency identification (RFID) storage region, a printed card number (with CCV for example), and the like.
[0039] It should be noted, that the multicard 210 can conform to industry standards established for payment artifacts. For example, in one embodiment, the multicard 210 can conform with ISO/IES 7810 for identification cards, and specifically to the ID-1 format that is commonly used for bank cards. The ID-1 format specifies a size of 85.60 x 53.98 mm (3.370 x 2.125 in) for a payment artifact, which can be a form factor used for the multicard 210. Additionally, the multicard 210 can conform to the ISO/IEC 7813, ISO/IEC 7811, and/or ISO/IEC 7816 standards. Specifically, ISO/IEC
7813 defines additional characteristics of ID-1 plastic banking cards, for example a thickness of 0.76 mm and corners rounded with a radius of 3.18 mm. ISO/IEC
defines traditional techniques for recording data on ID-1 identification cards, namely embossed characters and several different magnetic recording formats. ISO/IEC
defines ID-1 identification cards with an embedded chip (smartcard) and contact surfaces for power, clock, reset and serial-data signals.
[0040] The multicard 210 construction and form factor is not necessarily limited to the above in all contemplated embodiments. That is, the disclosure acknowledges that many alternative form factors exist for credit cards, reward cards, and the like, such as a small key-chain form factor. The multicard 210 can be provided in any of these form factors (in addition to the standard ones). Some contemplated form-facts relate to a digital-only factor, where the multicard is stored digitally upon a consumer electronic device, such as a smartphone. The multi-card can also conform to near field transmissions standards, such as those used for Google WalletTM. A set of devices that are able to utilize the multicard, can be referred to herein as usage artifacts for the multicard.
[0041] In one contemplated embodiment (shown as embodiment 240) a consumer can access the credit value of the multicard using his/her mobile device 242.
For example, an AndroidTM based phone can include a gift card application, which enables credit values from the multicard to be utilized for purchases. In one embodiment, purchases can be conducted via a retailer's Web site (straight from an internet-enabled browser of device 242.). In one embodiment, the device 242 can display or transmit a code including a bar code, which a point of sale device of the retailer can read, which causes credit value to be utilized during a commerce transaction.
[0042] In point of sale embodiment 250, a point of sale device 252 can be utilized to conduct market transactions. For example, a person can initiate the commerce transaction and pay by a multicard via a point of sale device 252 (e.g., card reader). .
[0043] Web plug-in embodiment 260 is similar to embodiment 250, in that the market transaction occurs at approximately the time (or as part of) the commerce transaction. In embodiment 260, however, the commerce transaction is an e-commerce transaction occurring via a Web interface, such as a browser. A plug-in 262 (e.g., a client-side or server-side software module) can perform the programmatic actions that trigger the use of credit value of the multicard for the e-commerce transaction instead of "cash". The "cash" can represent negotiable funds from a back-end account, such as a credit card account, a debit account, a bank account, a PayPa1TM or Google CheckoutTM
account, and the like.
[0044] FIG. 3 shows a schematic diagram of a system 300 within which a multicard 310 is used in accordance with an embodiment of the inventive arrangements disclosed herein. System 300 is not to be construed as limiting, and other arrangements and derivatives are contemplated.
[0045] System 300 includes a multicard 310 having access information for a credit value encoded within a storage medium such as a mag strip, RFID, etc.
The storage system on multicard 310 may also include other attributes such as a card identifier, an expiration data, and the like. The multicard 310 can be a physical artifact, which can interface with card processing device(s) 320. The processing devices 320 can include an artifact reader 322. The card processing device(s) 320 can be located within a retailer storefront, a secondary market storefront or kiosk, and the like.
Thus, a card processing device(s) 320 can be included in retailer system 330, buyer device or usage artifact 340.
[0046] The retailer system 330 can be a system where a commercial transaction between a consumer and the corresponding retailer is conducted. For example, the system 330 can include cash registers, an electronic commerce site for a retailer, a retailer's kiosk or self-service checkout machine, and the like.
[0047] A usage artifact 340 can represent a device, card, or system that a consumer is able to utilize to interact with a card processing device 320 of a retailer. The usage artifact 340, for example an electronic wallet application/device, can be a plug-in/application/computer through which e-commerce purchases are completed.
Thus, a mobile phone (with a suitable app installed) can be a usage artifact 340 (which substitutes for a physical payment artifact or card). Another usage artifact 340 can be a telephone (assuming purchases with the multicard can be completed by providing a number of the multicard, an expiration data, a credit card verification (CCV) number, and/or the like.
[0048] A backend card system 370 can represent a system of a backend card provider used for charging value to a backend card, for approving retail transactions and purchases with a backend card, and the like. Each backend cad system can have an associated data store 371 for maintaining data for that system 370. As an example, for a backend VisaTM card, the backend card system 370 can be a VisaTM processing, support, accounting, system. Each of the different backend cards can have a corresponding backend card system 370 associated with them. Compensation to the backend system 370 can be provided from a payment source 380 of the consumer or card holder and/or from the multicard processing system 350 (which may have received a payment from one or more payment source 380).
[0049] Each payment source 380 can represent a funding source for a consumer to pay bills incurred through using the multicard 310. Each payment source 380 can be associated with a data store 381 for data of the payment source 380. Payment sources 380 can include personal bank accounts, corporate bank accounts, processing systems for cash payments, accounts linked to backend cards of the consumer having the multicard, or combinations, derivatives, and alternatives thereof.
[0050] The multicard processing system 350 is a system that supports the multicard 310. The system 350 can have an associated data store 351 for maintaining related data. System 350 can support or serve a user interface (e.g., interface 130) through which users interact. System can interact with card processing devices 320 and can provide authorization for purchases. In one embodiment, system 350 can directly convey funds to the retailer system 330. In another embodiment, system 350 can facilitate the transfer of funds from a set of one or more backend card systems 370 to the retailer system 330 for purchases made through the multicard 310. System 350 can include a constraint manager 352, an alert manager 353, a perk valuator 354, a cost valuator 356, a payment manager 358, and/or other modules, functional units, components.
[0051] The constraint manager 352 handles constraints established for usages of the multicard 310 and/or linked backend cards. The constraints 352 can be user configurable. Constraints 352 can limit usage amounts on specific products, cities, retailers, purchase types, and/or can establish temporal limitations on usage.
[0052] The alert manager 353 can convey a set of one or more messages to a consumer or other user responsive to activity of the multicard 310. The alerts can be user configurable. Further, one or more of the alerts can require include prompts for confirming multicard activities, which may not be processed until the prompts are responded to. Alerts can be provided to an accountant, to a business finance center (for corporate uses of the multicard 310, for example), to retailers and the like.
[0053] The perk valuator 354 can calculate a value of a perks provided for using one or more backend systems. Perks can include frequent flier miles, cash-back, gas-back, purchasing credits, and the like. Perk valuator 354 permits a consumer or other authorized user to define values for specific perks. In one embodiment, perk value 354 can be automatically defined by an independent entity.
[0054] The cost valuator 356 can calculate a cost for using a backend card and/or for maintaining a balance within a backend card account. These costs can vary over time.
Further, different types of balances maintained on different cards can have varying costs ¨ all of which can be tracked, calculated, and managed by the cost valuator 356.
[0055] The payment manager 358 can centrally manage payments for balances against the set of backend cards and for the multicard 310. Payment manager 358 can accept payments from a consumer specified payment source 380, which is applied to the balance or set of balances incurred through use of the multicard 310.
[0056] Each of device 320, system 330, artifact 340, system 250, system 370, and source 380 can include one or more computing devices that execute computer program instructions that perform a set of one or more functions. Each computing device can include one or more processors, and one or more memories. Computer program instructions stored in the memories are able to be executed by the one or more processors.
The computer program instructions can include software, firmware, and logic encoded in a digital circuit.
[0057] Each of the illustrated systems can be connected to each other via a network 305. Network 305 can include any hardware/software/and firmware necessary to convey data encoded within carrier waves. Data can be contained within analog or digital signals and conveyed though data or voice channels. Network 305 can include local components and data pathways necessary for communications to be exchanged among computing device components and between integrated device components and peripheral devices. Network 305 can also include network equipment, such as routers, data lines, hubs, and intermediary servers which together form a data network, such as the Internet. Network 305 can also include circuit-based communication components and mobile communication components, such as telephony switches, moderns, cellular communication towers, and the like. Network 305 can include line based and/or wireless communication pathways.
[0058] The various computing devices and artifacts of system 300 can be linked to (or can include) one or more data stores, such as data store 351, 371, and 381. Each data store can be physically implemented within any type of hardware including, but not limited to, a magnetic disk, an optical disk, a semiconductor memory, a digitally encoded plastic memory, a holographic memory, or any other recording medium. Each of the data stores can be a stand-alone storage unit as well as a storage unit formed from a plurality of physical devices. Additionally, information can be stored within the data stores in a variety of manners. For example, information can be stored within a database structure or can be stored within one or more files of a file storage system, where each file may or may not be indexed for information searching purposes. Further, the data stores can utilize one or more encryption mechanisms to protect stored information from unauthorized access.
[0059] FIG. 4 is a flow chart for a method 400 for configuring setting of a multicard via a user interface in accordance with an embodiment of the disclosure. The user interface can take any number of forms including, but not limited to, a graphical user interface (GUI), a voice user interface (VUI), a telephony user interface, a multimodal interface, a human-to-human or customer service agent assisted interface, and the like.
Further, when implemented as a GUI for a computing device, the user interface can be a Web interface executing within a browser, a rich intemet application, an app for a mobile device (e.g., smart phone, tablet, home internet appliance), a kiosk interface, a point-of-sale interface, and the like. User interface details can vary from implementation to implementation based on configuration choices. Not all features expressed herein need be implemented for each embodiment, and not all features implemented are necessarily expressed herein.
[0060] Turning to method 400 as expressed by FIG. 4, a user interface for the multicard can be initiated in step 410. In step 412, a user can be authenticated, such as through a user identifier and password. Biometric input (e.g., speaker identity determination via voice, image recognition, finger print, etc.), device or card specific input (e.g., device key or other device specific identifier), and/or personal information (e.g., "what is your favorite pet", "what school did you graduate from", etc.) can be used in addition to or as an alternative to a user provided identifier and password. If a user is not properly authenticated the method 400 can end. When authentication is successful, the method 400 can progress beyond step 412.
[0061] In step 414, a new backend card to be linked to the multicard may or may not exist. If so, the method progresses to step 416, where back-end card details are entered. These details can include a card number, card type, expiration date, verification code information, billing information, digitally encoded information (via magnetic strip, or other storage medium), provider identification information, usage constraints (max per purchase limit, daily limit), remuneration specifics (interest rate, payment agreement, etc.), and the like. In one embodiment, this information can be manually entered. In another, at least a portion of the information can be automatically acquired from a network source (e.g., the back-end card provider or a data warehouse maintaining information for multiple back-end card providers), after being provided key information sufficient to initiate a search for this detailed information. In one embodiment, an auto-update function can be implemented, such that when any of the back-end card specific information changes, these changes are automatically conveyed to the multicard database so that setting of the back-end card can be automatically updated.
[0062] In step 418, usage rules (specific to a user or a consumer) can be entered for the back-end card. In optional step 419, perk evaluation criteria can be input for calculating a value of a set of perks that are provided for using the back-end card. For example, if a perk is additional frequent flier miles, a value of these miles relative to a baseline (such as cash) is entered during step 419. Similarly, a perk for "interest free delayed repayment for a period" is assigned a value relative to the baseline (such as a present value of cash offset verses the future value of cash). In step 420, a set of alerts and/or alert criteria can be entered. These alerts can announce to one or more people, which may not be the consumer, whenever the multicard is used, or when multicard settings are changed. An optional confirmation action can be performed in step 422.
Confirmation actions can include, for example, feedback from a known device or address that the changes have been approved. Instead of (or in addition to) a confirmation action, a notification action (such as mailing a consumer of a change) can occur. In step 424, the backend card can be activated, after which it is linked to the multicard. If additional cards are to be entered, the method can loop from step 426 to step 416.
[0063] In no new back-end cards are to be entered/linked to a multicard, the method 400 can progress to step 428, where existing backend cards can be edited. If there are edits for an existing backend card, a card identifier for the backend card can be provided. In step 430, existing backend card details, rules, and/or alerts can be adjusted.
Edits include removing a backend card so that it is no longer linked to the multicard.
Additionally, temporary enablement/disablement (for a time period, for example) conditions can be applied during the edits. A confirmation action can be optionally performed in step 432. Edits can be applied in step 434. If there are additional edits to other backend cards, the method can loop from step 436 to step 428.
[0064] If no edits are needed, one or more multicard usage artifacts can be enabled or disabled, as shown by step 438. A multicard usage artifact represents a device, software plug-in, point-of-sale mechanism, or physical artifact that is able to be utilized to charge amounts to the multicard. Common (non-limiting) examples of usage artifacts include a Web plug-in for using a payment artifact (e.g., PayPa1TM, Google CheckoutTM) and a mobile phone e-wallet. Each of the usage artifacts can be selectively enabled/disabled for the multicard. In step 440, an identifier for the usage artifact can be provided. In step 442, an enablement state of that usage artifact can be changed, per user input/configuration selections. In step 444, enablement constraints for that usage artifact (and only that usage artifact) can be entered. For example, a constraint on usage can be different from a mobile phone (e-Wallet usage) than for a Web plug-in, than for usages where the multicard is physically presented. A confirmation action can be optionally performed in step 446. The usage artifact changes can be applied in step 448.
Additional changes to usage artifact settings can be accommodated by looping from step 450 to step 440.
[0065] If no additional changes to usage artifacts are needed, the method 400 can progress to step 452, where changes to usage constraints for the multicard are able to be made. Constraints to the multicard are independent of any specific usage artifact.
Multicard level constraints can be entered or modified in step 454. An arbitrary level of complexity can be implemented at this step. For example, multicard level constraints can limit purchases of a specific type or category, can limit purchases within a specific time period, can limit purchases within a specific city, can limit purchases for a specific event or project, and the like. In step 456, specific constraints for backend cards (or even sets of backend cards) can be established. In step 460, a confirmation action can be optionally performed. In step 462, the changes to constraints can be applied. If no additional changes are needed to multicard settings, the method can end, as shown by step 464.
Otherwise, additional changes to the settings can be made (including setting changes not shown by the method 400), until ultimately all desired changes are made and the method 400 completes (step 464).
[0066] FIG. 5 provides flowcharts for usage of the multicard in accordance with embodiment of the disclosure. Process 510 shows a flowchart for a general usage situation. Process 510 can begin in step 520, where a usage artifact for a multicard can be provided to a retailer for a purchase. In step 522, a point of sale (POS) or retail processing system receives multicard usage information. This information can include an access number, CCV number, information from an internal storage medium (e.g., medium 216) and the like. In step 524, the POS/retail processing system can send a request to a multicard processing system for approval of the purchase.
[0067] In step 526, the multicard processing system can evaluate the payment request in light of previously established constraints imposed on the multicard and/or linked payment cards. In step 528, the multicard system can approve/deny payment requests and can send a response message to the POS and/or retail processing system. In step 530, the POS and/or retail processing system can approve or deny the purchase.
[0068] In various embodiment, the multicard processing system can function as a standard processing system for a payment artifact, where it possesses decision making and request handling authority (without having to interact at the time with backend card processing systems). This situation is represented by delayed processing embodiment 559. In embodiment 559, after a retail sale has been completed (which was independently processed by the multicard processing system), a request can be sent to start processing actions with one or more backend card systems, as shown by step 560.
In step 562, the multicard processing system can determine what backend cards to use for the already completed purchase. In step 564, the processing systems of the selected backend cards can be sent the charges for the allocated portion of the completed purchase. If any of the backend cards refuse the attempted charges, a fall-over action can occur, where another of the backend cards is charged. After all charges from the purchase are processed and conveyed to processing systems of backend cards, multicard records can be updated, as shown by step 566.
[0069] In embodiment 540, the multicard processing center can function as a real-time proxy. That is, all charges for a purchase are actually conveyed to one or more backend card processing systems, even though the retailers system interacts only with the multicard processing system. Embodiment 540 can begin in step 542, when the multicard processing system receives a request. In step 544, a set of backend cards to be used for the purchase can be determined. In step 546, requests to one or more backend card services can be conveyed to suitable backend card processing systems.
Charges to these backend card processing systems can be concurrently applied. In step 548, results from the backend card processing actions can be received.
[0070] One or more of these charges/requests may be refused by the backend processing system. In this case, the multicard processing system can adjust the selected backend cards (in an attempt to find a backend card that does not refuse the attempted charge), as shown by step 550. In step 552, approval/denial messages can be received and handled by the multicard processing system. In step 554, an approval/denial message (or response) can be conveyed form the multicarcl processing system to a retailer system.
In step 556, multicard usage records can be updated.
[0071] The flowchart and block diagrams in the FIGs. 1-5 illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
[9032] Information obscuring refers to a fact that embodiments the multicard 140 permit backend cards 150 to be used, without any information of the backend cards 150 being provided to a retailer 120. Further, retailer 120 specifics can be hidden from the providers of the backend cards 150. One advantage of this obscuring is that a consumer 110 can change backend cards 150 used to pay for reoccurring bills (e.g., monthly charges) without changing information provided to the retailer 120. Similarly, user identity and confidentiality can be preserved (by the multicard 140 protecting identity, address, and other personal information of the consumer 110), which may not be possible when using backend cards 150, which each have different confidentiality and disclosure standards for conveying information to the retailers 120.
[0033] Optimization of consumer value refers to an ability to select which of the business cards 150 are to be charged for purchases with the retailer 120 to maximize received perks. These perks can be received from the various providers of the backend cars 150, where perks can vary based on usage specifics. Perks and their accumulation can be earned through complex rules, which are difficult for consumers 110 to manage, yet which can be automatically managed and optimized through use of the rules 160.
[0034] Minimization of consumer costs refers to an ability to ensure consumers 110 pay a minimum of interest and fees for the use of the backend cards 150 and/or interest owed for balances maintained on the backend accounts 171, which can be based on due dates, and other factors. Consumers 110 can input (via user interface 130) forecasted payment amounts verses balances to be maintained, which can help the multicard processing system 170 determine an optimal distribution of debt across the set of bank cards 150.
[0035] Lock-in prevention refers to an ability of the disclosure to add and remove backend cards 150 with relative ease. This permits consumers 110 to take advantage of special incentive offers on new backend cards 150, which may be discarded when their terms are no longer beneficial relative to other ones of the backend cards 150 in the set.
Reports and tools provided through a user interface 130 can even help a consumer 110 plan which backend cards 150 should be maintained, discarded, or acquired based on their relative advantages and disadvantages as determined by the terms of each of the backend cards 150.
[0036] Accounting/reporting advantages of the disclosure refers to an ability to be able to view, group, predict, and change payment charges of the entire set of backend cards 150 through a single interface. It is common for consumers 110 to forget which charges are being accrued on which backend cards over time, which is why some services provide discounts for auto-payment from a credit card. These oversights are minimized through the multicard, as an easily digestible and comprehensive report of charges against a set of backend cards 150 are reported to the consumer 110.
[0037] FIG. 2 illustrates a multicard payment artifact in accordance with an embodiment of the disclosure. The multicard payment artifact 210 can include a graphic 212 printed on the front and/or back of the card 210. An optional graphic 215 can be part of graphic 212. Graphic 215 can indicates a set of systems that the multicard is accepted by. For example, the graphic can indicate MasterCardTM, VisaTM, DiscoverTM, American ExpressTM, debit, and gift card, in one embodiment. The graphic 215 can also be one specific to the multicard 210. The graphic 212 can also optionally include a photograph 214 of an authorized user, a set of numbers (which represent the access number of the multicard.
[0038] The backside 220 of the multicard can include a signature section, indicia of systems that accept the multicard, and a storage medium 216. The storage medium 216 can be one within which access information needed for utilizing the credit value is stored. Commonly, component 216 is implemented as a magnetic strip, which contains digitally encoded identification information for accessing the credit value.
Component 216 can also (or alternatively include) a barcode, a radio frequency identification (RFID) storage region, a printed card number (with CCV for example), and the like.
[0039] It should be noted, that the multicard 210 can conform to industry standards established for payment artifacts. For example, in one embodiment, the multicard 210 can conform with ISO/IES 7810 for identification cards, and specifically to the ID-1 format that is commonly used for bank cards. The ID-1 format specifies a size of 85.60 x 53.98 mm (3.370 x 2.125 in) for a payment artifact, which can be a form factor used for the multicard 210. Additionally, the multicard 210 can conform to the ISO/IEC 7813, ISO/IEC 7811, and/or ISO/IEC 7816 standards. Specifically, ISO/IEC
7813 defines additional characteristics of ID-1 plastic banking cards, for example a thickness of 0.76 mm and corners rounded with a radius of 3.18 mm. ISO/IEC
defines traditional techniques for recording data on ID-1 identification cards, namely embossed characters and several different magnetic recording formats. ISO/IEC
defines ID-1 identification cards with an embedded chip (smartcard) and contact surfaces for power, clock, reset and serial-data signals.
[0040] The multicard 210 construction and form factor is not necessarily limited to the above in all contemplated embodiments. That is, the disclosure acknowledges that many alternative form factors exist for credit cards, reward cards, and the like, such as a small key-chain form factor. The multicard 210 can be provided in any of these form factors (in addition to the standard ones). Some contemplated form-facts relate to a digital-only factor, where the multicard is stored digitally upon a consumer electronic device, such as a smartphone. The multi-card can also conform to near field transmissions standards, such as those used for Google WalletTM. A set of devices that are able to utilize the multicard, can be referred to herein as usage artifacts for the multicard.
[0041] In one contemplated embodiment (shown as embodiment 240) a consumer can access the credit value of the multicard using his/her mobile device 242.
For example, an AndroidTM based phone can include a gift card application, which enables credit values from the multicard to be utilized for purchases. In one embodiment, purchases can be conducted via a retailer's Web site (straight from an internet-enabled browser of device 242.). In one embodiment, the device 242 can display or transmit a code including a bar code, which a point of sale device of the retailer can read, which causes credit value to be utilized during a commerce transaction.
[0042] In point of sale embodiment 250, a point of sale device 252 can be utilized to conduct market transactions. For example, a person can initiate the commerce transaction and pay by a multicard via a point of sale device 252 (e.g., card reader). .
[0043] Web plug-in embodiment 260 is similar to embodiment 250, in that the market transaction occurs at approximately the time (or as part of) the commerce transaction. In embodiment 260, however, the commerce transaction is an e-commerce transaction occurring via a Web interface, such as a browser. A plug-in 262 (e.g., a client-side or server-side software module) can perform the programmatic actions that trigger the use of credit value of the multicard for the e-commerce transaction instead of "cash". The "cash" can represent negotiable funds from a back-end account, such as a credit card account, a debit account, a bank account, a PayPa1TM or Google CheckoutTM
account, and the like.
[0044] FIG. 3 shows a schematic diagram of a system 300 within which a multicard 310 is used in accordance with an embodiment of the inventive arrangements disclosed herein. System 300 is not to be construed as limiting, and other arrangements and derivatives are contemplated.
[0045] System 300 includes a multicard 310 having access information for a credit value encoded within a storage medium such as a mag strip, RFID, etc.
The storage system on multicard 310 may also include other attributes such as a card identifier, an expiration data, and the like. The multicard 310 can be a physical artifact, which can interface with card processing device(s) 320. The processing devices 320 can include an artifact reader 322. The card processing device(s) 320 can be located within a retailer storefront, a secondary market storefront or kiosk, and the like.
Thus, a card processing device(s) 320 can be included in retailer system 330, buyer device or usage artifact 340.
[0046] The retailer system 330 can be a system where a commercial transaction between a consumer and the corresponding retailer is conducted. For example, the system 330 can include cash registers, an electronic commerce site for a retailer, a retailer's kiosk or self-service checkout machine, and the like.
[0047] A usage artifact 340 can represent a device, card, or system that a consumer is able to utilize to interact with a card processing device 320 of a retailer. The usage artifact 340, for example an electronic wallet application/device, can be a plug-in/application/computer through which e-commerce purchases are completed.
Thus, a mobile phone (with a suitable app installed) can be a usage artifact 340 (which substitutes for a physical payment artifact or card). Another usage artifact 340 can be a telephone (assuming purchases with the multicard can be completed by providing a number of the multicard, an expiration data, a credit card verification (CCV) number, and/or the like.
[0048] A backend card system 370 can represent a system of a backend card provider used for charging value to a backend card, for approving retail transactions and purchases with a backend card, and the like. Each backend cad system can have an associated data store 371 for maintaining data for that system 370. As an example, for a backend VisaTM card, the backend card system 370 can be a VisaTM processing, support, accounting, system. Each of the different backend cards can have a corresponding backend card system 370 associated with them. Compensation to the backend system 370 can be provided from a payment source 380 of the consumer or card holder and/or from the multicard processing system 350 (which may have received a payment from one or more payment source 380).
[0049] Each payment source 380 can represent a funding source for a consumer to pay bills incurred through using the multicard 310. Each payment source 380 can be associated with a data store 381 for data of the payment source 380. Payment sources 380 can include personal bank accounts, corporate bank accounts, processing systems for cash payments, accounts linked to backend cards of the consumer having the multicard, or combinations, derivatives, and alternatives thereof.
[0050] The multicard processing system 350 is a system that supports the multicard 310. The system 350 can have an associated data store 351 for maintaining related data. System 350 can support or serve a user interface (e.g., interface 130) through which users interact. System can interact with card processing devices 320 and can provide authorization for purchases. In one embodiment, system 350 can directly convey funds to the retailer system 330. In another embodiment, system 350 can facilitate the transfer of funds from a set of one or more backend card systems 370 to the retailer system 330 for purchases made through the multicard 310. System 350 can include a constraint manager 352, an alert manager 353, a perk valuator 354, a cost valuator 356, a payment manager 358, and/or other modules, functional units, components.
[0051] The constraint manager 352 handles constraints established for usages of the multicard 310 and/or linked backend cards. The constraints 352 can be user configurable. Constraints 352 can limit usage amounts on specific products, cities, retailers, purchase types, and/or can establish temporal limitations on usage.
[0052] The alert manager 353 can convey a set of one or more messages to a consumer or other user responsive to activity of the multicard 310. The alerts can be user configurable. Further, one or more of the alerts can require include prompts for confirming multicard activities, which may not be processed until the prompts are responded to. Alerts can be provided to an accountant, to a business finance center (for corporate uses of the multicard 310, for example), to retailers and the like.
[0053] The perk valuator 354 can calculate a value of a perks provided for using one or more backend systems. Perks can include frequent flier miles, cash-back, gas-back, purchasing credits, and the like. Perk valuator 354 permits a consumer or other authorized user to define values for specific perks. In one embodiment, perk value 354 can be automatically defined by an independent entity.
[0054] The cost valuator 356 can calculate a cost for using a backend card and/or for maintaining a balance within a backend card account. These costs can vary over time.
Further, different types of balances maintained on different cards can have varying costs ¨ all of which can be tracked, calculated, and managed by the cost valuator 356.
[0055] The payment manager 358 can centrally manage payments for balances against the set of backend cards and for the multicard 310. Payment manager 358 can accept payments from a consumer specified payment source 380, which is applied to the balance or set of balances incurred through use of the multicard 310.
[0056] Each of device 320, system 330, artifact 340, system 250, system 370, and source 380 can include one or more computing devices that execute computer program instructions that perform a set of one or more functions. Each computing device can include one or more processors, and one or more memories. Computer program instructions stored in the memories are able to be executed by the one or more processors.
The computer program instructions can include software, firmware, and logic encoded in a digital circuit.
[0057] Each of the illustrated systems can be connected to each other via a network 305. Network 305 can include any hardware/software/and firmware necessary to convey data encoded within carrier waves. Data can be contained within analog or digital signals and conveyed though data or voice channels. Network 305 can include local components and data pathways necessary for communications to be exchanged among computing device components and between integrated device components and peripheral devices. Network 305 can also include network equipment, such as routers, data lines, hubs, and intermediary servers which together form a data network, such as the Internet. Network 305 can also include circuit-based communication components and mobile communication components, such as telephony switches, moderns, cellular communication towers, and the like. Network 305 can include line based and/or wireless communication pathways.
[0058] The various computing devices and artifacts of system 300 can be linked to (or can include) one or more data stores, such as data store 351, 371, and 381. Each data store can be physically implemented within any type of hardware including, but not limited to, a magnetic disk, an optical disk, a semiconductor memory, a digitally encoded plastic memory, a holographic memory, or any other recording medium. Each of the data stores can be a stand-alone storage unit as well as a storage unit formed from a plurality of physical devices. Additionally, information can be stored within the data stores in a variety of manners. For example, information can be stored within a database structure or can be stored within one or more files of a file storage system, where each file may or may not be indexed for information searching purposes. Further, the data stores can utilize one or more encryption mechanisms to protect stored information from unauthorized access.
[0059] FIG. 4 is a flow chart for a method 400 for configuring setting of a multicard via a user interface in accordance with an embodiment of the disclosure. The user interface can take any number of forms including, but not limited to, a graphical user interface (GUI), a voice user interface (VUI), a telephony user interface, a multimodal interface, a human-to-human or customer service agent assisted interface, and the like.
Further, when implemented as a GUI for a computing device, the user interface can be a Web interface executing within a browser, a rich intemet application, an app for a mobile device (e.g., smart phone, tablet, home internet appliance), a kiosk interface, a point-of-sale interface, and the like. User interface details can vary from implementation to implementation based on configuration choices. Not all features expressed herein need be implemented for each embodiment, and not all features implemented are necessarily expressed herein.
[0060] Turning to method 400 as expressed by FIG. 4, a user interface for the multicard can be initiated in step 410. In step 412, a user can be authenticated, such as through a user identifier and password. Biometric input (e.g., speaker identity determination via voice, image recognition, finger print, etc.), device or card specific input (e.g., device key or other device specific identifier), and/or personal information (e.g., "what is your favorite pet", "what school did you graduate from", etc.) can be used in addition to or as an alternative to a user provided identifier and password. If a user is not properly authenticated the method 400 can end. When authentication is successful, the method 400 can progress beyond step 412.
[0061] In step 414, a new backend card to be linked to the multicard may or may not exist. If so, the method progresses to step 416, where back-end card details are entered. These details can include a card number, card type, expiration date, verification code information, billing information, digitally encoded information (via magnetic strip, or other storage medium), provider identification information, usage constraints (max per purchase limit, daily limit), remuneration specifics (interest rate, payment agreement, etc.), and the like. In one embodiment, this information can be manually entered. In another, at least a portion of the information can be automatically acquired from a network source (e.g., the back-end card provider or a data warehouse maintaining information for multiple back-end card providers), after being provided key information sufficient to initiate a search for this detailed information. In one embodiment, an auto-update function can be implemented, such that when any of the back-end card specific information changes, these changes are automatically conveyed to the multicard database so that setting of the back-end card can be automatically updated.
[0062] In step 418, usage rules (specific to a user or a consumer) can be entered for the back-end card. In optional step 419, perk evaluation criteria can be input for calculating a value of a set of perks that are provided for using the back-end card. For example, if a perk is additional frequent flier miles, a value of these miles relative to a baseline (such as cash) is entered during step 419. Similarly, a perk for "interest free delayed repayment for a period" is assigned a value relative to the baseline (such as a present value of cash offset verses the future value of cash). In step 420, a set of alerts and/or alert criteria can be entered. These alerts can announce to one or more people, which may not be the consumer, whenever the multicard is used, or when multicard settings are changed. An optional confirmation action can be performed in step 422.
Confirmation actions can include, for example, feedback from a known device or address that the changes have been approved. Instead of (or in addition to) a confirmation action, a notification action (such as mailing a consumer of a change) can occur. In step 424, the backend card can be activated, after which it is linked to the multicard. If additional cards are to be entered, the method can loop from step 426 to step 416.
[0063] In no new back-end cards are to be entered/linked to a multicard, the method 400 can progress to step 428, where existing backend cards can be edited. If there are edits for an existing backend card, a card identifier for the backend card can be provided. In step 430, existing backend card details, rules, and/or alerts can be adjusted.
Edits include removing a backend card so that it is no longer linked to the multicard.
Additionally, temporary enablement/disablement (for a time period, for example) conditions can be applied during the edits. A confirmation action can be optionally performed in step 432. Edits can be applied in step 434. If there are additional edits to other backend cards, the method can loop from step 436 to step 428.
[0064] If no edits are needed, one or more multicard usage artifacts can be enabled or disabled, as shown by step 438. A multicard usage artifact represents a device, software plug-in, point-of-sale mechanism, or physical artifact that is able to be utilized to charge amounts to the multicard. Common (non-limiting) examples of usage artifacts include a Web plug-in for using a payment artifact (e.g., PayPa1TM, Google CheckoutTM) and a mobile phone e-wallet. Each of the usage artifacts can be selectively enabled/disabled for the multicard. In step 440, an identifier for the usage artifact can be provided. In step 442, an enablement state of that usage artifact can be changed, per user input/configuration selections. In step 444, enablement constraints for that usage artifact (and only that usage artifact) can be entered. For example, a constraint on usage can be different from a mobile phone (e-Wallet usage) than for a Web plug-in, than for usages where the multicard is physically presented. A confirmation action can be optionally performed in step 446. The usage artifact changes can be applied in step 448.
Additional changes to usage artifact settings can be accommodated by looping from step 450 to step 440.
[0065] If no additional changes to usage artifacts are needed, the method 400 can progress to step 452, where changes to usage constraints for the multicard are able to be made. Constraints to the multicard are independent of any specific usage artifact.
Multicard level constraints can be entered or modified in step 454. An arbitrary level of complexity can be implemented at this step. For example, multicard level constraints can limit purchases of a specific type or category, can limit purchases within a specific time period, can limit purchases within a specific city, can limit purchases for a specific event or project, and the like. In step 456, specific constraints for backend cards (or even sets of backend cards) can be established. In step 460, a confirmation action can be optionally performed. In step 462, the changes to constraints can be applied. If no additional changes are needed to multicard settings, the method can end, as shown by step 464.
Otherwise, additional changes to the settings can be made (including setting changes not shown by the method 400), until ultimately all desired changes are made and the method 400 completes (step 464).
[0066] FIG. 5 provides flowcharts for usage of the multicard in accordance with embodiment of the disclosure. Process 510 shows a flowchart for a general usage situation. Process 510 can begin in step 520, where a usage artifact for a multicard can be provided to a retailer for a purchase. In step 522, a point of sale (POS) or retail processing system receives multicard usage information. This information can include an access number, CCV number, information from an internal storage medium (e.g., medium 216) and the like. In step 524, the POS/retail processing system can send a request to a multicard processing system for approval of the purchase.
[0067] In step 526, the multicard processing system can evaluate the payment request in light of previously established constraints imposed on the multicard and/or linked payment cards. In step 528, the multicard system can approve/deny payment requests and can send a response message to the POS and/or retail processing system. In step 530, the POS and/or retail processing system can approve or deny the purchase.
[0068] In various embodiment, the multicard processing system can function as a standard processing system for a payment artifact, where it possesses decision making and request handling authority (without having to interact at the time with backend card processing systems). This situation is represented by delayed processing embodiment 559. In embodiment 559, after a retail sale has been completed (which was independently processed by the multicard processing system), a request can be sent to start processing actions with one or more backend card systems, as shown by step 560.
In step 562, the multicard processing system can determine what backend cards to use for the already completed purchase. In step 564, the processing systems of the selected backend cards can be sent the charges for the allocated portion of the completed purchase. If any of the backend cards refuse the attempted charges, a fall-over action can occur, where another of the backend cards is charged. After all charges from the purchase are processed and conveyed to processing systems of backend cards, multicard records can be updated, as shown by step 566.
[0069] In embodiment 540, the multicard processing center can function as a real-time proxy. That is, all charges for a purchase are actually conveyed to one or more backend card processing systems, even though the retailers system interacts only with the multicard processing system. Embodiment 540 can begin in step 542, when the multicard processing system receives a request. In step 544, a set of backend cards to be used for the purchase can be determined. In step 546, requests to one or more backend card services can be conveyed to suitable backend card processing systems.
Charges to these backend card processing systems can be concurrently applied. In step 548, results from the backend card processing actions can be received.
[0070] One or more of these charges/requests may be refused by the backend processing system. In this case, the multicard processing system can adjust the selected backend cards (in an attempt to find a backend card that does not refuse the attempted charge), as shown by step 550. In step 552, approval/denial messages can be received and handled by the multicard processing system. In step 554, an approval/denial message (or response) can be conveyed form the multicarcl processing system to a retailer system.
In step 556, multicard usage records can be updated.
[0071] The flowchart and block diagrams in the FIGs. 1-5 illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
Claims (20)
1. A method comprising:
providing a physical payment artifact for the purchase of goods and services, wherein the physical artifact is referred to as a multicard;
linking said multicard to a plurality of different payment artifacts referred to as backend cards, each backend card for the purchase of goods and services;
establishing a set of rules for selecting which of the plurality of different backend cards the multicard draws from for a purchase;
purchasing at least one good or service from a retailer using the multicard;
and automatically charging a set of the backend cards linked to the multicard for amounts incurred by purchasing the at least one good or service.
providing a physical payment artifact for the purchase of goods and services, wherein the physical artifact is referred to as a multicard;
linking said multicard to a plurality of different payment artifacts referred to as backend cards, each backend card for the purchase of goods and services;
establishing a set of rules for selecting which of the plurality of different backend cards the multicard draws from for a purchase;
purchasing at least one good or service from a retailer using the multicard;
and automatically charging a set of the backend cards linked to the multicard for amounts incurred by purchasing the at least one good or service.
2. The method of claim 1, wherein the automatically charging charges a plurality of different ones of the backend cards for a single purchase of a set of goods or services made using the multicard, wherein a selection of which of the backend cards of the plurality are charged for the single purchase is made based on evaluation results of the set of rules.
3. The method of claim 1, wherein said purchasing of the goods or service occurs via a point of sale device, which reads the multicard, wherein the point of sale device accepts credit cards, wherein the multicard is accepted by the point of sale device as a credit card or a debit card, wherein the backend cards that are charged for the purchasing of the good or service are never read by the point of sale device.
4. The method of claim 1, wherein the charging of the set of backend cards occurs during a retail transaction, wherein confirmation from each of the set of backend cards is received before the good or service purchase made via the multicard is completed.
5. The method of claim 1, wherein the charging of the set of backend cards occurs after a retail transaction for the purchasing of the good or service has completed.
6. The method of claim 1, further comprising:
accepting via a user interface of the multicard, a payment from a user of the multicard for purchases made via the multicard; and applying the accepted payment to the set of backend cards to pay amounts owed on the set of backend cards, wherein the user interface of the multicard is independent of any user interface used by any of the backend cards.
accepting via a user interface of the multicard, a payment from a user of the multicard for purchases made via the multicard; and applying the accepted payment to the set of backend cards to pay amounts owed on the set of backend cards, wherein the user interface of the multicard is independent of any user interface used by any of the backend cards.
7. The method of claim 1, further comprising:
receiving via a user interface of the multicard from a user of the multicard, edits, rules, and details for backend card settings for the multicard, wherein the changes to the edits, rules and details change which of the backend cards are charged when the multicard is used for purchasing a good or service, wherein the user interface of the multicard is independent of any user interface used by any of the backend cards.
receiving via a user interface of the multicard from a user of the multicard, edits, rules, and details for backend card settings for the multicard, wherein the changes to the edits, rules and details change which of the backend cards are charged when the multicard is used for purchasing a good or service, wherein the user interface of the multicard is independent of any user interface used by any of the backend cards.
8. The method of claim 1, wherein the multicard is accepted by the retailer as a first type of artifact, wherein at least one of the backend cards is charged as a second type of artifact, wherein the first type and the second types are different types selected from a group of types consisting of: a credit card, a debit card, a store charge card, and a prepaid card.
9. The method of claim 1, wherein the multicard is accepted by the retailer as a first type of artifact, wherein a plurality of different backend cards are charged for the at least one good or service, wherein at least one of the charged backend cards is charged as a second type of artifact, wherein at least one of the charged backend cards is charged as a third type of artifact, wherein the first type, the second type, and the third type are different types selected from a group of types consisting of: a credit card, a debit card, a store charge card, a prepaid card, and a user bank account.
10. The method of claim 1, wherein the purchasing of the at least one good or service is a purchasing of a plurality of discrete items, each of which are a good or a service, said method further comprising:
for each item, determining one of the plurality of different backend cards that is to be used to pay for that item in accordance with the set of rules, wherein different backend cards are used to pay for different ones of the discrete items.
for each item, determining one of the plurality of different backend cards that is to be used to pay for that item in accordance with the set of rules, wherein different backend cards are used to pay for different ones of the discrete items.
11. The method of claim 1, further comprising:
a consumer paying for charges incurred using the multicard through a user interface of a multicard processing system; and the multicard processing system applying the consumer submitted payment to balances of the different backend cards, wherein the user interface functions as a single user interface for management payment and reporting of the different backend cards.
a consumer paying for charges incurred using the multicard through a user interface of a multicard processing system; and the multicard processing system applying the consumer submitted payment to balances of the different backend cards, wherein the user interface functions as a single user interface for management payment and reporting of the different backend cards.
12. The method of claim 1, further comprising:
calculating perks received through different ones of the backend cards should each of the backend cards be used for the purchase of the at least one good or service;
for each of the different ones of the backend cards, computing a perk value based on the perks received and a valuation formula per perk assigned to each perk;
determining which of the backend cards to be charged for purchasing the at least one good or service based on which set of backend cards results in a highest computed perk value; and charging amounts for the at least one good or service to the determined backend cards to obtain perks with the highest computed perk value.
calculating perks received through different ones of the backend cards should each of the backend cards be used for the purchase of the at least one good or service;
for each of the different ones of the backend cards, computing a perk value based on the perks received and a valuation formula per perk assigned to each perk;
determining which of the backend cards to be charged for purchasing the at least one good or service based on which set of backend cards results in a highest computed perk value; and charging amounts for the at least one good or service to the determined backend cards to obtain perks with the highest computed perk value.
13. The method of claim 1, further comprising:
calculating usage costs for using and maintaining a balance on the different ones of the backend cards should each of the backend cards be used for the purchase of the at least one good or service;
for each of the different ones of the backend cards, computing a usage cost value based on the calculated usage costs;
determining which of the backend cards to be charged for purchasing the at least one good or service based on which set of backend cards results in a lowest computed usage cost; and charging amounts for the at least one good or service to the determined backend cards for the lowest computed usage cost.
calculating usage costs for using and maintaining a balance on the different ones of the backend cards should each of the backend cards be used for the purchase of the at least one good or service;
for each of the different ones of the backend cards, computing a usage cost value based on the calculated usage costs;
determining which of the backend cards to be charged for purchasing the at least one good or service based on which set of backend cards results in a lowest computed usage cost; and charging amounts for the at least one good or service to the determined backend cards for the lowest computed usage cost.
14. A computer program product comprising:
one or more computer-readable, storage devices;
program instructions, stored on at least one of the one or more storage devices, to provide a physical payment artifact for the purchase of goods and services, wherein the physical artifact is referred to as a multicard;
program instructions, stored on at least one of the one or more storage devices, to link said multicard to a plurality of different payment artifacts referred to as backend cards, each backend card for the purchase of goods and services;
program instructions, stored on at least one of the one or more storage devices, to establish a set of rules for selecting which of the plurality of different backend cards the multicard draws from for a purchase;
program instructions, stored on at least one of the one or more storage devices, to purchase at least one good or service from a retailer using the multicard; and program instructions, stored on at least one of the one or more storage devices, to automatically charge a set of the backend cards linked to the multicard for amounts incurred by purchasing the at least one good or service.
one or more computer-readable, storage devices;
program instructions, stored on at least one of the one or more storage devices, to provide a physical payment artifact for the purchase of goods and services, wherein the physical artifact is referred to as a multicard;
program instructions, stored on at least one of the one or more storage devices, to link said multicard to a plurality of different payment artifacts referred to as backend cards, each backend card for the purchase of goods and services;
program instructions, stored on at least one of the one or more storage devices, to establish a set of rules for selecting which of the plurality of different backend cards the multicard draws from for a purchase;
program instructions, stored on at least one of the one or more storage devices, to purchase at least one good or service from a retailer using the multicard; and program instructions, stored on at least one of the one or more storage devices, to automatically charge a set of the backend cards linked to the multicard for amounts incurred by purchasing the at least one good or service.
15. The computer program product of claim 14, wherein said purchasing of the goods or service occurs via a point of sale device, which reads the multicard, wherein the point of sale device accepts credit cards, wherein the multicard is accepted by the point of sale device as a credit card or a debit card, wherein the backend cards that are charged for the purchasing of the good or service are never read by the point of sale device.
16. The computer program product of claim 14, wherein the charging of the set of backend cards occurs during a retail transaction, wherein confirmation from each of the set of backend cards is received before the good or service purchase made via the multicard is completed.
17. The computer program product of claim 14, wherein the charging of the set of backend cards occurs after a retail transaction for the purchasing of the good or service has completed.
18. A computer system comprising:
one or more processors, one or more computer-readable memories and one or more computer-readable, tangible storage devices;
program instructions, stored on at least one of the one or more storage devices for execution by at least one of the one or more processors via at least one of the one or more memories, to provide a physical payment artifact for the purchase of goods and services, wherein the physical artifact is referred to as a multicard;
program instructions, stored on at least one of the one or more storage devices for execution by at least one of the one or more processors via at least one of the one or more memories, to link said multicard to a plurality of different payment artifacts referred to as backend cards, each backend card for the purchase of goods and services;
program instructions, stored on at least one of the one or more storage devices for execution by at least one of the one or more processors via at least one of the one or more memories, to establish a set of rules for selecting which of the plurality of different backend cards the multicard draws from for a purchase;
program instructions, stored on at least one of the one or more storage devices for execution by at least one of the one or more processors via at least one of the one or more memories, to purchase at least one good or service from a retailer using the multicard;
and program instructions, stored on at least one of the one or more storage devices for execution by at least one of the one or more processors via at least one of the one or more memories, to automatically charge a set of the backend cards linked to the multicard for amounts incurred by purchasing the at least one good or service.
one or more processors, one or more computer-readable memories and one or more computer-readable, tangible storage devices;
program instructions, stored on at least one of the one or more storage devices for execution by at least one of the one or more processors via at least one of the one or more memories, to provide a physical payment artifact for the purchase of goods and services, wherein the physical artifact is referred to as a multicard;
program instructions, stored on at least one of the one or more storage devices for execution by at least one of the one or more processors via at least one of the one or more memories, to link said multicard to a plurality of different payment artifacts referred to as backend cards, each backend card for the purchase of goods and services;
program instructions, stored on at least one of the one or more storage devices for execution by at least one of the one or more processors via at least one of the one or more memories, to establish a set of rules for selecting which of the plurality of different backend cards the multicard draws from for a purchase;
program instructions, stored on at least one of the one or more storage devices for execution by at least one of the one or more processors via at least one of the one or more memories, to purchase at least one good or service from a retailer using the multicard;
and program instructions, stored on at least one of the one or more storage devices for execution by at least one of the one or more processors via at least one of the one or more memories, to automatically charge a set of the backend cards linked to the multicard for amounts incurred by purchasing the at least one good or service.
19. The computer system of claim 18, wherein a charging of the set of backend cards occurs during a retail transaction, wherein confirmation from each of the set of backend cards is received before the good or service purchase made via the multicard is completed.
20. The computer system of claim 18, wherein a charging of the set of backend cards occurs after a retail transaction for the purchasing of the good or service has completed.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201113331149A | 2011-12-20 | 2011-12-20 | |
US13/331,149 | 2011-12-20 |
Publications (1)
Publication Number | Publication Date |
---|---|
CA2799237A1 true CA2799237A1 (en) | 2013-06-20 |
Family
ID=48653026
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA 2799237 Abandoned CA2799237A1 (en) | 2011-12-20 | 2012-12-19 | Multicard payment artifact for managing a set of user-owned payment artifacts |
Country Status (1)
Country | Link |
---|---|
CA (1) | CA2799237A1 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110533406A (en) * | 2019-09-04 | 2019-12-03 | 中国工商银行股份有限公司 | A kind of payment call method, apparatus and system |
US10671996B2 (en) | 2014-07-11 | 2020-06-02 | The Toronto-Dominion Bank | Systems and methods for providing pre-paid multicards |
CN117011062A (en) * | 2023-08-30 | 2023-11-07 | 广州佳新智能科技有限公司 | Bank fund payment method, system and computer equipment based on Internet |
-
2012
- 2012-12-19 CA CA 2799237 patent/CA2799237A1/en not_active Abandoned
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10671996B2 (en) | 2014-07-11 | 2020-06-02 | The Toronto-Dominion Bank | Systems and methods for providing pre-paid multicards |
CN110533406A (en) * | 2019-09-04 | 2019-12-03 | 中国工商银行股份有限公司 | A kind of payment call method, apparatus and system |
CN117011062A (en) * | 2023-08-30 | 2023-11-07 | 广州佳新智能科技有限公司 | Bank fund payment method, system and computer equipment based on Internet |
CN117011062B (en) * | 2023-08-30 | 2024-04-12 | 广州佳新智能科技有限公司 | Bank fund payment method, system and computer equipment based on Internet |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP7404154B2 (en) | System for payments via electronic wallets | |
AU2019200882B2 (en) | System and method of registering stored-value cards into electronic wallets | |
US20220270078A1 (en) | Method and system for reloading prepaid card | |
US9805362B2 (en) | Mobile devices for activating instant disposable payment cards | |
US10037526B2 (en) | System for payment via electronic wallet | |
KR101903963B1 (en) | Prepaid card with savings feature | |
US11030589B2 (en) | Hosted disbursement system | |
US20140143037A1 (en) | Systems and methods to own a free computer, a free mobile device and a free wearable device and life time warranty via the same device payment cashback | |
US20140310153A1 (en) | Systems and methods for mobile device financing | |
WO2014107594A2 (en) | System and method for providing a security code | |
EP3108428A1 (en) | Business services platform solutions for small and medium enterprises | |
CA2912066C (en) | System and method of reloading prepaid cards | |
CA2799237A1 (en) | Multicard payment artifact for managing a set of user-owned payment artifacts | |
US20140279117A1 (en) | Subscription and membership based credit card processing system | |
KR20140030615A (en) | Tax refund processing divese and method | |
JP6904636B2 (en) | Methods, computer programs and systems for secure transaction processing | |
KR101474386B1 (en) | System for Processing Payment |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
FZDE | Dead |
Effective date: 20181219 |