System and method for creating automatic expiring transactions for a credit card

A system and method are disclosed in which a user engaging in an online or in-person transaction with a merchant may create automatic expiring transactions for a credit card. The user provides the credit card information to an online interface or a point-of-sale device but specifies an expiration date that is on or before the actual expiration date of the credit card, known as an artificial expiration date. A token for the merchant is generated with the artificial expiration date. The issuing bank will honor the transaction with the artificial expiration date using the merchant-specific token, and the token may continue to be used with the online merchant until the artificial expiration date.

BACKGROUND

Online transactions are very popular with consumers. A merchant who has online interfaces, such as a web page and/or mobile application, typically contracts with a payment processing system to manage sensitive information, such as credit card numbers. The merchant online interface automatically sends the sensitive information to the payment processing system, which determines whether the transaction may be completed.

SUMMARY

This disclosure presents various systems, components, and methods related to creating automatic expiring transactions for a credit card. Each of the systems, components, and methods disclosed herein provide one or more advantages over conventional systems, components, and methods.

Various embodiments include techniques for creating automatic expiring transactions for a credit card. In one embodiment, an apparatus, comprises a processor and a memory coupled to the processor, the memory comprising instructions that, when executed by the processor, cause the processor to receive a request to make a payment to a merchant from a payment processing system, wherein the payment is to be made from a customer's credit card, the request to include an expiration date that is different from a second expiration date associated with the credit card, confirm that the expiration date is prior to the second expiration date, confirm that the expiration date is after a current date, and either approve the request to the payment processing system upon authentication of the credit card of the customer, or deny the request to the payment processor.

In another embodiment, at least one machine-readable storage medium comprises instructions that, when executed by a processor, cause the processor to receive encrypted information from a payment processing system, the encrypted information comprising a credit card number and an expiration date, decrypt the encrypted information to obtain the credit card number and the expiration date, and authenticate the credit card number by comparing the credit card number to a database of saved credit card numbers, approve a transaction using the credit card even though the expiration date is on or before an actual expiration date associated with the credit card number, wherein a token having the expiration date is to be used for transactions with a merchant, wherein the merchant was given the expiration date during processing of an initial transaction with the merchant.

In another embodiment, an apparatus comprises a processor and a memory coupled to the processor, the memory comprising instructions that when executed by the processor cause the processor to decrypt an encrypted transaction object, the encrypted transaction object comprising credit card information including an artificial expiration date, authenticate the credit card information by consulting a database of credit card information for a plurality of bank customers, confirm, by consulting the database of credit card information, that the artificial expiration date is on or before an actual expiration date associated with the credit card number, and approve a transaction using the credit card information and the artificial expiration date.

DETAILED DESCRIPTION

In accordance with the embodiments described herein, a system and method are disclosed in which a user engaging in an online or in-person transaction with a merchant causes an automatically expiring merchant-specific token to be generated and used for the transaction. The merchant-specific token is associated with a credit card of the user, and the user may specify an expiration date that is on or before the actual expiration date of the credit card, known as an artificial expiration date. The issuing bank will honor the transaction with the artificial expiration date using the merchant-specific token, and the token may continue to be used with the online merchant until the artificial expiration date.

Evolution of the Banking Relationship

Banks and other financial institutions provide a number of different services involving finances, most notably, a checking or savings account. Hereinafter, a reference to a “bank” is meant to encompass other financial institutions, including, but not limited to credit unions, savings and loan institutions, financial services providers, and so forth. Initially, a customer of a bank would rely on a passbook, a booklet issued by the bank, enabling the accountholder to personally record how much money had been deposited or withdrawn from the account. More recently, an accountholder would receive a statement, usually monthly, in the mail.

With the advent of personal computers, banks began providing account statements by electronic mail for those users who selected the feature, such as being part of the institution's “paperless” option. Today, many banks enable customers to access their account information by way of a personal computer, laptop, tablet, notebook, pad, personal digital assistant, or other devices that have access to the Internet. By accessing a web page and providing a username and password as authentication, the user is able to receive a wealth of information about the bank account, including recent purchases and deposits, transaction entities, bank statements, and so on. These web accesses also enable transactions to take place, known colloquially as “online banking” in which automatic payments may be scheduled and money may be transferred between different accounts of the user, to a third-party account within the same bank, and even to third-party accounts with another bank. Relying on this Internet-based access, today's accountholder may view the current balance of an account twenty-four hours a day, seven days a week.

