Methods and Systems for Managing Card Programs and Processing Card Transactions

• US 20060026073A1
• Filed: 10/24/2005
• Published: 02/02/2006
• Est. Priority Date: 10/24/2005
• Status: Abandoned Application

• Current Assignee: Edwin R. Kenny Jr, Robert A. Campbell
• Original Assignee: Edwin R. Kenny Jr, Robert A. Campbell
• Inventors: Campbell, Robert A., Kenny, Edwin R. Jr.
• Application Number:
  US11/163,590
• Publication Number:
  US 20060026073A1
• Time in Patent Office: Days
• US Class Current: 705/16
• CPC Class Codes: G06Q 20/02 involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
• CPC Class Codes: G06Q 20/04 Payment circuits
• CPC Class Codes: G06Q 20/20 Point-of-sale [POS] network systems
• CPC Class Codes: G06Q 30/0226 Incentive systems for frequent usage, e.g. frequent flyer miles programs or point systems
• CPC Class Codes: G06Q 30/0234 Rebates after completed purchase

Abstract

Methods and systems are provided for processing Card transactions. The Cards and Card Programs are configured on a Host System by a Client and transactions are received at a Host System. Issuers of Cards and their Program Groups are configured on the Host System. Acquirers of Card transactions and their Program Groups are configured on the Host System. An Issuer and Acquirer associated with singular Card transactions may or may not belong to the same Client. The Card transactions carry associated data relevant to the Card Type and transaction type captured and identified by the Host System for proper Transaction Set build and ultimate Card transaction processing based on the relevant Issuer and Acquirer set choices. A Web Interface is provided for Clients, their designees, and Cardholders.

Claims

1. A method for design, deployment, and management of Card Programs and processing Card transactions where

a. a plurality of Clients, Cards, Limits, Card Types, Issuers, Acquirers, Locations, Program Groups, Terminals, Distributors, and Agents may be configured on a Host System;

b. Clients, their designees, and Cardholders having available Web Interface user forms for input, queries, and reports;

c. Inbound Transactions may be received at the Host System from a plurality of Card transaction acquiring sources, Open Networks, Third Party Networks and Terminals;

d. Issuers and Acquirers associated with a Card transaction may or may not be of the same Client configured in the Host System database;

e. Card transaction strings arriving at the Host System for processing containing data relevant to a singular transaction, (for example date, time, transaction type, amount, Card number, and Terminal ID) are captured and parsed by the Host System for proper ultimate Card Transaction Set processing based on the relevant Client choices configured in Program Groups associated with Locations;

f. Client Card Programs are configured within the Host System database typically by Card Type, Card Limits, Locations, Program Groups, and Locations.

2. The method recited in claim 1 wherein a Card is one of many Client configured Card Types within the Host System which carry different transaction type enablement, the method further enabling a plurality of Locations enablement of Card Type transactions which are received at the Host System for unique processing.

3. The method recited in claim 2 where Locations are configured in the Host System database to allow for acceptance and issuance of specified multiple Card Types which are defined in the Host System.

4. The method recited in claim 1 wherein a Client may utilize many Card Programs by assigning transaction values to Program Group entries.

5. The method recited in claim 1 wherein an Issuer is configured in the Host System database so that the Issuer is associated with a plurality of sequential Card account number ranges for the purpose of assignment of a sequential range of Card account numbers to a specific Card Type which the Issuer Issues.

6. The method recited in claim 4 wherein Client Locations may utilize many specified Card Types to grant specific or custom functions to a range of Cards. Such functions can include gift, discount, loyalty, rebate, reward, ATM/Debit, private label, multi-Acquirer, credit, event days, custom stored value, or any other Stored Value schema the Client wishes to develop.

7. The method recited in claim 5 where a Card Type functionality and transaction values are ultimately determined by Client Location utilizing named Program Group choices.

8. The method recited in claim 5 where multiple Acquirers accept the same Card Type as is issued by an Issuer when the Acquirer and Issuer are of the same Client within the Host System allowing for a plurality of Transaction Set values at a plurality of Acquirers with a single Card Type issued by an Issuer.

9. The method recited in claim 1 wherein a Card Issuer selects Card expiration dates for a range of Cards, where the Card expiration date is encoded on the Card and is only utilized for ultimate Card exhaustion when no Card Programs can function, and also for basic Card validation purposes, never for direct validation of a Transaction Set.

