Patent ID: 12211050

Embodiments of the present disclosure and their advantages are best understood by referring to the detailed description that follows. It should be appreciated that like reference numerals are used to identify like elements illustrated in one or more of the figures, wherein showings therein are for purposes of illustrating embodiments of the present disclosure and not for purposes of limiting the same.

DETAILED DESCRIPTION

Provided are methods for providing and using canary card identifiers for real-time usage alerts. Systems suitable for practicing methods of the present disclosure are also provided.

An organization may issue one or more payment cards to customers, clients, and/or employees to process payments through an electronic card and/or transaction network associated with a backend payment processor on the network. A payment card may be linked to an account with an online transaction service provider, such as a service provider that facilitates processing of payments and enforcement of expense policies for payment instruments. In one example, such a payment and card processing system may be provided by BREX®, Inc. of San Francisco, CA, USA., which may provide electronic transaction processing services to customers and client organizations through credit accounts, debit cards, direct debit/credit through automated clearing house (ACH), wire transfers, gift cards, and other types of funding sources. The funding sources may be issued to organizations by the payment and card processing system, and well as other financial service providers integrated with the payment and card processing system. Digital accounts and physical payment cards may be used for in-store or physical payment transactions, such as by scanning a payment card or capturing data representing the account via a point-of-sale (POS) device and the like. Further, accounts and cards (including card identifiers) may also be used via one or more websites and/or applications of online merchants.

A networked system for payment and card processing and management may include a framework and architecture to provide payment gateways, billing platforms, eCommerce platforms, invoicing, and additional services. Organizations may be required to select payment networks utilized for issuance of payment instruments and transaction processing, which may include payment cards (e.g., credit or debit cards) or other types of funding sources. The payment networks may correspond to resolution networks for payment processing of expenses purchased using an account identifier, payment card, or the like during electronic and in-person transaction processing. However, organizations may have different account and/or card identifiers issued to the organization, and which may be provided during transaction processing. Where these identifiers are misappropriated, stolen, and/or fraudulently used, the organization may not be immediately aware of the fraud. Further, organizations may be required to review accounting and transaction histories to detect the fraud, which may allow some fraud to be unrecognized and resolved.

In this regard, one or more payment instruments may be issued to users or employees of an organization, including sales, management, information technologies, or other employees. The payment instruments may correspond to various types of payment cards and/or account identifiers, which may be issued by the card processing and/or issuing system, or by an associated partner (e.g., an issuing bank that provides credit cards or another financial instrument). During the course of business, an employee may engage in commerce with one or more merchants using a payment instrument, such as by making an in-person (e.g., at a merchant location or store) or online purchase from the merchant. The user may request electronic transaction processing through the account number or payment instrument identifier(s) provided to the user. Merchants (e.g., a seller or payment receiver, such as a business, fundraiser, healthcare provider, landlord, etc.) may correspond to any person or entity selling goods and/or services (referred to herein as an “item” or “items”) to the company's employees. Due to integration with payment networks, the card processing system's framework may receive real-time data of the transaction, for example, prior to the transaction being approved and resolving through such entities.

The card processing system may issue one or more “canary” card identifiers and/or physical payment cards. These canary card identifiers correspond to an alphanumeric code or identifier that uniquely identifies data for each canary card and may imitate valid card identifiers and appear as though the canary card identifiers are legitimate and can be used for processing transactions and providing payments or transfers. In other embodiments, the canary identifiers may instead or also be associated with digital account identifiers for payment accounts that may be used to facilitate payments. The canary card identifiers may be fake or falsified so that the card identifiers cannot be used for transaction processing and payments, are not associated with a digital account, do not have an available account or credit balance, or otherwise would fail transaction processing with a transaction and not provide a payment. Instead, the canary card identifiers may be marked for generating and transmitting an alert to the organization, one or more members of the organization, and/or the card processing system, which would identify a use of the canary card identifiers in a transaction. Thus, the canary card identifiers would instead cause a real-time or near real-time alert to be generated, which indicates that the canary card identifiers have been used. This may be done to indicate that at least the canary card identifiers have been misappropriated or fraudulently used, which may further indicate other valid card identifiers may also have been misappropriated and/or fraudulently used.

With the canary card identifiers, the card processing system that issues the valid and canary card identifiers to one or more organizations may implement and provide a network and card identifier listener system to list for and detect uses of the canary card identifiers. The network and system may be integrated with one or more payment networks for card processor systems and gateways for payment card processing, such as by processing data from physical payment cards (e.g., data and/or identifiers stored by a magnetic strip, EMV chip, smart card chip, or other card chip and storage mechanism, and the like). For example, a Mastercard®, Visa®, Discover®, American Express®, or the like may have a payment card network, card processors, and gateways that may be used to process a transaction when a payment card is used in the transaction (e.g., through a point-of-sale (POS) device, website, online merchant marketplace, or the like). The integration between these networks may allow for application programming interface (API) calls to be exchanged between the card processing system and one or more external card processors and/or gateways. The API calls may allow for APIs to interface and be integrated to exchange these calls when generating and issuing payment and canary card identifiers, as well as detect and exchange API calls during use of canary cards in transactions. The card processing system that issues the canary card identifiers may then provide an infrastructure and integration with these networks to provide another network to detect usages of card identifiers and determine that a canary card identifier has been used through one or more database lookups and/or queries from databases and data tables identifying the canary card identifiers and any operations to execute when the canary card identifiers are used.