With the proliferation of hand-held device technology, such as smart phones, many banks have made applications (known colloquially as “apps”) available to their customers. As long as the smartphone is able to access the Internet, the bank may provide a downloadable app for accessing a customer's bank account from the smartphone. Similar to the web page, the app, once selected, will generally request a username and password to authenticate the user. Alternatively, some apps enable access using a fingerprint or voiceprint to authenticate the user. Once authenticated, the user is able to review the account, such as to obtain balance information, scroll through transactions, make transfers to another account, deposit checks, and so on. These apps are intended to enhance the convenience for the accountholder. So, in addition to being able to access one's checking account by accessing a web page, a user may similarly access the account by enabling the app on a smartphone.

System for Creating Automatic Expiring Transactions for a Credit Card

FIG. 1is a simplified block diagram of a system for creating automatic expiring transactions for a credit card100, according to some embodiments. The system100includes a bank system102, a payment processing system110, a merchant or vendor system118, and an accountholder system126. The bank102includes a bank server104, and the accountholder126may have one or more accounts, such as a checking or savings account, with the bank. The accountholder126may also have one or more credit cards128that were issued by the bank102. Thus, the bank102is also known as an issuing bank. The accountholder126is able to communicate with the merchant or vendor118by way of a merchant application, known colloquially as an app122, where the merchant app is to be loaded onto a mobile device130of the accountholder, by way of a website124viewable from a computer132. Alternatively, the accountholder126communicates with the merchant in person at the premises of the merchant. Collectively, the mobile app122and website124are known herein as online interfaces or merchant online interfaces. The accountholder126may use either or both types of merchant online interfaces. The accountholder may also be referred to herein as a customer, a bank customer, and a user.

In some embodiments, the system for creating automatic expiring transactions for a credit card100pertains to online transactions between the merchant118and the accountholder126. In some embodiments, an online transaction or online purchase is one in which a user selects goods or services offered by a merchant by viewing a web page (from a computer) or mobile app (from a mobile device), the web page and the mobile app having been created by the merchant, and using a credit card to complete a purchase of the selected goods or services. In other embodiments, the system for creating automatic expiring transactions for a credit card100pertains to in-person transactions with a merchant, where the accountholder126uses the credit card128with a point-of-sale (POS) device134at the merchant, to complete a transaction for goods or services.

In some embodiments, the system for creating automatic expiring transactions for a credit card100enables the accountholder126to enter an expiration date other than the actual expiration date shown on the credit card128(an artificial expiration date) during an online transaction. As used herein, the actual expiration date is the date associated with the credit card's expiration, that is, the date after which the credit card may not be used, where the actual expiration date is generally stamped directly on the physical card. The artificial expiration date is a date which is the same as or prior to the actual expiration date, and which is specified by the accountholder during online or in-person transactions with a merchant. Once the artificial expiration date is entered at the merchant online interface or at a point-of-sale (POS) device at the merchant premises, a merchant-specific token is generated, usable only for transactions at the merchant, in which the token will expire on the artificial expiration date entered by the accountholder. The merchant-specific token is generated with the artificial expiration date. Neither the payment processing system110nor the merchant system118knows the artificial expiration date is different from the actual expiration date on the card. Instead, both the payment processing system110and the merchant system118see the artificial expiration date of the token and process transactions using the token until the artificial expiration date. In some embodiments, the tokenization of the credit card information at the merchant mobile app122, the merchant website124, or at the merchant POS device, ensures that the merchant is unable to overcharge the customer against their wishes.

In some embodiments, the system for creating automatic expiring transactions for a credit card100enables the accountholder126to enter the artificial expiration date during an in-person transaction. For example, the accountholder may specify the artificial expiration date by manually entering the credit card number plus the artificial expiration date at the POS device at the merchant location.

The bank server104, which may be more than one server, is controlled by the bank. The bank server104is a processor-based computing system of the bank, which may be on the premises of the bank or at another location, may be a cloud server or may be a combination of on-premises, off-premises, and cloud-based computing. The bank server104includes software executed by a processor, to issue a transaction approval code106to the payment processing system110. The transaction approval code106is to be issued to the payment processing system once the bank verifies the transaction as valid. In some embodiments, the transaction approval code106is issued even though the accountholder has entered an artificial expiration date.