10. The method recited in claim 1 wherein a Card Issuer selects Card activation and Cardholder enrollment choices at the time of issuance.

11. The method recited in claim 1 wherein a Card Issuer chooses whether Cards issued have parent and companion Card privileges at the time of issuance based on a Card issuance trust ID number tied to a companion Card issuance trust ID.

12. The method recited in claim 1 where Issuers configure Cardholder fees charged to the Cardholders for various Card activities in Program Groups, and to associate Client Card transactions with a schedule of wholesale processing fees from the Host System service provider for the purpose of automated billing and accounting functions between the Client and the Host System.

13. The method recited in claim 1 where Issuers are associated with numerous Program Groups that are utilized for processing Cardholder fees specific to the Issuer, the Issuers Program Groups and Card Types.

14. The method recited in claim 1 where Acquirers are associated with Program Groups which enables proper calculation of Transaction Set values based upon the Acquirers choices.

15. The method recited in claim 1 where Card daily and maximum limits are determined for balances, usage counts, authentication failures, load amounts, daily spending and withdrawal amounts.

16. The method recited in claim 15 where Card Issuers configure numerous Card limits for a range of sequential Card numbers.

17. The method recited in claim 15 where separate Card limits are set for enrolled and non-enrolled or anonymous Cardholders within the same Card range.

18. The method recited in claim 15 where parent and companion Cards have different Card limits, yet share the same available funds, and that the companion Card limits are set by the parent Cardholder.

19. The method recited in claim 1 where Issuers are associated with Program Groups of which the Program Groups may contain fees, dates, event days, reward, loyalty, discount, rebate values, and choice of which Inbound Transaction types generate Stored Value transactions within the Transaction Set.

20. The method recited in claim 1 where Acquirers are associated with Program Groups that contain reward, loyalty, discount, and rebate values, and may also contain dates, event days, fees and choice of which Inbound Transaction type activate the Stored Value transactions.

21. The methods recited in claims 19 or 20 where Acquirers or Issuers set loyalty point rates contained within Program Groups that may be associated with a plurality of Acquirers or Issuers or both.

22. The methods recited in claims 19 or 20 where the Acquirer or Issuer sets purchase price discount rates contained within Program Groups that may be associated with a plurality of Acquirers or Issuers or both.

23. The methods recited in claims 19 or 20 where the Acquirer or Issuer sets rebate percentages of specified transactions or fixed dollar values after an event, as a function of utilizing Program Groups.

24. The methods recited in claims 19 or 20 where the Acquirer or Issuer sets Rewards rates in Program Groups that may be associated with a plurality of Acquirers or Issuers or both.

25. The methods recited in claims 19 or 20 where the Acquirer or Issuer selects up to seven days of week event days where the specified transaction associated with the Program Group is processed only on those selected days.

26. The methods recited in claims 19 or 20 where the Acquirer or Issuer selects event transactions types in the Program Groups to manage which type transactions trigger additional Stored Value transactions to be built in the Transaction Set.

27. The methods recited in claims 19 or 20 where the Issuer or Acquirer configures a funding entity Location which is charged for the values of rewards, discounts, rebates, loyalty, and points declared in the utilized Program Group.

28. The method recited in claim 1 where a scheduled Host System computer software program runs automatically on a daily basis to count the number of days since the last transaction occurred with all Cards in the Host System database and analyzing all the valid Program Groups and setting a flag in the Card database table designating the Cards as inactive if in fact the Cards have had no activity for the specified period of days configured in the Program Group associated with the Issuer and the inactive Cards, thereby triggering dormancy fees based on the Issuers time period choice.

29. The methods recited in claim 22 where the Acquirer or Issuer selects whether purchase discounts are added to the Card balance or deducted from the purchase price of the goods or services.

30. The methods recited in claim 26 whereby daily funding entity dollar amounts are automatically debited out of a designated account via a Host System automated computer software program that totals up the daily values of the relevant Stored Value transactions associated with the funding entity Locations and submits an ACH debit transaction for settlement via an ACH credit to the Clients designee which may be an entity such as a charity, marketing company, vendor, etc.

31. The method recited in claim 1 where Locations are configured within the Host System database for enablement of maintenance, support, accounting, settlement, and association with Program Groups containing Card transaction values choices.

32. The method recited in claim 30 where Card transaction Acquirers maintain daily Card loadability limits at a Location level so that as Cards are credited/loaded by the Acquirer Location, the daily Acquirer Location available loads limit is reduced by the load amounts till the limit is reached and the daily load ability is depleted.