Thus, the card processing system providing the canary card identifiers may use the additional network and system integrated with the payment network for card processing to detect a processing and use of a canary card identifier in a transaction. Initially, the canary card identifiers are provided to the organization, which may be provided with the valid card identifiers or provided at another time and/or updated when used. When providing the valid card identifiers and canary card identifiers to the organization, the card processing system may provide the canary card identifiers hidden within the valid card identifiers and/or with data that makes the canary card identifiers appear valid. For example, the canary card identifiers may be listed in a data table of all valid card identifiers. The canary card identifiers may also be issued to users, employees, and/or divisions within the organization or with particular data that causes the canary card identifiers to appear valid. The canary card identifiers may also be provided or listed with data that entices use of the canary card identifiers, such as “All sales division credit card,” “No limit credit card,” or other text, image, or information that may cause a malicious user or party to believe the canary card identifier is valid, would allow large payments, and/or may be unlikely to be caught in fraudulent transactions.

However, the organization may be informed of which card identifiers are canary card identifiers in order to not accidentally use and/or distribute the canary card identifiers to valid or not fraudulent users (e.g., employees). Thus, when a use of a canary card identifier is detected, the card processing system may want to notify the organization in order to secure transactions from additional fraud. To process a payment, a canary card identifier may be used and/or found in transaction data for a payment request on the payment network, for example, when the acquirer (e.g., the acquiring bank for the merchant that processes the payment instrument provided by the user) requests processing with the issuer (e.g., the issuing bank of the organization and expense management system that issues the payment instrument). This occurs when a user causes a transaction to be generated, and the merchant generates a total for the transaction request, which the user can pay for by providing a payment instrument to the merchant. After receiving the canary card identifier as the payment instrument, the merchant may cause a payment request to be generated for payment of the transaction. In various embodiments, the user may be required to enter additional checkout information, such as a name, delivery location, or other personal or financial information that may be included in the transaction data for the transaction. The card processing system may receive or detect the transaction data for the electronic transaction using the integration with the payment network and determine that the transaction data includes the canary card identifier.

In this regard, when transaction data having the canary card identifier for a transaction is detected and received, the card processing system may identify the canary card identifier as being used from a database lookup or query. The system may further determine what operations are to be executed when the canary card identifier is used. This may correspond to one or more alerts, types of alerts, and/or data for entry and transmission in the alerts to be generated and transmitted based on the use of the canary card identifier. Further, the data may identify which users, entities, digital addresses, phone numbers, or other endpoints are to be contacted and/or receive the alert. In various embodiments, other types of card data, transaction data, messages/communications, or other contextual data may be used for the alert. Additional contextual data may be any data associated with a transaction that may be detected and/or determined by the card processing system. For example, types of card data may include Level 2 (L2 or Level II) and/or Level 3 (L3 or Level III) card or transaction data that accompanies a credit or debit card transaction when the transaction is processed. L2 and/or L3 card data may include a purchase order number, a shipping address or zip code, a billing address or zip code, a destination location, a tax indicator and/or an amount, a consumer and/or merchant name, an item identifier (including an SKU, barcode, QR code, or the like), an item description or name, a price, a number or volume of the item, discounts or applied benefits, a merchant name and/or code, merchant information including an address or location, and similar data that may be used to further define the transaction and provide more detailed transaction information. For example, billing codes may be used to determine transaction information and assign that transaction to a category. Similarly, this card data may be used to determine where an employee or malicious party is conducting a transaction, making a purchase, travelling, or otherwise performing a transaction on behalf of the company and/or using the canary card identifier. For example, a plane ticket purchase may include a destination city as part of the card data.

L2 or L3 card data may be provided and processed during a transaction to provide more detailed information for the transaction, lower card processing fees, and/or enable better authentication and security for fraud analysis and protection. The L2 or L3 data may therefore provide more granular transaction data that may inform a user viewing the alert of the fraudulent activity. The alert may then be generated in real-time or near real-time during the transaction, and transmitted to the appropriate users, parties, contact addresses, and the like in real-time or near real-time so that alerts may be viewed during the fraudulent transaction processing. The receiving addresses may correspond to email, instant messaging, voice communication (e.g., telecommunication or VoIP), text messaging, social networking, microblogging, and other applications and communication services. The card processing system may then determine if further users or entities should be alerted, such as an authority, the merchant in the transaction, or the like. The card processing system may further decline processing and/or payment on the payment network based on the use of the canary card identifier, and/or the canary card identifier may not be processed by virtue of having a zero balance or designation that payments should not be processed using the canary card identifier. Thus, the transaction processing request for the transaction using the canary card identifier may be declined and/or prevented from processing

After a use of a canary card identifier and generation of an alert, the canary card identifier that was used may be burned, flagged, or otherwise identified as used and therefore likely to be recognized as invalid and/or a canary card. The card processing system may further generate one or more new canary card identifiers, which may be used to replace the burned canary card identifiers. However, in other embodiments, the canary card identifier may be left as open or usable in order to detect additional fraud by other malicious parties that may have compromised data from the organization. In some embodiments, the canary card identifier and/or alert may also include a functionality to approve the underlying transaction and/or supply a new payment source and/or valid card identifier. This may occur when an employee of the organization accidentally used the canary card identifier, but the underlying transaction was valid and/or approved. In further embodiments, the alert and/or use of the canary card identifier may further cause one or more account freezes or prevention of account and/or fund uses to be issued and/or execute. This may prevent further fraud where other valid card identifiers have also been compromised. Thus, the account freezing may be executed automatically or may be selected and initiated through the alert transmitted to one or more entities of the organization.