Similarly, the payment processing system110and the merchant system118include respective servers112and120, each of which may consist of multiple server devices and may include on-premises, off-premises, and/or cloud-based computing. The merchant system118, also known as a vendor system, is the entity from which the accountholder126is able to make online or in-person purchases of goods or services. The bank server104, payment processing system server112, and merchant server120communicate with one another using Application Programming Interface (API) calls. Sometimes known as a payment gateway, a merchant gateway, pay gate, or online gateway, the APIs are software that connects between the bank server104to the payment processing system server112, as well as between the payment processing system server and the merchant server120. The payment gateway captures and encrypts sensitive information, such as a credit card number, before any transmission, thus ensuring a secure transmission of the information between the servers.

Payment processing systems are involved in virtually every transaction involving a credit or debit card, whether online or from Point of Sale (POS) devices. Payment processing systems are companies that handle credit and debit card transactions on behalf of merchant acquiring banks. Merchant acquiring banks, also known as acquirers, are banks that enter into contracts with the merchants so that the merchants are able to accept credit or debit card payments in exchange for goods or services. Issuing banks are banks that issue credit cards to their bank customers. For example, the bank102inFIG. 1issues the credit card128to the accountholder126and is thus an issuing bank.

In some embodiments, the payment processing system server112includes a token generator114and, like the bank server, software to generate a transaction approval code116. The token generator114is software of the payment processing system server112that causes the token to be generated and sent to the merchant, the merchant being determined based on where the credit card information was entered, whether from the merchant's online interface or from a POS device on the merchant premises. The resulting token is to be used in one or more transactions between the accountholder126and the merchant118, as described in more detail below.

Payment Processing System

In exchange for goods or services offered by a merchant, a credit card holder presents a credit card to the merchant. A credit card holder is an individual to whom a credit card was issued by an issuing bank. If the transaction is in person, the merchant has a POS device and associated software that electronically reads the credit card information. If the transaction is from a website or mobile app, the credit card information is entered into a form embedded as part of the website or mobile app.

The credit card information as well as the amount of the purchase is then sent electronically to the payment processing system. For online and in-person transactions, the electronic transmission is securely sent through the payment gateway. The payment processing system forwards the electronic information to a credit card network, such as VISA®, MASTERCARD®, or AMERICAN EXPRESS®. The credit card network forwards the electronic information to the issuing bank. The issuing bank knows whether the credit card holder has sufficient funds to honor the transaction with the merchant and, based on this information, sends a reply in digital form back across the network, to be received at the merchant POS device, website, or mobile app. The digital reply is either an approval code or a denial code. The passing of the electronic information between the merchant and the payment processing system, the payment processing system, and the credit card network, and the credit card network and the issuing bank occur using API calls.

Assuming the credit card holder has the funds or approved credit available, the issuing bank approves the transaction by issuing the approval code, which is sent to the credit card network, which then forwards the approval code to the payment processing system. The payment processing system forwards the approval code to the merchant and the transaction between the credit card holder and the merchant is approved. These transactions are also done electronically, using API calls. As long as the there is no disruption to the payment processing network, these steps generally are completed in a few seconds. In exchange for swiping the credit card for the specified amount at the POS device or entering the credit card information into the web or mobile app form, the credit card holder receives goods or services from the merchant.

Once the transaction is complete, additional processing takes place. The issuing bank sends money for the amount of the transaction (in electronic form) to the payment processing system as reimbursement for the transaction the bank just approved. At the end of the day (or at the end of a specified time period), the merchant sends all transactions made using credit or debit cards, known as a batch, to the payment processing system. The payment processing system sends the batch to the merchant bank and the amount of the daily (or specified time period) deposits is credited to a bank account of the merchant at the merchant bank. Finally, the issuing bank sends a credit card bill to the credit card holder, so that the issuing bank will be reimbursed for the money sent to the payment processing system.

Thus, the payment processing system is an intermediary between the merchant and the credit card network, between the merchant and the merchant bank, and between the issuing bank and the merchant bank. Similarly, in the system for creating automatic expiring transactions for a credit card100(FIG. 1), the payment processing system110is an intermediary between the bank system102and the merchant system118. For simplicity, the credit card network entity is not shown in the figures. The payment processing system110may also generate the token to be used by the accountholder126, as explained in more detail below.