33. The method recited in claim 30 where the daily loads of Locations are batched and processed automatically by a Host System computer software program that utilizes Acquirer data held in the Host System database to build an ACH file to be processed for settlement and the Acquiring store daily load limits replenished upon a designated time frame.

34. The method recited in claim 1 where Client Program Groups contain various dates for program definition, I.E. start, end, first enrollment, last enrollment, purge date, first distribution, initial funding, etc.

35. The method recited in claim 1 where Issuer Program Groups define a period of time, in days of inactivity, for Card dormancy to occur, thereby triggering Card dormancy fees.

36. The method recited in claim 1 where the Location Terminals may contain Program Group data elements and logic which build some Transaction Set values, by means of client software residing on the Terminals which ultimately communicate a transaction string to the Host System that may contain one or more Program Group values.

37. The method recited in claim 1 where Clients brand the Host System for their use of the Web Interface with their graphic design, logos, color schemes, fonts, and menu style with their registered Internet domain names, so the Clients can give their customers Distributors, Agents, Cardholders, and any other authorized Client designee a seamless Web Interface experience.

38. The method recited in claim 37 where the Host System database holds specific values for branded Client users of the Web Interface that limit user access of the Host System to the Clients specific Web Interface and data.

39. The method recited in claim 1 where Acquirer Locations configure Terminals used in Acquirer Locations which send a transaction string ultimately to the Host System via Third Party Networks utilized by the Client.

40. The method recited in claim 39 where Terminal configurations utilize a unique Location ID number that allows the Host System to identify the Acquiring Location.

41. The method recited in claim 40 where each Acquiring Location can configure a plurality of Terminals in the Host System that are uniquely identified at that Location for the purposes of managing transaction activity and clerk usage of the Terminal.

42. The method recited in claim 1 where Cards are activated based on Issuer choices. Cards may be activated with a code sent in a transaction string received at the Host System from an Acquirer, they may be batch activated, they may be issued Active but unloaded, they may be activated via a telephone call to a Host System Interactive Voice Response that is called by the Cardholder and prompted by the IVR with an Issuer defined activation sequence.

43. The method recited in claim 1 where the Host System parses a Inbound Transaction string from a plurality of Third Party Networks in a variety of ISO standards and XML formats for transaction type determination, validation or rejection based on relevant data contained in the Host System database about the Card, the Client, Acquirer, Issuer, and their respective Program Groups for the Card Type, and process the transactions accordingly.

44. The method recited in claim 43 where multiple new Card transactions may occur and be added to the Transaction Set if the transaction string contains codes that based on the Acquirer and Issuers Program Group values, call for additional Stored Value transactions.

45. The method recited in claim 43 where multiple additional Card transactions may occur when a Card Type code is passed in with the transaction string from an Acquirer which is authorized to accept said Card Type, yet the Issuer has set the Card Type in the aforementioned transaction string to be a different Card Type;

when the Card Type codes match, only one Program Group values transaction occurs, when the Card Type codes are different and the Acquirer is authorized to accept both Card Types then two Stored Value transactions are added to the Transaction Set.

46. The method recited in claim 1 where the Host System calculates Cardholder fees based on transaction codes contained in the Inbound Transaction string and Issuer Program Group settings for that Card Type, to get the value to deduct from the Cardholder balance prior to authorization of transactions, and then posting the appropriate fee transaction details in the Host System database based on the authorization outcome of the transaction string request.

47. The method recited in claim 1 where the Host System builds Stored Value transactions and ads them to the Transaction Set based on the Client Program Groups values for the specified Card Type contained in the Inbound Transaction string received by the Host System.

48. The method recited in claim 1 where Cardholder enrollment data is stored in the Host System database for U.S. Government O.F.A.C and Patriot act “

know your account”

laws compliancy.

49. The method recited in claim 48 where Cardholder enrollment ID validation is accomplished through utilization of the Host System Web Interface forms that are filled out by enrollees and/or Client designees, then where the data is stored in the Host System database for submission in real time to a third party ID validation source and then the pass/fail results of the ID validation submission is published in real time back to the Web Interface user. The enrollee data is batch processed daily by a Host System computer software program and then the Pass batch submitted to a third party Card fulfillment source. The Fail batch can be processed by a Host System computer software program to generate application failure notices to the Cardholder to be sent by US Postal Service, or email.