As such, systems and methods are provided to enable a company to better manage electronic transaction data and prevent fraud. This may be done by issuing specifically marked identifiers and implement a new and improved network and processing system to integrate with payment networks. Thus, alerts may be generated in real-time when use of a marked identifier is detected, and organizations may be provided with faster and coordinated messaging and communications to limit electronic fraud, data misappropriation, and other computing attacks that compromise sensitive data of the organizations. Further, additional data may be determined and recorded in order to document the fraudulent activities on payment networks.

FIG.1is a block diagram of a networked system100suitable for implementing the processes described herein, according to an embodiment. As shown, system100may comprise or implement a plurality of devices, servers, and/or software components that operate to perform various methodologies in accordance with the described embodiments. Exemplary devices and servers may include device, stand-alone, and enterprise-class servers, operating an OS such as a MICROSOFT® OS, a UNIX® OS, a LINUX® OS, or another suitable device and/or server-based OS. It can be appreciated that the devices and/or servers illustrated inFIG.1may be deployed in other ways and that the operations performed and/or the services provided by such devices and/or servers may be combined or separated for a given embodiment and may be performed by a greater number or fewer number of devices and/or servers. One or more devices and/or servers may be operated and/or maintained by the same or different entities.

System100includes a payment card110, a merchant device120, a user device130, and a service provider server140in communication over a network160. A user (not shown) may correspond to an employee, contractor, shareholder, or other suitable person (not shown and generally referred to herein as an “employee”) of a company associated with user device130, which may utilize payment card110to submit purchase requests for items to be paid using company funds. Payment card110may correspond to a payment instrument allowing for purchase of items using company funds, which may be provided and managed by service provider server140. However, payment card110may also correspond to a canary card and/or canary card identifier that does not have a balance and/or enable transaction processing but instead causes alerts to be generated when used. Service provider server140may process payments using payment card110and/or cause alerts to be generated based on use of payment card110. Further, service provider server140may interact with merchant device120for transaction processing and/or alert generation based on use of payment card110.

Merchant device120, user device130, and service provider server140may each include one or more processors, memories, and other appropriate components for executing instructions such as program code and/or data stored on one or more computer readable mediums to implement the various applications, data, and steps described herein. For example, such instructions may be stored in one or more computer readable media such as memories or data storage devices internal and/or external to various components of system100, and/or accessible over network160.

Payment card110may correspond to a physical and/or virtual payment card having a card identifier112that is supplied and/or read during transaction processing to effectuate a payment to another user, merchant, entity, or the like. In this regard, payment card110may be read by merchant device120and/or card identifier112may be provided to merchant device120for electronic transaction processing for a transaction. Payment card110may be issued to an employee using user device130and/or another employee, entity, division, team, or the like for an organization. Payment card110may be linked to a funding source, credit or bank account balance, or the like and may therefore be used to provide payments. In some embodiments, payment card110corresponds to a canary card, and/or card identifier112corresponds to a canary card identifier that instead causes one or more alerts to be generated on use. In such embodiments, payment card110may not be linked to a balance, have a zero balance and thus no underwriting, and/or may not be used for valid transaction processing.

Merchant device120may be maintained, for example, by a merchant or other entity selling one or more items to users, which may include single users or groups of independent users as well as small and large merchants. Merchant device120may provide the items for sale, such as through use of various software, infrastructure, websites, applications, and/or other platforms for advertisement, sale, and payment processing. In this regard, merchant device120may include a device having processing applications, which may be configured to interact with user device130and/or service provider server140to engage in transactions, for example, by processing a transaction processing request122using payment card110. In some embodiments, merchant device120may be implemented as a single or networked personal computers (PCs), a smart phone, laptop computer, wearable computing device, and/or other types of computing devices. Although only one merchant device is shown, a plurality of merchant devices may function similarly.

Merchant device120may be implemented with an application offering items for sale that may be accessed by a computing device to present the items for sale to the user associated with card identifier. In certain embodiments, the application may provide a website available over the Internet and/or online content and/or database information accessible through a dedicated application. The application may provide item sales through an online marketplace using the website of the merchant. The application may also correspond to a checkout application at a physical merchant location, such as the application(s) of a point-of-sale (POS) device used to provide sales at physical locations. Merchant device120may be used to establish a transaction once a user/employee associated with user device130has selected one or more items for purchase. Once a payment amount is determined for the item(s) to be purchased by the user, merchant device120may request payment using payment card110for transaction processing request122. After input, merchant device120may then process a payment to the merchant associated with merchant device120using payment card110. Service provider server140may utilize network integration with a payment resolution network to manage payment card110, approve transaction processing request122, and/or generate alerts when payment card110corresponds to a canary card that is used to identify fraudulent or abusive use of payment card110and/or card identifier112. Service provider server140may approve or deny the payment request based on if payment card110corresponds to a canary card. Transaction processing request122may then be processed, payment provided to the merchant account, and notification of payment (or failure, for example, where a canary card and/or canary card identifier is used) may be sent to merchant device120. Merchant device120may then receive the results of transaction processing request122and may further track and/or provide additional data, such as L2 or L3 card data for transaction processing.