Online merchants typically do not see credit card information directly. Instead, they receive the credit card information in tokenized form, in part, to protect the merchant from having to store the sensitive data found on a credit card. The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard mandated by credit card brands to increase controls around credit card data, which, in turn, is designed to protect against credit card fraud. Any merchant, including an online merchant, that wants to process, store, or transmit credit card data is expected to be PCI compliant. Because the payment gateway is designed to securely pass the sensitive credit card data from the form on the merchant's website or from the POS device at the merchant premises to the payment processing system, many online merchants will use a payment gateway to maintain compliance with the PCI DSS standards.

The payment processing system110, by contrast, has robust mechanisms in place to protect the security of accountholder data. The payment processing system may maintain a firewall, use regularly updated anti-virus software, and execute secure applications, for example, to protect data stored in its PCI-compliant database116, and may also limit access to the database by its employees. The payment processing system further employs cryptographic security measures, such as by encrypting and hashing, before the data is stored.

Token Generation

Tokens are increasingly used as a security measure against fraud, both for online transactions and for point-of-sale transactions at a merchant. Tokens are generated using an algorithm to replace the original credit card number with a series of randomly generated numbers or a randomly generated code. The use of tokens rather than original credit card numbers facilitates PCI compliance by the merchant, since the merchant does not have access to the original credit card numbers. Once the credit card is entered into the POS device of a merchant, the randomly generated token is only valid for purchases at the merchant. Similarly, once the credit card information is entered into an online interface of the merchant, the token is only valid at the merchant.

Method for Creating Automatic Expiring Transactions for a Credit Card

FIGS. 2A and 2Bare schematic diagrams of a method for creating automatic expiring transactions for a credit card200A and200B (collectively, “method200”), according to some embodiments. The method200is to be used during online transactions with a merchant and enables the accountholder to cause a merchant-specific token to be generated for the purchase. InFIG. 2A, the operations of the accountholder are described, while inFIG. 2B, the operations of the payment processing system server112, the merchant server120, and the bank server104are described. Although the reference numbers inFIG. 2Bsuggest an ordered progression, it will become apparent that the described steps may take place in an order other than is illustrated. Furthermore, one or more of these steps may take place simultaneously.

Starting with the accountholder operations inFIG. 2A, the mobile device130and the computer132(FIG. 1) are shown, either one of which may be used by the accountholder126(not shown) to invoke a merchant online interface with which the accountholder may engage in an online transaction with the merchant118. Further, a POS device134is featured for in-person transactions with the merchant.

The accountholder may communicate with a merchant using the mobile app122loaded onto the mobile device110. Alternatively, the accountholder may communicate with a merchant by opening a website124loaded onto a computer display132. As a third alternative, the accountholder may shop in person at the merchant premises and interact with a POS device during checkout. In any of these three circumstances, the merchant app122, the merchant web page124, or the POS device134are requesting credit card information (CCI) from the accountholder. The credit card information consists of a credit card number, a zip code of the user, optionally, a security code, and an expiration date. In some embodiments, at this point, the accountholder enters the artificial expiration date. From one of the two merchant online interfaces122(merchant mobile app) or124(merchant web page), or at the POS device134, the accountholder enters the credit card information including the artificial expiration date202.

Whether from a form on one of the merchant online interfaces or from the POS device, a payment gateway captures the CCI including the artificial expiration date202. A merchant identifier (ID)204and the transaction amount206are also part of the data gathered. The payment gateway encrypts the sensitive data, shown as an encrypted transaction object208, before any transmission takes place. The encrypted transaction object208is then securely transmitted to the payment processing system server112(FIG. 2B). For example, RSA-style encryption, a type of public-key encryption, may be used. The merchant ID204may be, for example, a merchant-specific identifier, such as a merchant account number with the payment processing system, as well as a merchant token, which is used to authenticate the merchant to the payment processing system.

InFIG. 2B, although the operations are taking place between the bank102, the payment processing system110, and the merchant118, the respective servers of each entity are featured, namely, the bank server104, the payment processing system server112, and the merchant server120. The communication between these servers is by way of API calls. The operations ofFIG. 2Bcommence once the encrypted transaction object208(FIG. 2A) is generated.