50. The method recited in claim 1 where Client support personnel utilize the Host System Web Interface forms for Problem Tracking and resolution data held in the Host System database that captures and stores User ID, date and time, Card information, user comments, severity level, and user key words. Retrieval of Problem tickets can be queried by ticket number, Card information, severity level, User ID, and date, or a combination of those items for follow up or management review.

51. The method recited in claim 1 where Distributors are able to track Agent to Card transaction counts for commission and royalty calculations purposes by associating the Location of initial Card Activation to the Agent. This enables Distributors to manage inactive Card inventories without pre assignment of Cards to Agents.

52. The method recited in claim 1 where Issuer support personnel utilize a Host System generated Trust Receipt number for tracking shipment and receipt of Cards issued by them. The Trust Receipt number is unique within the Host System and is tied to the sequential number of Cards that are ordered via the Host System Web Interface with the Card ordering Issuer choices. The Cards are not available in the Host System for activation until the Trust Receipt process is completed and the Card shipment is designated complete by a support user, whose ID is recorded on in the Trust Receipt data.

53. The method recited in claim 1 where the Host System receives streaming real time transaction strings containing relevant data to process Card transactions properly based upon Client choices for certain Card Types and Program Groups. This host to Host System connectivity is accomplished with TCP/IP or legacy protocols, utilizing ISO formatted bitmap, and/or XML character messages.

54. The method recited in claim 53 where the Host System receives Open Network transaction requests via direct TCP/IP or legacy protocol connection or gateway to a direct connection TCP/IP or legacy protocol between the Host System and the Open Networks, where these transaction requests carry varied amounts of relevant data to process the transaction properly based on Client choices.

55. The method recited in claim 54 where the Host System receives a transaction string from the Open Networks containing a merchant Terminal ID, where the Terminal ID in the Open Network string is related to an Acquirer Location ID configured in the Host System database, where a positive match is then used by the Host System to build additional transactions in the transaction set as configured in the Acquirer Location Program Group for the Card Type if the Acquiring Location is authorized to accept the Card Type for the additional transaction set being processed. Additional Acquiring Location validation can be utilized if needed where the street number in the merchant address field of the open network transaction string matches with the street number of the Acquiring store in the Host System.

56. The method recited in claim 53 where the Host System receives a transaction string from the Open Networks containing a Merchant Category Code or MCC numeric value that is associated with a merchant type within the Host System database. The Host System may utilize this value in a variety of ways as determined by the Client in Program Group configurations associated with Acquirers and Issuers to filter transactions within Transaction Sets and process accordingly.

57. The method recited in claim 56 where an Issuer utilizes a Program Group to manage, and filter Card usage at certain merchants. An Issuer can also apply specific Stored Value transactions to the transaction set based on the MCC.

58. The method recited in claim 57 where a Client can set up a plurality of Issuers for a plurality of Card Programs utilizing the MCC to manage a plurality of values within the Program Groups that will be utilized based on Issuer of the Card number in the Inbound Transaction string from the open networks.

59. A computer-readable storage medium having a computer-readable program embodied therein for directing operation of the Host System including a communications system, a processor, and a storage device, wherein the computer-readable program includes instructions for operating the Host System to process Card transactions in accordance with the following

a. receiving, with the communications system, a transaction string in either bitmap or XML characters;

receiving, with the communications system, fields within the transaction string that may contain codes to be interpreted by the computer-readable program that define the transaction type, the Card Type, the Card, the Acquirer, the Card Issuer, transaction values, transaction time, transaction ID or trace number, size of transaction string, Cardholder Personal Identification Numbers (PINs), Card expiration date, merchant location information, and Cardholder Verification Values (CVV);

b. receiving, with the communications system, a transaction string that cannot be processed due to data contained therein that the host computer readable program determines is invalid based on the transaction type and data contained within the storage device.

60. The computer-readable storage medium recited in claim 59 wherein the computer-readable program further includes instructions for reading the transaction string fields values and comparing those fields values with associated values within the storage device for authentication, validation, and storage and retrieval of data to complete the transaction process.

61. The computer-readable storage medium recited in claim 59 wherein the computer-readable program further includes instructions for analyzing and filtering the transaction string fields values with data contained in the storage device so that the computer-readable program can process the transaction string based on Card number, Card Type, Transaction type, Location, and Program Group values to build a Transaction Set that may contain other transactions written to it by the computer-readable program if the relative Program Groups so specify and that if approved, comprises at least the Inbound Transaction requested and the transaction fee transaction.