User device130may be utilized by an employee of an organization or company that employs one or more users, for example, to receive one or more alerts from service provider server140in response to uses or canary cards, such as payment card110where designated as a canary card. For example, in one embodiment, user device130may be implemented as a personal computer (PC), telephonic device, a smart phone, laptop/tablet computer, wristwatch with appropriate computer hardware resources, eyeglasses with appropriate computer hardware (e.g. GOOGLE GLASS®), other type of wearable computing device, implantable communication devices, and/or other types of computing devices capable of transmitting and/or receiving data. In this regard, user device130includes one or more processing applications which may be configured to interact with service provider server140to manage payment card110and/or alerts provided by service provider server140and further provide data utilized by service provider server140. Although only one communication device is shown, a plurality of communication devices may function similarly.

User device130may be implemented with an application that may manage payment cards including canary cards and canary card identifiers, and further receive alerts in response to uses of canary card identifiers in transactions. In certain embodiments, the application may be configured to interface and/or communicate with service provider server140over network160. The application may receive an alert132from service provider server140via a text message, email, instant message, dashboard interface message for a digital account, or other communication channel. Alert132may be associated with a use of payment card110where payment card110corresponds to a canary card, and therefore alert132may include data regarding the use of payment card110. Alert132may be received in real-time or near real-time when use of payment card110occurs, such as when merchant device120attempts to process card identifier112in a transaction. Further, alert132may include information regarding the transaction and/or use of the canary card identifier for card identifier112by merchant device120. For example, the alert may include transaction information, information provided by the user requesting the transaction, and/or L2 or L3 card data. Alert132may further include one or more executable processes, such as those to approve the transaction and supply a valid payment instrument, contact an authority and/or the merchant for merchant device120, request burning or disposal of card identifier112, implementing a freeze on an account, or the like.

In various embodiments, the application may include a general browser application configured to retrieve, present, and communicate information over the Internet (e.g., utilize resources on the World Wide Web) or a private network. For example, the application may provide a web browser, which may send and receive information over network160, including retrieving website information, presenting the website information to the user, and/or communicating information to the website, including payment information. However, in other embodiments, the application may include a dedicated application of service provider server140or other entity, which may be configured to assist in establishing and maintaining payment and canary card identifiers, receive alerts, and/or interact with devices on one or more payment networks.

Service provider server140may be maintained, for example, by an online service provider, which may provide payment instruments and payment processing services to companies and other organizations. In this regard, service provider server140includes one or more processing applications which may be configured to interact with merchant device120and user device130to facilitate processing of payments and use of canary card identifiers, such as ones associated with payment card110. In one example, service provider server140may be provided by BREX®, Inc. of San Francisco, CA, USA. However, in other embodiments, service provider server140may be maintained by or include other types of credit providers, financial services providers, and/or other service provider, which may provide expense management services to companies.

Service provider server140ofFIG.1includes a card generator application150, transaction application142, a database144, and a network interface component146. Card generator application150and transaction application142may correspond to executable processes, procedures, and/or applications with associated hardware. In other embodiments, service provider server140may include additional or different modules having specialized hardware and/or software as required.

Card generator application150may correspond to specialized hardware and/or software to allow companies to receive payment instruments associated with a bank account and funding of the company, such as one or more company credit cards, and provide expense management for those issued payment instruments and additional funds/accounts of the company. In this regard, a company may first establish an account with expense management system by providing company data and onboard through card generator application150. Such information may include bank account and funding information, such as verified funding from investors, available funds directly in an account, and burn rate of company funds over a time period. If qualified, service provider server140and/or another issuing entity may provide a payment instrument that is managed by card generator application150. For example, service provider server140may issue payment card110for a real or virtual credit card or may issue other types of payment instruments and instrument identifiers that may be used for company payments.

Card generator application150may provide one or more processes accessible by an administrator or other employee of an organization to establish and issue payment instruments for use, including payment card110, where one or more of the payment instruments may correspond to canary identifiers that have a zero balance or are not valid for transaction processing but cause generation of alerts. In this regard, the administrator may establish and/or select types of payment instruments and corresponding payment instrument information, which correspond to attributes for a maximum purchase amount, maximum spend over a time period, merchant/item types, location, hours of purchase, etc. Card generator application150may further provide additional processes for use with requesting and/or establishing one or more canary card identifiers. The additional functionality and processes provided by card generator application150are described in more detail with regard to the additional Figures of the application, such asFIGS.2,3A,3B, and4.

Card generator application150may receive card generation requests152, which may request that payment cards, both physical and/or virtual cards, and their corresponding card identifiers154be generated. Card generation requests152may designate a number of payment cards and a corresponding credit or bank account balance for use with the valid payment cards and identifiers. Additionally, card generation requests152may designate a number of canary cards to be generated so that card identifiers154include valid card identifiers for use in transactions to effectuate payments and canary card identifiers156for generating alerts on use of canary card identifiers156. With canary card identifiers156, the administrator or other employee may designate devices, communication addresses or identifiers, communication channels, and/or users to receive the alerts when canary card identifiers156are used. The alerts may be transmitted to those users and/or devices in real-time and/or near real-time on use of canary card identifiers156. Further, card generation requests152may designate the additional transaction or contextual data to include with an alert, such as L2 or L3 card data detected during a transaction based on input by the merchant or other transaction data. The additional contextual data may include communications between parties and/or data entered by users for a transaction using one or more of canary card identifiers156, such as merchants and/or transaction requesters. For example, a location, client name, user identifier, or other information may be provided in an alert and used to determine fraud.