Within the payment process system server112, the merchant server120, and the bank server104, different method operations are performed. Reference numbers210-234refer to distinct method operations, referred to herein as blocks. First, at the payment processing system server112, the encrypted transaction object208, containing the CCI including the artificial expiration date202, the merchant ID204, and the transaction amount206, is decrypted (block210). From the decrypted objects, the payment processing system server112generates a token having the artificial expiration date (block212). The token is associated with both the credit card information of the accountholder and the merchant, although the former is known only to the bank server104and the latter is known only to the payment processing system server112. Because the payment processing system server112has the merchant ID from the decrypted transaction objects, the payment processing system server knows where to send the token. Accordingly, the payment processing system server112sends the token to the merchant based on the merchant ID (block214), with the transmission being via an API call. The payment processing system server112also re-encrypts the transaction objects (block216) before the sensitive data is forwarded to the bank server104(block218). A credit card network intermediary may also be part of the process, but, for simplicity, is not shown.

At the bank server104, the re-encrypted transaction objects received from the payment processing system server112are decrypted, resulting in the CCI including the artificial expiration date202, the merchant ID204, and the amount of the transaction206(block220). By consulting its credit card database106, the bank will know whether the CCI202is that of one of its accountholders and thus performs authentication operations (block222). By comparing the CCI202with the database106, the bank server104will know if the accountholder indicated an artificial expiration date and will be able to confirm whether the artificial expiration date is on or before the actual expiration date (and is also on or after the current date). In some embodiments, if the CCI202includes the artificial expiration date and is otherwise legitimate, the bank server104will approve the transaction using the artificial expiration date (block224). Using its transaction approval code software106, the bank server104sends a transaction approval code106to the payment processing system server112(block226).

Meanwhile, the merchant server120has received the token with the artificial expiration date from the payment processing system server112(block228). This may occur before the bank server has sent the approval code to the payment processing system server. The token is a representation of the original CCI including artificial expiration date202, but the merchant server120has no knowledge of the original credit card information. However, some information about the original credit card information is available to the merchant, namely, the artificial expiration date (but the merchant is unaware that the date is user-generated).

Next, the merchant server120sends, in an API call, a combination of the token and merchant API keys, to the payment processing system server112(block230). The merchant API keys consist of a “code” or “string” of digits which are used to authenticate the merchant. Each merchant has its own merchant API keys, which is kept secret by the merchant. Thus, both the token and the merchant API keys are associated with the merchant118. In some embodiments, the token is only valid when used with the merchant API keys. The payment processing system server112confirms that the token and merchant API keys are legitimate (block232), and, once the approval code from the bank (block226) is received, issues an approval code to the merchant server120(block234). Once the approval code is received by the merchant server120, the merchant server is able to complete the transaction (block236).

The method for creating automatic expiring transactions for a credit card200thus enables the accountholder to enter an artificial expiration date other than the actual expiration date shown on the credit card. As long as the accountholder-specified artificial expiration date the same as or prior to the expiration date on the card, the bank server104will approve the transaction, assuming that the credit card is otherwise valid. Thus, in some embodiments, the accountholder may enter an expiration date that precedes the actual expiration date of the card (artificial expiration date) without the merchant server118knowing that the expiration date has changed. Further, the accountholder may change the expiration date for the merchant, whether at one of the merchant online interfaces or at a POS device at the merchant location.

When used with subscription-based transactions, the token ensures that the merchants do not overcharge customers against the wishes of the accountholder. The merchant is able to use the token for subscriptions as long as the transactions are processed before the artificial expiration date. The payment processing system will block any transactions using the token that are attempted after the artificial expiration date. The method200also enables the accountholder to set up different expiration dates for different online merchants, all from the same credit card.

FIGS. 3A and 3Bare illustrations300A and300B, respectively, of how the method for creating automatic expiring transactions for a credit card200operates, from the perspective of the accountholder, according to some embodiments. The accountholder, such as the accountholder126(FIG. 1), is the holder of a credit card128. The credit card128includes the relevant information used in transactions, whether online or with POS devices at physical merchant locations, namely, a credit card number302, a zip code304, optionally, a security code306, and an actual expiration date308. While the zip code304is not part of the credit card, merchants often use zip codes as an additional security measure to ensure that the credit card belongs to the accountholder.

At the merchant online interface, whether a mobile app or a web page, once a transaction is to be completed by a user, the web page generally pops up a form window, such as when the user enters the “shopping cart” of the online interface. The user is instructed to enter the relevant credit card information, which generally consists of the information shown inFIG. 3A. Some merchants additionally request a complete billing address or at least an indication whether the mailing address, provided by the user when goods are to be shipped from the online merchant, is different than the billing address.

In some embodiments, according to the method for creating automatic expiring transactions for a credit card200, the accountholder is able to enter an artificial expiration date in the form window. Further, this may be done for different online merchants using the same credit card information, resulting in a new token being generated for each online merchant, as described above. Thus, as illustrated inFIG. 3A, the accountholder may enter a first artificial expiration date322for a first online merchant310, resulting in a first token316that may be used for online transactions with the first online merchant. The artificial expiration date is encoded as part of the token such that, after said date, the token would not be usable. Further, in some embodiments, the token316may only be used by the first online merchant310, where the first online merchant sends the token316as well as its merchant API keys to the payment processing system for approval of the transaction. Similarly, the accountholder may enter a second artificial expiration date324for a second online merchant312, resulting in a second token318, and so on, until an Nthtoken320is created based on an artificial expiration date326for an Nthonline merchant314. The token320may not be used by the second online merchant312but may only be used with the Nthonline merchant326. Each of the tokens316,318, . . . ,320are associated with the original credit card128and transactions using these tokens will be paid for by the accountholder by paying the credit card bill associated with the original credit card.

In the illustration300B (FIG. 38), the use of the tokens may be customized by the accountholder based on the relationship between the customer and the online merchants. For example, suppose the accountholder would like to buy a subscription from the first online merchant. The online merchant may provide a monthly service, such as for a service such as NETFLIX® or HULU®, and the accountholder does not want to come back every month and pay for the subscription. Further, the accountholder would like to be able to periodically review her relationship with the online merchant, and thus does not want the subscription to be open-ended. The accountholder therefore may request a subscription service with the online merchant and set up the first token316at the online merchant website. By setting an artificial expiration date of one year from the date of engagement with the merchant, the token316will expire in one year. This ensures that twelve payments, once a month, will be sent to the first online merchant, and no more. Although the credit card128may not expire in one years' time, the token316does expire in one year. Further, in some embodiments, the token316is to be used for transactions with the first online merchant, and thus may not be used for other online transactions. The first online merchant will successfully bill each month of the subscription by sending the token316plus the first merchant's API keys to the payment processing system. This limits the ability of a nefarious actor to obtain any benefit from the token316.

The second token318is also used for a subscription, this time to be paid quarterly. Again, the accountholder may, upon entering the merchant online interface of the second merchant, request the subscription service and enter an artificial expiration date of one year from the date of engagement with the merchant, such that the token318will expire in a year. The accountholder may also specify on the merchant's web site or mobile app, that quarterly payments are to be made using the token318. Each quarter, the second online merchant will send the token318plus the second merchant's API key to the payment processing system. This ensures that four quarterly payments will be sent to the second online merchant, and no more.

The method for creating automatic expiring transactions for a credit card200is not limited to subscription payments, in some embodiments, but may also be used for one-time payments to a merchant. In the third example, the token320is generated for an online transaction with an Nthmerchant. The accountholder may set the artificial expiration date for the next day, for example. As long as the transaction is completed before the next day expires, the token320is usable on the Nthmerchant's online interface for desired goods or services. Through an API call, the Nthmerchant will send both the token320and its merchant API keys to the payment processing system for transaction approval.

Suppose the first merchant310makes a change during the subscription period, such as an increase in the monthly service fee.FIG. 4illustrates the operation400that takes place between the online merchant and the payment processing system server. In some embodiments, the merchant310sends the token316, plus its merchant-specific API keys, plus the desired modifications, to the payment processing system server112. The modifications may include, for example, a change to the monthly subscription amount or a change of the due date. As long as the token is known to be associated with the first merchant and the merchant-specific API keys are associated with that merchant, the payment processing system may approve the modification, and the token is still usable for the monthly subscription with the first merchant. Neither the bank102nor the accountholder126are involved in the change to the subscription, in some embodiments.

FIGS. 5, 6, and 7are flow diagrams depicting three different embodiments for performing the method for creating automatic expiring transactions for a credit card. In the operations500, the payment processing system generates the token without prompting from the issuing bank. In the operations600, the payment processing system generates the token after being prompted to do so by the issuing bank. In the operations700, the issuing bank generates the token and sends the token to the payment processing system.