Transaction application142may provide one or more processes to process transactions, including transactions using card identifiers154and/or provide one or more alerts in response to detection of one or more of canary card identifiers156in the transactions. In this regard, transaction application142may include or provide one or more computing operations, services, and/or networks that may reside as one or more layers under a transaction processing flow for transactions processed over network160, such as between merchant device120and user device130. Transaction application142may utilize this integration with one or more payment networks to detect transaction processing request122from merchant device120, determine card identifier112used for transaction processing request122, and perform one or more database look ups or queries to determine if card identifier112corresponds to a canary card identifier. If not, transaction processing request122may be processed. However, if card identifier112corresponds to a canary card identifier, transaction processing request122may be declined or prevented from processing and transaction application142or another application may be used to issue alert132to user device130.

In various embodiments, transaction application142may be desired in particular embodiments to provide features to service provider server140. For example, transaction application142may include security applications for implementing server-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) over network160, or other types of application processes used to effectuate transactions, provide transaction processing security, and/or transmit one or more alerts based on detected uses of canary card identifiers156. Transaction application142may contain software programs, executable by a processor, including a graphical user interface (GUI), configured to provide an interface to the user when accessing service provider server140and/or managing transaction processing and accounts.

Additionally, service provider server140includes database144. As previously discussed, the user, entity, and/or organization corresponding to user device130may establish one or more accounts with service provider server140, which may be used to issue payment card110. Payment accounts in database144may include entity information, such as name, address, payment/funding information, additional user financial information, and/or other desired user data. Database144may also be used to store transaction data and information on issued payment instruments to the company and transactions processed using those instruments, including card identifiers154.

In various embodiments, service provider server140includes at least one network interface component146adapted to communicate with merchant device120and/or user device130over network160. In various embodiments, network interface component146may comprise a DSL (e.g., Digital Subscriber Line) modem, a PSTN (Public Switched Telephone Network) modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices.

Network160may be implemented as a single network or a combination of multiple networks. For example, in various embodiments, network160may include the Internet or one or more intranets, landline networks, wireless networks, and/or other appropriate types of networks. Thus, network160may correspond to small scale communication networks, such as a private or local area network, or a larger scale network, such as a wide area network or the Internet, accessible by the various components of system100.

Network160may correspond to a network utilized for resolution of payment requests and electronic transaction processing, which may be governed by permissions (e.g., acceptances and denials) of payment requests for transaction processing by service provider server140. In this regard, network160may correspond to a credit card or debit card network where an acquiring bank or entity may interact with an issuing bank or entity for the resolution of a payment using payment card110and/or detection of use of a canary card identifier corresponding to payment card110for generating and transmitting one or more alerts. However, in other embodiments, payment resolution network may correspond to other types of payment networks and payment types, such as direct debit payments (ACH payments), wire exchanges or payments, prepaid card payments, or regionally/company-specific payments.

Network160may be implemented or used by service provider server140on request by user device130, and may allow users to interact with the network to submit payments and process transactions, allow third parties (e.g., banks or other financial service intermediaries) to interact on the network on behalf of the user, and/or access or use data provided to or from the payment network, such as notifications of transactions and details that allow authorizing or declining transactions. Service provider server140may utilize network160in the managing, approval, denial, and data gathering associated with payment requests using company issued payment instruments associated with network160, such as payment card110.

FIG.2is an exemplary system environment200for matching receipt data to expense data in a transactional database, according to an embodiment. System environment200ofFIG.2includes a cloud infrastructure202that may be provided by a service provider in a cloud computing environment, such as by service provider server140discussed in reference to system100ofFIG.1. In this regard, an integration between cloud infrastructure202may be used to exchange data with and over a card network232so that usages of canary card identifiers during transaction processing may be detected and used to generate alerts to a customer204, such as through outside service alerts230. Cloud infrastructure202may be provided by a cloud computing service provider to the service provider using the canary card services discussed herein, such as by Amazon Web Services (AWS)® and the like.

In system environment200, customer204may interact with cloud infrastructure202when utilizing the corresponding computing services for financial accounts, payment cards, and electronic transaction processing, including those for generating valid and canary payment cards and identifiers. Customer204may correspond to an organization and/or employees or other users associated with the organization that utilizes the services provided by the service provider. In this regard, customer204may access and utilize the services provided by cloud infrastructure202through customer and dashboard services206. Customer and dashboard services206may provide one or more user interfaces, such as a dashboard interface, that may be used to request generation of payment cards and/or canary cards, as well as their corresponding identifiers, set alerts and data for alerts (e.g., receiving parties, data contained in alerts including L2 and L3 card data, and the like), and view alerts and other data generated from uses of canary card identifiers during electronic transaction processing. Customer and dashboard services206may further be used to otherwise interact with one or more digital accounts, financial services, and the like provided by the corresponding service provider.

Customer and dashboard services206may interact with a network card service208that manages payment card services between customer204and other customers or organizations and a vendor external partner214that may issue payment card identifiers. Network card service208interacts with a canary cards issuing service210that utilizes a canary cards API212to exchange API calls and requests, and any required data, with vendor external partner214. Canary cards API212may be used to request generation of payment and canary cards, and their corresponding identifiers, from vendor external partner214. Canary cards API212may transmit an API request generation of the card identifiers, as well as any physical or virtual cards, that include valid card identifiers that may be processed on card network232. Vendor external partner214may receive the request and execute operations to generate one or more alphanumeric card identifiers according to an identifier generation scheme. The card identifiers may further include canary card identifiers or other card identifiers that have a zero balance and/or may not initiate or complete a payment on card network232when used. In some embodiments, vendor external partner214may further flag or indicate that the canary card identifiers are to be used to generate and transmit an alert to customer204. However, this may be performed by or in conjunction with a canary cards manager service216of the service provider for cloud infrastructure202.

Canary cards manager service216may manage canary cards and canary card identifiers by establishing the canary card identifiers for alerts and designating the additional alert data for each canary card and/or set of canary cards. For example, the additional alert data may include the designation of the receiving parties, contact addresses or identifiers, and/or alert data (e.g., transaction time and/or location, transaction amount and items/services, additional card or transaction data, and the like as discussed in reference toFIGS.3A and3B). Canary cards manager service216may store canary card and/or valid card data, as well as canary card alerts and notifications, in a user/card database218and a canary cards notification database220. The canary card identifiers and other data, as well as valid card identifiers and data when generated, may then be provided to customer204, such as through one or more user interfaces provided by customer and dashboard services206. When providing the canary cards and identifiers, they may be noted to customer204as canary cards but may also not be marked as invalid or canary cards to other users and/or external (e.g., malicious parties). For example, in one or more data tables, documents, or spreadsheets that document the card identifiers to internal users and may be compromised by internal and/or external malicious users, the canary card identifiers may appear valid and/or associated with valid users or departments. Further, additional descriptions or data may entice use by malicious parties, such as by noting a high available credit balance, being associated with large departments or high-ranking employees, and the like.

Thereafter, during a canary card use234, a canary card and/or canary card identifier is attempted to be used during a transaction. Card network232may be used to process the canary card during canary card use234. Card network232may be integrated with and/or interact with one or more computing services for cloud infrastructure202to detect canary card use234. In this regard, card network232may exchange API calls with and/or send an API request to cloud infrastructure202. This may be done using a payment card environment228that resides underneath a transaction flow for processing payment card identifiers on card network232, where the payment card identifiers may be processed in conjunction with services provided by cloud infrastructure202.

Payment card environment228may interact with a network service226to stream events224to a canary cards service222. Network service226may be used to stream events224when detected by payment card environment228from card network232. Events224may correspond to Apache Kafka® event streaming services that streams data events from network service226as detected, where canary cards service222may then process the events. In this regard, events224may include one or more events from canary card use234on card network232. Thereafter, canary cards service222may interact with user/card database218and canary card notification database220to perform one or more database look ups and/or queries for data in data tables associated with canary card identifiers and corresponding alerts. Based on canary card use234, a matching canary card identifier may be determined by canary cards service222, and data for one or more alerts for transmission based on canary card use234may be determined. Thereafter, canary cards service222may generate an alert for customer204, which may be generated in real-time or near real-time with canary card use234. The alert may be output through platforms for outside service alerts230, such as one or more communication channels and/or services that may be used to communicate with customer204. For example, outside service alerts230may correspond to email, text message, messages via customer and dashboard services206, and the like. In some embodiments, outside service alerts230may be provided to employees of customer organizations through Slack™ or the like, such as using a Slack™ webhook.

FIG.3Ais an exemplary user interface300adisplaying a first alert generated from use of a canary card identifier during electronic transaction processing, according to an embodiment. A canary transaction alert302may be provided to a customer organization of a service provider, such as by service provider server140discussed in reference to system100ofFIG.1. In this regard, canary transaction alert302may be displayed by a computing device of an employee of the customer organization, such as on user device130discussed in reference to system100.

User interface300adisplays canary transaction alert302as an exemplary alert that may be generated and output responsive to use of a canary card and/or identifier in a transaction processing request, such as one requesting electronic transaction processing for a transaction between a user and a merchant. The use of the canary card and/or identifier may prevent the electronic transaction processing, for example, by having a zero balance or being ineligible for the electronic transaction processing and therefore returning a declined status. However, use of the canary card and/or identifier may cause an underlying service for a service provider and/or card processing system to generate canary transaction alert302when an event indicating the usage of the canary card and/or identifier is detected.

Canary transaction alert302may be transmitted to a user, employee, department, and/or contact address or dashboard portal designated for the canary card and/or organization. Canary transaction alert302may further be standardized by the corresponding service provider transmitting the canary card usage alerts or may be custom configured by the organization based on requested data for the use of the canary card. In this regard, canary transaction alert302includes an alert message304, a transaction time306, a merchant name308, a transaction amount310, a transaction type312, receipt information314, a card identifier316, a merchant category318, a merchant location320, a merchant website322, other information324, and support notification326. This data allows the corresponding organization to review canary transaction alert302and determine corresponding actions to take in order to resolve the attempted fraud and/or protect computing systems.