First looking at the operations500(FIG. 5), the accountholder enters credit card information including the artificial expiration date at a merchant online interface or at a POS device at the merchant (block502). The credit card information, plus a merchant identifier, plus the transaction amount, is encrypted and sent to the payment processing system (block504). The payment processing system decrypts and stores the received information, generates a token, re-encrypts the sensitive data, and sends the encrypted information to the issuing bank. Simultaneously or subsequently, the payment processing system sends the token to the merchant (block506). The issuing bank decrypts the received data, authenticates the credit card information, and confirms that the artificial expiration date satisfies the criteria, namely, that the artificial expiration date is not a date later than the actual expiration date on the credit card (block508). In some embodiments, the bank also confirms that the artificial expiration date is on or after the current date. If the transaction is approved, the issuing bank sends an approval code to the payment processing system (block514). If, instead, the transaction is not approved, the issuing bank sends a rejection code to the payment processing system (block512).

After receiving the approval code, the payment processing system subsequently receives the token previously sent to the merchant (block506), plus the merchant API keys, from the merchant (block516). If the payment processing system confirms that the merchant API keys and the token match or, in other words, the merchant API keys belong to the merchant and the token was issued for the merchant (block518), the payment processing system issues an approval code (block520) for the transaction. Otherwise, the payment processing system issues a rejection code to the merchant (block524).

Where the merchant receives the approval code, the merchant is able to complete the transaction with the accountholder using the token (block522). Although the merchant receives only one approval code,FIG. 5shows that the transaction with the merchant is not approved unless both the issuing bank approval code (block514) and the payment processing system approval code (block520) are issued.

In the operations600(FIG. 6), the payment processing system generates the token only after receiving an API call from the issuing bank with instructions to generate the token. The accountholder enters credit card information including the artificial expiration date at a merchant online interface or at a POS device at the merchant (block602). The credit card information, plus a merchant identifier, plus the transaction amount, is encrypted and sent to the payment processing system (block604). The payment processing system decrypts and stores the received information, re-encrypts the sensitive data, and sends the encrypted information to the issuing bank (block606). The issuing bank decrypts the received data, authenticates the credit card information, and confirms that the artificial expiration date satisfies the criteria, namely, that the artificial expiration date is not a date later than the actual expiration date on the credit card and is also a date after the current date (block608). If the transaction is approved, the issuing bank sends an approval code to the payment processing system (block614). The issuing bank also sends a token generating code to the payment processing system (block616). The operations of blocks614and616may occur in reverse order or simultaneously. If, instead, the transaction is not approved, the issuing bank sends a rejection code to the payment processing system (block612).

After receiving the approval code and the instructions to generate the token from the issuing bank, the payment processing system generates the token and sends it to the merchant (block618). Subsequently, the payment processing system receives the token back from the merchant, along with the merchant API keys (block620). If the payment processing system confirms that the merchant API keys belong to the merchant and the token was issued for the merchant (block622), the payment processing system issues an approval code (block624) for the transaction. Otherwise, the payment processing system issues a rejection code to the merchant (block628).

Where the merchant receives the approval code, the merchant is able to complete the transaction with the accountholder using the token (block626). Again, although the merchant receives only one approval code,FIG. 6shows that the transaction with the merchant is not approved unless both the issuing bank approval code (block614) and the payment processing system approval code (block624) are issued.

In the operations700(FIG. 7), the issuing bank generates the token. As in the previous two examples, the accountholder enters credit card information including the artificial expiration date at a merchant online interface or at a POS device at the merchant (block702). The credit card information, plus a merchant identifier, plus the transaction amount, is encrypted and sent to the payment processing system (block704). The payment processing system decrypts and stores the received information, re-encrypts the sensitive data, and sends the encrypted information to the issuing bank (block706). The issuing bank decrypts the received data, authenticates the credit card information, and confirms that the artificial expiration date is valid (block708). If the transaction is approved, the issuing bank sends an approval code to the payment processing system (block714). If, instead, the transaction is not approved, the issuing bank sends a rejection code to the payment processing system (block512).

After sending the approval code, the issuing bank generates the token and sends it to the payment processing system (block716). Although the operations700show the approval code being sent first, the token may be generated first and sent to the payment processing system before the approval code is sent. The payment processing system then sends the token to the merchant (block718). Subsequently, the payment processing system receives the token it just sent to the merchant (block718), plus the merchant API keys, from the merchant (block720). If the payment processing system confirms that the merchant API keys and the token match (block722), the payment processing system issues an approval code (block724) for the transaction. Otherwise, the payment processing system issues a rejection code to the merchant (block728).

Where the merchant receives the approval code, the merchant is able to complete the transaction with the accountholder using the token (block726).