For example, transaction time306, merchant name308, and transaction amount310may each include information that allows the organization to determine when, where and/or with whom, and for how much the canary card was used. This may allow the organization to determine if the transaction was purposeful fraud or an accidental use by an employee. Similarly, transaction type312may show whether the canary card was present and physically provided and used during the transaction (e.g., a card-present and/or in-person transaction using a physical card) or digitally used (e.g., a card-not-present transaction, that may be conducted over a network or communication session). Receipt information314may be used to show a receipt, which may have items purchased, tax, signatures, tip, and the like. Card identifier316may also be used to designate the specific canary card used, as whether that canary card should be burned or made invalid, retained as valid to catch additional fraud, or whether an employee may have accidentally used.

Additional card and/or transaction information may allow determination of the fraudulent or malicious entity and/or the breach of data by the organization and/or an authority utilized by the organization to protect from fraud and/or reverse or recover from fraud. In this regard, merchant category, merchant location, and merchant website may be used to determine additional information about the merchant where the fraud occurred. This may be used to determine if the merchant is fraudulent or also a victim of a malicious entity that fraudulently uses misappropriated data. Other information324may include information determined from the transaction and/or payment network. In some embodiments, other information324may include L2 or L3 data captured for the transaction. However, other data for the transaction may also be determined from the merchant and/or payment network processing the transaction.

FIG.3Bis an exemplary user interface300bdisplaying a second alert generated from use of a canary card identifier during electronic transaction processing, according to an embodiment. A canary transaction alert328may be provided to a customer organization of a service provider, such as by service provider server140discussed in reference to system100ofFIG.1. In this regard, canary transaction alert328may be displayed by a computing device of an employee of the customer organization, such as on user device130discussed in reference to system100.

User interface300bdisplays canary transaction alert328as another exemplary alert that may be generated and output responsive to another use of a canary card and/or identifier in an additional transaction processing request. In this regard, canary transaction alert328may further include an alert message330, which may be changed or updated for the particular transaction or may include the same or similar information to alert message304. Canary transaction alert328further has fields for transaction time306, merchant name308, transaction amount310, transaction type312, receipt information314, card identifier316, merchant category318, merchant location320, merchant website322, other information324, and support notification326. However, as shown in user interface300b, different data is shown in one or more of the field for canary transaction alert328. Further, in some embodiments, the fields in canary transaction alert328may be changed or updated for the particular organization and/or canary card associated with generating canary transaction alert328when use of a corresponding canary card and/or identifier is detected.

FIG.4is an exemplary flowchart400for canary card identifiers for real-time usage alerts, according to an embodiment. Note that one or more steps, processes, and methods of flowchart400described herein may be omitted, performed in a different sequence, or combined as desired or appropriate.

At step402of flowchart400, a request for a set of card identifiers for payment cards is received. The request may designate a number of valid payment cards to be generated, as well as a number of canary payment cards that do not have a balance or credit or otherwise may not be processed but instead cause an alert to be generated. The request may be received by a service provider, such as an online transaction processor and/or card processing system that may provide computing services for the canary payment cards. These services may include detecting use of the canary cards, generating alerts, and/or transmitting the alerts in real-time or near real-time for the use of the canary cards. Further, the service provider may provide additional services, such as expense management, payment card issuance and/or underwriting services, payment card and digital account management, and the like.

At step404, the set of card identifiers having valid identifiers and canary card identifiers is generated. Valid identifiers may be generated for those payment cards meant for use with a balance, such as those payment cards that may have a debit or credit balance underwritten for the corresponding organization and/or employees of the organization. In this regard, the valid identifiers may be issued digitally and/or provided with physical payment cards. In contrast, the canary card identifiers may be generated without a valid or usable balance or credit, such as a zero balance or credit and/or not linked to the available credit balance underwritten for the organization. Instead, the canary card identifiers may be linked to alert generation data for alerts that are generated and transmitted to the organization in response to a use of the canary card identifiers.

At step406, the set is provided to a customer for use in transaction processing. The canary card identifiers may be made known to the organization when provided so that the organization will not issue or provide those to trusted employees for valid transaction processing. However, the service provider and/or the organization may create or store the valid identifiers in one or more data structures with the canary card identifiers. In this regard, if the data structure storing the card identifiers comprise compromised or misappropriated by an external malicious party, or if an internal malicious party gains access to the data structure, and fraud is attempted, the canary card identifiers may be used by such parties. This may be done while attempting use of multiple different cards by the malicious parties or the canary cards may be described to entice individual usage, and therefore the canary card identifiers allow for fraud alerts in real-time when comprised data is used.

At step408, a canary card identifier is received in a transaction processing request. The canary card identifier may be received when detecting use of the canary card identifier when a merchant or other payee device attempts processing of the transaction processing request over a payment network. An integration between the service provider's canary card system with the payment network may allow for listening to data processing events that include the canary card identifier. A database search or look up of the canary card identifier may occur with the transaction processing request, and when the canary card identifier is detected as such, alert generation data may be retrieved. In order to prevent processing of the transaction, at step412, processing of the transaction processing request is declined. The transaction processing request may be declined on the payment network by the service provider and/or by a card processing gateway, for example, if the canary card identifier is provided a zero balance or credit or is not a valid identifier for processing on the payment network. However, the canary card identifier may appear valid so that use by malicious parties is encouraged.

At step414, in real-time during the transaction processing request, an alert of the use of the canary card identifier is generated. The alert may be generated to coincide with the transaction processing request and may include data relevant to the underlying transaction where the canary card identifier was used. Thus, the alert may include data recording the use of the canary card identifier and may assist the organization and/or an authority with determining the culprit of the fraud and/or limiting additional fraud. At step416, the alert is output to the customer. The alert may be provided to the customer's organization, employees, and/or contact addresses/identifiers as designated by the customer for canary card alerts. This may be provided through a business communication channel and platform, such as Slack™ that allows Internet Relay Chat (IRC) features and/or IRC-like features for Internet chats and communications. In this regard, one or more channels, communication chains, and the like may be updated with an alert of the use.

Thus, using various embodiments discussed herein, companies and other organizations can better (e.g., more efficiently and more accurately) track and manage identifiers used for electronic transaction processing by tracking, alerting, and otherwise managing canary card identifiers. This allows for real-time alerts to be generated to minimize fraud caused by breaches of data. Accordingly, the various embodiments discussed herein provide improved data security techniques with faster and more coordinated data transmissions when data breaches occur and are detected.

FIG.5is a block diagram of a computer system500suitable for implementing one or more components inFIG.1, according to an embodiment. In various embodiments, the communication device may comprise a personal computing device (e.g., smart phone, a computing tablet, a personal computer, laptop, a wearable computing device such as glasses or a watch, Bluetooth device, key FOB, badge, etc.) capable of communicating with the network. The service provider may utilize a network computing device (e.g., a network server) capable of communicating with the network. It should be appreciated that each of the devices utilized by users and service providers may be implemented as computer system500in a manner as follows.

Computer system500includes a bus502or other communication mechanism for communicating information data, signals, and information between various components of computer system500. Components include an input/output (I/O) component504that processes a user action, such as selecting keys from a keypad/keyboard, selecting one or more buttons, image, or links, and/or moving one or more images, etc., and sends a corresponding signal to bus502. I/O component504may also include an output component, such as a display511and a cursor control513(such as a keyboard, keypad, mouse, etc.). An optional audio input/output component505may also be included to allow a user to use voice for inputting information by converting audio signals. Audio I/O component505may allow the user to hear audio. A transceiver or network interface506transmits and receives signals between computer system500and other devices, such as another communication device, service device, or a service provider server via network160. In one embodiment, the transmission is wireless, although other transmission mediums and methods may also be suitable. One or more processors512, which can be a micro-controller, digital signal processor (DSP), or other processing component, processes these various signals, such as for display on computer system500or transmission to other devices via a communication link518. Processor(s)512may also control transmission of information, such as cookies or IP addresses, to other devices.

Components of computer system500also include a system memory component514(e.g., RAM), a static storage component516(e.g., ROM), and/or a disk drive517. Computer system500performs specific operations by processor(s)512and other components by executing one or more sequences of instructions contained in system memory component514. Logic may be encoded in a computer readable medium, which may refer to any medium that participates in providing instructions to processor(s)512for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. In various embodiments, non-volatile media includes optical or magnetic disks, volatile media includes dynamic memory, such as system memory component514, and transmission media includes coaxial cables, copper wire, and fiber optics, including wires that comprise bus502. In one embodiment, the logic is encoded in non-transitory computer readable medium. In one example, transmission media may take the form of acoustic or light waves, such as those generated during radio wave, optical, and infrared data communications.

Some common forms of computer readable media includes, for example, floppy disk, flexible disk, hard disk, magnetic tape, any other magnetic medium, CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, RAM, PROM, EEPROM, FLASH-EEPROM, any other memory chip or cartridge, or any other medium from which a computer is adapted to read.

In various embodiments of the present disclosure, execution of instruction sequences to practice the present disclosure may be performed by computer system500. In various other embodiments of the present disclosure, a plurality of computer systems500coupled by communication link518to the network (e.g., such as a LAN, WLAN, PTSN, and/or various other wired or wireless networks, including telecommunications, mobile, and cellular phone networks) may perform instruction sequences to practice the present disclosure in coordination with one another.

Where applicable, various embodiments provided by the present disclosure may be implemented using hardware, software, or combinations of hardware and software. Also, where applicable, the various hardware components and/or software components set forth herein may be combined into composite components comprising software, hardware, and/or both without departing from the spirit of the present disclosure. Where applicable, the various hardware components and/or software components set forth herein may be separated into sub-components comprising software, hardware, or both without departing from the scope of the present disclosure. In addition, where applicable, it is contemplated that software components may be implemented as hardware components and vice-versa.

Software, in accordance with the present disclosure, such as program code and/or data, may be stored on one or more computer readable mediums. It is also contemplated that software identified herein may be implemented using one or more general purpose or specific purpose computers and/or computer systems, networked and/or otherwise. Where applicable, the ordering of various steps described herein may be changed, combined into composite steps, and/or separated into sub-steps to provide features described herein.

The foregoing disclosure is not intended to limit the present disclosure to the precise forms or particular fields of use disclosed. As such, it is contemplated that various alternate embodiments and/or modifications to the present disclosure, whether explicitly described or implied herein, are possible in light of the disclosure. Having thus described embodiments of the present disclosure, persons of ordinary skill in the art will recognize that changes may be made in form and detail without departing from the scope of the present disclosure. Thus, the present disclosure is limited only by the claims.