FIG. 8is a flow diagram illustrating operations800in which the merchant modifies a subscription already in place with an accountholder. It is assumed that the accountholder set up a subscription with the merchant using a token with an artificial expiration date, as described herein. First, the merchant wants to modify a subscription of the accountholder during the subscription period (block802). The merchant sends the accountholder token, plus the merchant API keys, plus the modification to be made, to the payment processing system (block804). The payment processing system validates the merchant API keys (block806), as described above. If the merchant API keys are not valid, the payment processing system issues a rejection code to the merchant (block814) and the transaction fails. The payment processing system also validates the token (block808), as described above. If the token is not valid, the payment processing system issues a rejection code to the merchant (block814) and the transaction fails. The operations of blocks806and808may be done in reverse order. If either query fails, the attempted modification by the merchant fails.

If, instead, both queries are answered in the affirmative, the payment processing system issues the approval code (block810). The merchant is then able to complete the transaction with the accountholder with the modification using the token (block812). The operations800show that neither the issuing bank nor the accountholder are involved in the modification of the subscription. Nevertheless, the accountholder is able to contact the merchant and cancel the subscription at any time, such as when the accountholder objects to an increase in fees, or for any reason.

FIG. 9illustrates an embodiment of an exemplary computing architecture900comprising a computing system902that may be suitable for implementing various embodiments as previously described. In various embodiments, the computing architecture900may comprise or be implemented as part of an electronic device. In some embodiments, the computing architecture900may be representative, for example, of a system that implements one or more components of the system100and method200for creating automatic expiring transactions for a credit card. In some embodiments, computing system902may be representative, for example, of the mobile devices used in implementing the system100and method200for creating automatic expiring transactions for a credit card. The embodiments are not limited in this context. More generally, the computing architecture900is configured to implement all logic, applications, systems, methods, apparatuses, and functionality described herein.

The computing system902may include various types of computer-readable storage media in the form of one or more lower speed memory units, including an internal (or external) hard disk drive (HDD)914, a magnetic floppy disk drive (FDD)916to read from or write to a removable magnetic disk918, and an optical disk drive920to read from or write to a removable optical disk922(e.g., a CD-ROM or DVD). The HDD914, FDD916and optical disk drive920may be connected to the system bus908by an HDD interface924, an FDD interface926and an optical drive interface928, respectively. The HDD interface924for external drive implementations may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies. The computing system902is generally is configured to implement all logic, systems, methods, apparatuses, and functionality described herein with reference toFIGS. 1-8.

The drives and associated computer-readable media provide volatile and/or nonvolatile storage of data, data structures, computer-executable instructions, and so forth. For example, a number of program modules may be stored in the drives and memory units910,912, including an operating system930, one or more application programs932, other program modules934, and program data936. In one embodiment, the one or more application programs932, other program modules934, and program data936may include, for example, the various applications and/or components of the system100and method200for creating automatic expiring transactions for a credit card.

A monitor944or other type of display device is also connected to the system bus908via an interface, such as a video adaptor946. The monitor944may be internal or external to the computing system902. In addition to the monitor944, a computer typically includes other peripheral output devices, such as speakers, printers, and so forth.

When used in a LAN networking environment, the computing system902is connected to the LAN952through a wire and/or wireless communication network interface or adaptor956. The adaptor956may facilitate wire and/or wireless communications to the LAN952, which may also include a wireless access point disposed thereon for communicating with the wireless functionality of the adaptor956.

When used in a WAN networking environment, the computing system902may include a modem958, or is connected to a communications server on the WAN954or has other means for establishing communications over the WAN954, such as by way of the Internet. The modem958, which may be internal or external and a wire and/or wireless device, connects to the system bus908via the input device interface942. In a networked environment, program modules depicted relative to the computing system902, or portions thereof, may be stored in the remote memory/storage device950. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

The computing system902is operable to communicate with wired and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices operatively disposed in wireless communication (e.g., IEEE 802.16 over-the-air modulation techniques). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth™ wireless technologies, among others. Thus, the communication may be a predefined structure as with a conventional network or simply an ad hoc communication between at least two devices. Wi-Fi networks use radio technologies called IEEE 802.11x (a, b, g, n, etc.) to provide secure, reliable, fast wireless connectivity. A Wi-Fi network may be used to connect computers to each other, to the Internet, and to wire networks (which use IEEE 802.3-related media and functions).