WO2024147971A1

WO2024147971A1 - Method and apparatus for providing dynamic interchange for payment card transactions

Info

Publication number: WO2024147971A1
Application number: PCT/US2023/086132
Authority: WO
Inventors: Max Levchin; Ned Jackson Lovely; Alexandra Lang Miller; Laurie Sellick; Johan Backman; Andrew Mahon
Original assignee: Affirm, Inc.
Priority date: 2023-01-03
Filing date: 2023-12-28
Publication date: 2024-07-11

Abstract

A method of facilitating a dynamic interchange in relation to a transaction associated with a payment card may include receiving pre-purchase information from a customer identifying a future transaction and indicating customer intent with respect to treatment of the future transaction, receiving an indication of a current transaction between a customer and a merchant using the payment card, and determining whether to assign the customer intent to the current transaction based on the pre-purchase information. The method may further include, in response to determining to assign the customer intent to the current transaction, providing coded information into an authorization message to indicate the customer intent and enable a payment processor handling transfer of funds to the merchant in association with completing the current transaction to apply a selected changeable interchange fee to the current transaction.

Description

METHOD AND APPARATUS FOR PROVIDING DYNAMIC INTERCHANGE FOR

PAYMENT CARD TRANSACTIONS

TECHNICAL FIELD

Example embodiments generally relate to financial industry technologies and, in particular, relate to apparatuses, systems, and methods for facilitating commerce and for enabling a dynamic interchange rate to be charged on different transactions based on customer intent.

BACKGROUND

The financial industry is comprised of many thousands of customers, merchants, lenders, borrowers, and other role players that all interact in various ways to enable customers to ultimately have access to goods and services provided by merchants or vendors. Credit and debit transactions have long been a way that individuals have managed point of sale transactions to ensure seamless transfer of funds from customers, or on their behalf, to merchants for relatively routine or small transactions. Meanwhile, obtaining a loan from a bank has long been the most common way of obtaining financing for non-routine or larger transactions.

In each of the cases above, a relatively rigid and pre-planned sequence of activities occurs before, during, and after the transaction is closed. The customer makes the decision up front as to which mechanism to employ, and the handling of the entire transaction after that initial decision is made follows existing and well-known paths to completion. While there is great flexibility in that many options are available to customers (particularly those with good credit), there is not much flexibility at all after the decision is made as to which option to select.

More recently, some payment cards have been provided to customers that give the customers the ability to pay now or convert to an installment loan. These payment cards give customers the flexibility to change the function of the card via a mobile application (or similar) between purchases, or before a next purchase. While such a payment card may be valued by customers for its flexibility, card issuers have not had flexibility with respect to dynamic compensation or interchange when a purchase is converted to a different transaction type than originally processed. In this regard, such payment cards typically have a fixed interchange rate that merchants pay in order to participate in the payment processing network that the payment card relies upon to effect fund transfers. For example, if the payment card is used in a pay- now transaction, the risk to the card issuer is low, and the interchange rate charged to the merchant may also be kept fairly low. However, if the same payment card is used instead as a vehicle for payment that is backed by a loan to the customer, the risk to the card issuer is increased. Thus, the card issuer may fairly expect to be able to charge the merchant a higher interchange rate.

Accordingly, some example embodiments may enable the provision of technical means by which to give card issuers the ability to utilize customer intent information to determine how a transaction conducted via payment card should be treated, and then encode information for provision to the payment processor to enable the payment processor to charge the merchant a different (or dynamic) interchange rate that has a fair correlation to the different attendant risk associated with the transaction.

BRIEF SUMMARY OF SOME EXAMPLES

In an example embodiment, a method of facilitating a dynamic interchange in relation to a transaction associated with a payment card may be provided. The method may include receiving pre-purchase information from a customer identifying a future transaction and indicating customer intent with respect to treatment of the future transaction, receiving an indication of a current transaction between a customer and a merchant using the payment card and determining whether to assign the customer intent to the current transaction based on the pre-purchase information. The method may further include, in response to determining to assign the customer intent to the current transaction, providing coded information into an authorization message to indicate the customer intent and enable a payment processor handling transfer of funds to the merchant in association with completing the current transaction to apply a selected changeable interchange fee to the current transaction.

In another example embodiment, an apparatus for facilitating a dynamic interchange in relation to a transaction associated with a payment card may include processing circuitry. The processing circuitry may be configured to receive pre-purchase information from a customer identifying a future transaction and indicating customer intent with respect to treatment of the future transaction, receive an indication of a current transaction between a customer and a merchant using the payment card, and determine whether to assign the customer intent to the current transaction based on the pre-purchase information. The processing circuitry may be further configured to, in response to determining to assign the customer intent to the current transaction, provide coded information into an authorization message to indicate the customer intent and enable a payment processor handling transfer of funds to the merchant in association with completing the current transaction to apply a selected changeable interchange fee to the current transaction.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING(S)

Having thus described the invention in general terms, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and wherein:

FIG. 1 illustrates a functional block diagram of a system for providing a selective financing and payment platform according to an example embodiment;

FIG. 2 illustrates a functional block diagram of an apparatus for defining a facilitation agent according to an example embodiment;

FIG. 3 illustrates a block diagram showing control flow for providing a dynamic interchange fee in accordance with an example embodiment;

FIG. 4 illustrates a block diagram for control flow associated with transaction handling involving a dynamic interchange fee in accordance with an example embodiment;

FIG. 5 shows a display screen illustrating pre-purchase identification information and selection options in accordance with an example embodiment; and

FIG. 6 illustrates a method for signaling customer intent to enable applying a dynamic interchange fee in accordance with an example embodiment.

DETAILED DESCRIPTION

Some example embodiments now will be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all example embodiments are shown. Indeed, the examples described and pictured herein should not be construed as being limiting as to the scope, applicability or configuration of the present disclosure. Rather, these example embodiments are provided so that this disclosure will satisfy applicable legal requirements. Like reference numerals refer to like elements throughout. Furthermore, as used herein, the term “or” is to be interpreted as a logical operator that results in true whenever one or more of its operands are true. As used herein, operable coupling should be understood to relate to direct or indirect connection that, in either case, enables functional interconnection of components that are operably coupled to each other. Additionally, when the term “data” is used, it should be appreciated that the data may in some cases include simply data or a particular type of data generated based on operation of algorithms and computational services, or, in some cases, the data may actually provide computations, results, algorithms and/or the like that are provided as services. As used in herein, the term "module" is intended to include a computer-related entity, such as but not limited to hardware, firmware, or a combination of hardware and software (i.e., hardware being configured in a particular way by software being executed thereon). For example, a module may be, but is not limited to being, a process running on a processor, a processor (or processors), an object, an executable, a thread of execution, and/or a computer. By way of example, both an application running on a computing device and/or the computing device can be a module. One or more modules can reside within a process and/or thread of execution and a module may be localized on one computer and/or distributed between two or more computers. In addition, these components can execute from various computer readable media having various data structures stored thereon. The modules may communicate by way of local and/or remote processes such as in accordance with a signal having one or more data packets, such as data from one module interacting with another module in a local system, distributed system, and/or across a network such as the Internet with other systems by way of the signal. Each respective module may perform one or more functions that will be described in greater detail herein. However, it should be appreciated that although this example is described in terms of separate modules corresponding to various functions performed, some examples may not necessarily utilize modular architectures for employment of the respective different functions. Thus, for example, code may be shared between different modules, or the processing circuitry itself may be configured to perform all of the functions described as being associated with the modules described herein. Furthermore, in the context of this disclosure, the term "module" should not be understood as a nonce word to identify any generic means for performing functionalities of the respective modules. Instead, the term "module" should be understood to be a modular component that is specifically configured in, or can be operably coupled to, the processing circuitry to modify the behavior and/or capability of the processing circuitry based on the hardware and/or software that is added to or otherwise operably coupled to the processing circuitry to configure the processing circuitry accordingly.

Some example embodiments described herein provide for a data processing platform that can be instantiated at an apparatus comprising configurable processing circuitry. The processing circuitry may be configured to execute various processing functions on financial data using the techniques described herein. The data processing platform may, for example, be configured to provide an information exchange via which multiple independent or even proprietary platforms may be connected to each other. As such, the data processing platform may be embodied as a selective financing and payment platform (i.e., SFP platform) that connects customers and merchants (or vendors) to banks, payment services, and/or a transaction facilitator within the financial industry. By enabling data between the players on or members of the platform to be shared, and by further providing customers with tools for using the platform to manage individual transactions based on signaled customer intent, customers may have increased flexibility for maximizing their access to the goods and services they desire or need at any given time, while enabling card issuers to be fairly compensated for the risks they take on in support of the customer. Moreover, the platform may be employed under the management of the facilitator to control the usage of data on mutually agreeable terms for all participants who access the platform. Accordingly, a commercial framework can be provided by a technical platform designed to connect customers with access to financial support to effect transactions in real time while enabling dynamic interchange rates to be charged in a way that is transparent to all of the parties involved. In other words, instead of merely initiating a platform for supporting transactions, example embodiments provide card issuers with technical means by which to determine when to change an interchange rate based on customer intent, and signal to payment processors that the merchant should be charged a corresponding different interchange rate for a given transaction in a transparent way. This stands in contrast to today’s paradigm in which unchangeable and fixed interchange rates are associated rigidly with each respective card or card type. The creation of one platform, managed by the facilitator, for the interaction of multiple parties to enable dynamic interchange provides a flexible and yet cohesive experience for customers and merchants that maximizes responsible access to financial freedom and satisfaction.

Notably, example embodiments do not aim to merely employ a computer to make a decision in a programmatic way based on informational inputs. To the contrary, example embodiments provide the technical tools by which communication of information that enables such decision to be made is enabled. As such, example embodiments not only provide the SFP platform, but also provide various enabling technologies that may facilitate operation of the SFP platform itself or of modules that may interact with the SFP platform. Example embodiments may also provide for enhancement of functionalities associated with the environment that is created by the SFP platform. The SFP platform may provide a mechanism by which to enhance commerce in a responsible way that is both empathetic and empowering to customers, while also rewarding card issuers based on the risk taken on for the transactions they enable.

An example embodiment of the invention will now be described in reference to FIG. 1, which illustrates an example system in which an embodiment of the present invention may be employed. As shown in FIG. 1, a system comprising an SFP platform 10 according to an example embodiment may include one or more client devices (e.g., clients 20). Notably, although FIG. 1 illustrates three clients 20, it should be appreciated that a single client or many more clients 20 may be included in some embodiments and thus, the three clients 20 of FIG. 1 are simply used to illustrate a potential for a multiplicity of clients 20 and the number of clients 20 is in no way limiting to other example embodiments. In this regard, example embodiments are scalable to inclusion of any number of clients 20 being tied into the system. Furthermore, in some cases, some embodiments may be practiced on a single client without any connection to the system.

The clients 20 may, in some cases, each be associated with a single individual or customer. However, in some embodiments, one or more of the clients 20 may be associated with an organization (e.g., a company) or group of individuals (e.g., a family unit). In general, the clients 20 may be referred to as members of the environment or community associated with the SFP platform 10.

Each one of the clients 20 may include one or more instances of a communication device such as, for example, a computing device (e.g., a computer, a server, a network access terminal, a personal digital assistant (PDA), radio equipment, cellular phone, smart phone, or the like) capable of communication with a network 30. As such, for example, each one of the clients 20 may include (or otherwise have access to) memory for storing instructions or applications for the performance of various functions and a corresponding processor for executing stored instructions or applications. Each one of the clients 20 may also include software and/or corresponding hardware for enabling the performance of the respective functions of the clients 20 as described below. In an example embodiment, the clients 20 may include or be capable of executing a client application 22 configured to operate in accordance with an example embodiment of the present invention. In this regard, for example, the client application 22 may include software for enabling a respective one of the clients 20 to communicate with the network 30 for requesting and/or receiving information and/or services via the network 30 as described herein. The information or services receivable at the client applications 22 may include deliverable components (e.g., downloadable software to configure the clients 20, or information for consumption/processing at the clients 20). As such, for example, the client application 22 may include corresponding executable instructions for configuring the client 20 to provide corresponding functionalities for sharing, processing and/or utilizing financial data as described in greater detail below.

The network 30 may be a data network, such as one or more instances of a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN) (e.g., the Internet), and/or the like, which may couple the clients 20 to devices such as processing elements (e.g., personal computers, server computers or the like) and/or databases. Communication between the network 30, the clients 20 and the devices or databases (e.g., servers) to which the clients 20 are coupled may be accomplished by either wireline or wireless communication mechanisms and corresponding communication protocols. In some embodiments, the network 30 may be communicatively coupled to, or include, a payment processing network 31, which serve as a platform for information exchange among card issuers, banks, merchants, customer and/or the like in connection with processing a card transaction for a payment card 33 (e.g., a credit card, debit card, or other card used by a customer to transfer funds to a merchant via the payment processing network 31) that may be presented by the customer (i.e., a customer associated with one of the clients 20) to the merchant for a transaction.

In an example embodiment, devices to which the clients 20 may be coupled via the network 30 may include one or more application servers (e.g., application server 40), and/or a database server 42, which together may form respective elements of a server network 32. Although the application server 40 and the database server 42 are each referred to as “servers,” this does not necessarily imply that they are embodied on separate servers or devices. As such, for example, a single server or device may include both entities and the database server 42 could merely be represented by a database or group of databases physically located on the same server or device as the application server 40. The application server 40 and the database server 42 may each include hardware and/or software for configuring the application server 40 and the database server 42, respectively, to perform various functions. As such, for example, the application server 40 may include processing logic and memory enabling the application server 40 to access and/or execute stored computer readable instructions for performing various functions. In an example embodiment, one function that may be provided by the application server 40 may be the provision of access to information and/or services related to the SFP platform 10, and more particularly relating to facilitating transactions where the details of setting the transaction will be determined after the transaction. For example, the application server 40 may be configured to provide for storage of information descriptive of events or activities associated with the SFP platform 10 and the execution of a financial transaction on behalf of a customer in real time, while delaying the customers decision on how to settle the transaction to a later time. In some cases, data and/or services may be exchanged amongst members, where specific needs or desires of the members are aligned with respect to playing their respective roles in connection with conducting a financial transaction, and enabling the settlement method for the transaction to be determined at a later time.

In some embodiments, for example, the application server 40 may therefore include an instance of a facilitation agent 44 comprising stored instructions for handling activities associated with practicing example embodiments as described herein. The facilitation agent 44 may be a technical device, component or module affiliated with the facilitator of the functioning of the SFP platform 10. Thus, the facilitation agent 44 may operate under control of the facilitator to be a technical means by which to carry out activities under direction of the facilitator or employees thereof. As such, in some embodiments, the clients 20 may access the SFP platform 10 services, and more particularly contact the facilitation agent 44 online and utilize the services provided thereby. However, it should be appreciated that in other embodiments, an application (e.g., the client application 22) enabling the clients 20 to interact with the facilitation agent 44 (or components thereof) may be provided from the application server 40 (e.g., via download over the network 30) to one or more of the clients 20 to enable recipient clients to instantiate an instance of the client application 22 for local operation such that the facilitation agent 44 may be a distributor of software enabling members or parties to participate in operation of the SFP platform 10. Alternatively, another distributor of the software may provide the client 20 with the client application 22, and the facilitation agent 44 may communicate with the client 20 (via the client application 22) after such download.

In an example embodiment, the client application 22 may therefore include application programming interfaces (APIs) and other web interfaces to enable the client 20 to conduct business via the SFP platform 10. The client application 22 may include a series of control consoles or web pages including a landing page, onboarding services, activity feed, account settings (e.g., user profile information), transaction management services, payment management services and the like in cooperation with a service application that may be executed at the facilitation agent 44. Thus, for example, the client application 22 may enable the customer to review monthly statements, request a physical payment card, turn on or off a virtual or digital card, access or adjust information associated with the customer account, or receive help or other information. Budgeting tools and other useful information and other useful tools for managing the finances of the customer may also be available via the client application 22 in some cases.

Moreover, in some cases, the client application 22 may be used to identify an item of merchandise or a service that the customer wishes to obtain via a transaction with the payment card 33. In such cases, the client application 22 may effectively make a pre-purchase identification of the item or transaction (e.g., identifying the merchant, product, amount, date and/or location of the purchase). The pre-purchase identification may include or be indicative of customer intent information, indicating an intent of the customer with respect to the type of transaction that should be processed for payment via the payment card 33. In other words, the pre-purchase identification may indicate whether the customer intends for the corresponding transaction to be treated as a debit transaction (i.e., pay now), or a financed transaction (i.e., pay later - with either a conventional loan backing the purchase, or a 0%, split pay, or installment loan option). The intent information may then be used (e.g., by the application server 40 (or more specifically by the facilitation agent 44)) to provide technical information injection into the communication stream over the network 30 (and/or payment processing network 31) to ensure that the transaction can be processed as intended.

In an example embodiment, the application server 40 may include or have access to memory (e.g., internal memory or the database server 42) for storing instructions or applications for the performance of various functions and a corresponding processor for executing stored instructions or applications. For example, the memory may store an instance of the facilitation agent 44 configured to operate in accordance with an example embodiment of the present invention. In this regard, for example, the facilitation agent 44 may include software for enabling the application server 40 to communicate with the network 30 and/or the clients 20 for the provision and/or receipt of information associated with performing activities as described herein. Moreover, in some embodiments, the application server 40 may include or otherwise be in communication with an access terminal (e.g., a computer including a user interface) via which individual operators or managers of the entity associated with the facilitation agent may interact with, configure or otherwise maintain the SFP platform 10 and/or the facilitation agent 44.

As such, the environment of FIG. 1 illustrates an example in which provision of content and information associated with the financial industry (e.g., including at least some data provided to/from customers and/or merchants in real-time) may be accomplished by a particular entity (namely the facilitation agent 44 residing at the application server 40). Thus, the facilitation agent 44 may be configured to handle provision of content and information associated with tasks that are associated only with the SFP platform 10. Access to the facilitation agent 44 may therefore be secured as appropriate for the individuals or organizations involved and credentials of individuals or organizations attempting to utilize the tools provided herein may be managed by digital rights management services or other authentication and security services or protocols that are outside the scope of this disclosure. The SFP platform 10 may also operate in cooperation with a bank authentication agent 50, an issuing bank agent 55, a merchant agent 60, a customer bank agent 70, and a payment processor 80. The facilitation agent 44 may be configured to interact with, or otherwise facilitate interactions between, each of the bank authentication agent 50, the issuing bank agent 55, the merchant agent 60, the customer bank agent 70, and the payment processor 80 in order to carry out example embodiments as described herein. Thus, each of the bank authentication agent 50, the issuing bank agent 55, the merchant agent 60, the customer bank agent 70, and the payment processor 80 should be understood to be a computer, server, smart phone, or other technical component or module associated with a respective party (e.g., an authenticating bank, issuing bank, a merchant, a customer bank, and a payment service, respectively) that is capable of communication with other parties via the network 30, and under control of or responsive to facilitating communication by the facilitation agent 44.

The issuing bank may be a bank or other financial services provider. The issuing bank may have a persistent relationship with the entity associated with the facilitation agent 44 (e.g., the facilitator), but generally need not have any persistent or pre-existing relationship with the customer or the customer bank. The issuing bank may be contracted with or otherwise have a pre-existing relationship with the facilitation agent 44 (and entity associated therewith) that enables the facilitation agent 44 to facilitate transactions on behalf of the customer when certain conditions (agreed upon in advance by the entity associated with the facilitation agent 44 and the issuing bank) are met associated with a transaction undertaken (or attempted) by the customer via the client 20 and client application 22. For example, the issuing bank may be the issuer of the payment card on behalf of the facilitation agent 44 and be responsible for directly paying the merchants and merchants during a transaction initiated by the customer via the payment card.

The bank authenticator may be an agent or financial service provider capable of granting the facilitation agent 44 access to the customer bank to view account balances and credentials. The balances and credentials may be used or relied upon to pull or push funds from or to the customer bank using the payment processor 80. Thus, for example, the bank authenticator may utilize its own software, application programming interfaces (APIs) or the like that define an infrastructure or intermediary platform to connect a customer’ s bank account with the facilitation agent 44.

The customer bank may be a bank at which the customer (i.e., associated with one of the clients 20) deposits money in a bank account such as a savings account or a checking account. In an example embodiment, the customer may subscribe or register to a service or request a physical payment card or other virtual or digital card) from the facilitation agent 44 to enroll the customer as a member of the SFP platform 10. During subscription or registration, the customer may be prompted (via the client 20 and client application 22) by the facilitation agent 44 to provide account details identifying the savings account or checking account (i.e., a customer account) at the customer bank. The customer may, by registering or subscribing, further authorize the facilitation agent 44 to conduct specific activities related to the customer account when corresponding conditions are met, which may be facilitated by one of or a combination of the bank authenticator and the issuing bank as described above. The activities may include checking account status (i.e., checking a current balance of funds deposited in the customer account) and/or authorizing withdrawal of funds from the customer account by the payment processor 80 in order to settle a transaction or make payments to the facilitation agent 44.

The payment processor 80 may be an agent or service that facilitates the acceptance and/or sending of payments between parties online. Thus, for example, the payment processor 80 may utilize its own software, application programming interfaces (APIs) or the like that define an infrastructure or payment platform to connect businesses or companies to manage their businesses or transactions online. In some embodiments, the payment processor 80 may be an operator of the payment processing network 31. However, it should be appreciated that in some cases, a gateway agent may sit between the merchant and the payment processing network 31. Thus, the payment processor 80 depicted should be understood to, in some cases, encompass or include both the payment processing network operator and any gateway agents that provide access to the payment processing network 31.

The customer bank agent 70 may change for each respective one of the clients 20 (and therefore for each respective customer). Similarly, the merchant agent 60 may change for each respective transaction since different merchants may be involved in different transactions involving the clients 20. In some examples, the bank authentication agent 50 and the payment processor 80 may remain the same entities across all transactions managed by the facilitation agent 44. However, the facilitation agent 44 could use different bank authentication agents in different geographic areas or jurisdictions, and the payment processor 80 may also change on the same bases. In some cases, the facilitation agent 44 may use different bank authentication agents 50 in order to ensure all customers’ banks can be accommodated. For example, if the customer bank was not serviced by a first bank authentication agent, the facilitation agent 44 is configured to swap in a second bank authentication agent that would allow for servicing of the customer bank. Accordingly, the facilitation agent 44 is configured to swap each of the payment processors 80 and the bank authentication agents 50 under certain circumstances. For example, the bank authentication agent 50 may be swapped by the facilitation agent 44 if the bank authentication agent 50 is temporarily offline or if the bank authentication agent 50 did not support a customer bank.

As noted above, the SFP platform 10 may operate to enable or otherwise support the customer associated with a given one of the clients 20 in making a purchase in real time from a merchant associated with the merchant agent 60. In some example embodiments, the client application 22 may be used in connection with setting up the account details that are then used as the basis for managing interactions between the parties shown in FIG. 1 under control of the facilitation agent 44. In this regard, for example, the client application 22 may be used to engage (e.g., via a website and corresponding APIs) with the facilitation agent 44 to set up an account with the facilitation agent 44 for services associated with the SFP platform 10. The facilitation agent 44 may prompt the client 20 to provide account details associated with the customer bank agent 70 and may provide terms and conditions (electronically or via mail or other communication means) that the customer may accept to establish a user profile and user account with the facilitation agent 44. In some cases, the customer may be provided with the payment card 33 (e.g., a debit card) or other physical implement that can be used to initiate transactions with merchants. As noted above, the payment card 33 may be issued by the facilitation agent 44. The card may be associated with the user account, and may provide identifying information needed to initiate operation of the SFP platform 10 (and the facilitation agent 44) as described herein when the customer uses the card to make a purchase with a merchant. The payment card 33 may be physically presented for such purpose and magnetic strip, chip or other technologies may be used in connection with initiating the transaction. Otherwise, the card number provided on the payment card 33 may be unique to the user account, and may be provided to the merchant to initiate the transaction. Finally, as an additional or alternative way to initiate a transaction, the payment card 33 may be virtual and may exist in a mobile wallet or other smartphone context for initiating transactions online. In such a context, the client application 22 may also or alternatively be the means by which the transaction is initiated or handled. Thus, it should be appreciated that the client application 22 could be used to set up the user account and user profile and/or to conduct individual transactions.

During establishment of the user account, the customer may provide an identification of the customer bank associated with the customer bank agent 70, and may also provide details for the savings or checking account that the customer maintains at the customer bank. The customer may also authorize the facilitation agent 44 to make real time (or anytime) checks on account status (e.g., account balance) or to make periodic routine checks of the same. Thus, for example, for each transaction, the facilitation agent 44 may be enabled to check the account balance of the customer. Alternatively or additionally, the facilitation agent 44 may make routine checks or snapshot looks at the account balance. For example, a check may be made every day at a certain time, every two or three days, or at other standard or random intervals. The account status of the customer bank may be used by the facilitation agent 44 in facilitating payment transactions, and issuing requested loans for such transactions as described in greater detail below.

The issuing bank may have an agreement or relationship with the entity associated with the facilitation agent 44 that enables the facilitation agent 44 to engage the issuing bank to extend funds to a merchant or merchant on behalf of the customer in response to instruction from the facilitation agent. The facilitation agent 44 may therefore coordinate communications and funds transferring between members or parties of the SFP platform 10 to facilitate payment transactions that can be settled later or in ways selected specifically by the customer. In this regard, the customer may approach the merchant (physically or virtually) in order to initiate a transaction. The payment card 33 (virtual or physical) may be provided for payment, and the corresponding indication of a pending transaction may be communicated (e.g., via the SFP platform 10 by the merchant agent 60 and/or the client 20) via the network 30. In an example embodiment, the merchant may recognize the transaction as a debit transaction, regardless of how it is actually handled between the facilitation agent 44 and the customer. The communication and activities that ensue thereafter will now be described greater detail below.

Regardless of how the transactions are initiated, the SFP platform 10 of FIG. 1 may be used before, during and after the time of the transaction in order to enable the facilitation agent 44 to set up the user account, make determinations necessary to initiate the transactions in real time responsive to initiation of the transaction, facilitate enabling the customer to decide the type of transaction to conduct with the merchant, and thereby indicate the customer’s intent for implementation into a technical transformation of such information into a tool for effecting the transaction in accordance with the customer’s intent. Each of these activities may have its own respective timing and communications that are facilitated by the facilitation agent 44 and FIGS. 3-5 illustrate example control flows and methods associated with an example scenario. However, prior to examining an example scenario in detail, the structures associated with an apparatus at which the facilitation agent 44 of an example embodiment may be instantiated will be described in reference to FIG. 2. FIG. 2 shows certain elements of an apparatus for provision of the facilitation agent 44 or other processing circuitry according to an example embodiment. The apparatus of FIG. 2 may be employed, for example, as the facilitation agent 44 itself operating at, for example, a network device, server, proxy, or the like (e.g., the application server 40 of FIG. 1)). Alternatively, embodiments may be employed on a combination of devices (e.g., in distributed fashion on a device (e.g., a computer) or a variety of other device s/computers that are networked together). Accordingly, some embodiments of the present invention may be embodied wholly at a single device (e.g., the application server 40) or by devices in a client/server relationship (e.g., the application server 40 and one or more clients 20). Thus, although FIG. 2 illustrates the facilitation agent 44 as including the components shown, it should be appreciated that some of the components may be distributed and not centrally located in some cases. Furthermore, it should be noted that the devices or elements described below may not be mandatory and thus some may be omitted or replaced with others in certain embodiments.

Referring now to FIG. 2, an apparatus for provision of tools, services and/or the like for facilitating an exchange for information and services associated therewith in the financial industry is provided. The apparatus may be an embodiment of the facilitation agent 44 or a device of the SFP platform hosting the facilitation agent 44. As such, configuration of the apparatus as described herein may transform the apparatus into the facilitation agent 44. In an example embodiment, the apparatus may include or otherwise be in communication with processing circuitry 100 that is configured to perform data processing, application execution and other processing and management services according to an example embodiment of the present invention. In one embodiment, the processing circuitry 100 may include a storage device (e.g., memory 104) and a processor 102 that may be in communication with or otherwise control a user interface 110 and a device interface 120. As such, the processing circuitry 100 may be embodied as a circuit chip (e.g., an integrated circuit chip) configured (e.g., with hardware, software or a combination of hardware and software) to perform operations described herein. However, in some embodiments, the processing circuitry 100 may be embodied as a portion of a server, computer, laptop, workstation or even one of various mobile computing devices. In situations where the processing circuitry 100 is embodied as a server or at a remotely located computing device, the user interface 110 may be disposed at another device (e.g., at a computer terminal) that may be in communication with the processing circuitry 100 via the device interface 120 and/or a network (e.g., network 30). The user interface 110 may be in communication with the processing circuitry 100 to receive an indication of a user input at the user interface 110 and/or to provide an audible, visual, mechanical or other output to the user. As such, the user interface 110 may include, for example, a keyboard, a mouse, a joystick, a display, a touch screen, a microphone, a speaker, augmented/virtual reality device, or other input/output mechanisms. In embodiments where the apparatus is embodied at a server or other network entity, the user interface 110 may be limited or even eliminated in some cases. Alternatively, as indicated above, the user interface 110 may be remotely located.

The device interface 120 may include one or more interface mechanisms for enabling communication with other devices and/or networks. In some cases, the device interface 120 may be any means such as a device or circuitry embodied in either hardware, software, or a combination of hardware and software that is configured to receive and/or transmit data from/to a network (e.g., network 30) and/or any other device or module in communication with the processing circuitry 100. In this regard, the device interface 120 may include, for example, an antenna (or multiple antennas) and supporting hardware and/or software for enabling communications with a wireless communication network and/or a communication modem or other hardware/software for supporting communication via cable, digital subscriber line (DSL), universal serial bus (USB), Ethernet or other methods. In situations where the device interface 120 communicates with a network, the network 30 may be any of various examples of wireless or wired communication networks such as, for example, data networks like a Local Area Network (LAN), a Metropolitan Area Network (MAN), and/or a Wide Area Network (WAN), such as the Internet, as described above.

In an example embodiment, the memory 104 may include one or more non-transitory storage or memory devices such as, for example, volatile and/or non-volatile memory that may be either fixed or removable. The memory 104 may be configured to store information, data, applications, instructions or the like for enabling the apparatus to carry out various functions in accordance with example embodiments of the present invention. For example, the memory 104 could be configured to buffer input data for processing by the processor 102. Additionally or alternatively, the memory 104 could be configured to store instructions for execution by the processor 102. As yet another alternative, the memory 104 may include one of a plurality of databases (e.g., database server 42) that may store a variety of files, contents or data sets. Among the contents of the memory 104, applications (e.g., a service application configured to interface with the client application 22) may be stored for execution by the processor 102 in order to carry out the functionality associated with each respective application. The processor 102 may be embodied in a number of different ways. For example, the processor 102 may be embodied as various processing means such as a microprocessor or other processing element, a coprocessor, a controller or various other computing or processing devices including integrated circuits such as, for example, an ASIC (application specific integrated circuit), an FPGA (field programmable gate array), a hardware accelerator, or the like. In an example embodiment, the processor 102 may be configured to execute instructions stored in the memory 104 or otherwise accessible to the processor 102. As such, whether configured by hardware or software methods, or by a combination thereof, the processor 102 may represent an entity (e.g., physically embodied in circuitry) capable of performing operations according to embodiments of the present invention while configured accordingly. Thus, for example, when the processor 102 is embodied as an ASIC, FPGA or the like, the processor 102 may be specifically configured hardware for conducting the operations described herein. Alternatively, as another example, when the processor 102 is embodied as an executor of software instructions, the instructions may specifically configure the processor 102 to perform the operations described herein.

In an example embodiment, the processor 102 (or the processing circuitry 100) may be embodied as, include or otherwise control the facilitation agent 44, which may be any means such as a device or circuitry operating in accordance with software or otherwise embodied in hardware or a combination of hardware and software (e.g., processor 102 operating under software control, the processor 102 embodied as an ASIC or FPGA specifically configured to perform the operations described herein, or a combination thereof) thereby configuring the device or circuitry to perform the corresponding functions of the facilitation agent 44 as described below.

The facilitation agent 44 may be configured to include tools to facilitate the creation of customer or user accounts (and a corresponding user profile), and the coordination of communication and fund transfers to support the operations of the SFP platform 10 as described herein. The tools may be provided in the form of various modules that may be instantiated by configuration of the processing circuitry 100. FIG. 2 illustrates some examples of modules that may be included in the facilitation agent 44 and that may be individually configured to perform one or more of the individual tasks or functions generally attributable to the facilitation agent 44 according to an example embodiment. However, the facilitation agent 44 need not necessarily be modular. In cases where the facilitation agent 44 employs modules, the modules may, for example, be configured to perform the tasks and functions described herein. In some embodiments, the facilitation agent 44 and/or any modules comprising the facilitation agent 44 may be any means such as a device or circuitry operating in accordance with software or otherwise embodied in hardware or a combination of hardware and software (e.g., processor 102 operating under software control, the processor 102 embodied as an ASIC or FPGA specifically configured to perform the operations described herein, or a combination thereof) thereby configuring the device or circuitry to perform the corresponding functions of the facilitation agent 44 and/or any modules thereof, as described herein.

As shown in FIG. 2, the facilitation agent 44 may include an intent determination module 140. The intent determination module 140 may be configured to record data associated with pre-purchase information received from the customer in a log, database or other memory device (e.g., in memory 104) so that the recorded data can be compared to a transaction in real time when the transaction occurs to attempt to correlate the current, real time transaction with a previously identified future (i.e., “future” at the time of identification) transaction that was indicated in the pre-purchase information. When the comparison indicates a match between the pre-purchase information and the current transaction, the intent expressed by the customer as to how to handle the future transaction will be associated with the current transaction so that the authorization message that is issued for the current transaction can be coded to signal the intention to the payment processor 80.

In this regard, for example, when interacting with the facilitation agent 44 to make a pre-purchase identification, the facilitation agent 44 may become aware of, and record, information associated with the item or transaction that the user intends to purchase in the future. In some cases, the pre-purchase information in the pre-purchase identification may be entered by the customer via an API or other user interface to identify the merchant, product, amount, date and/or location of the intended future purchase. The pre-purchase identification may include or be indicative of customer intent information, indicating an intent of the customer with respect to the type of transaction that should be processed for payment via the payment card 33. In other words, the pre-purchase identification may indicate whether the customer intends for the corresponding transaction to be treated as a pay-now transaction where the customer pays at the time of the transaction, or a financed transaction where the customer intends to cover the cost of the transaction by a loan (e.g., installment loan). The intent determination module 140 may be configured to generate an intent signal 142 based on the customer intent information, where the intent signal at least distinguishes between pay now and pay later options.

The facilitation agent 44 may also include a transaction coding module 150. The intent signal 142 generated by the intent determination module 140 may then be provided to a transaction coding module 150 to enable the transaction coding module 150 to generate coded information 152 for inclusion in the authorization message 154 provided to the payment processor 80 when the payment card 33 is presented at the transaction. The authorization message 154 is typically a message of a limited number of characters or fields, where the fields are structured in a particular way that is defined by protocol for communication over the payment processing network 31. Thus, there is very limited capacity to modify the authorization message 154. The coded information 152 is therefore used to provide technical information injection into the communication stream over the payment processing network 31 that can be recognized and acted upon to ensure that the transaction is processed as intended. Within one payment processing network, the coded information 152 may be provided in the expansion field. In other payment processing networks, a similar field may be employed.

In an example embodiment, the coded information 152 may include a dynamic interchange indicator that indicates that either a normal or increased interchange rate may be charged for the transaction. In this regard, since a pay now transaction (e.g., a debit transaction) is low risk for the card issuer, the card issuer or facilitation agent may be authorized to take a relatively lower interchange fee from the merchant for facilitating the transaction (which benefits the merchant). However, if the transaction is instead a pay later transaction (e.g., an installment or conventional loan backed transaction), the card issuer or facilitation agent is taking on a higher risk of non-repayment. The taking on of higher risk for the benefit of the merchant (who otherwise may not have the corresponding sale associated with the transaction) may fairly entitle the card issuer or facilitation agent to a higher interchange fee from the merchant for facilitating the transaction. By providing the coded information 152 in the authorization message 154, the facilitator notifies the payment processor 80 that the transaction is pay now or pay later, and that the interchange fee may be adjusted accordingly and its reason for adjustment may also be tracked for informing the merchant to substantiate the charge. This capability allows a dynamic interchange fee to not only be charged, but to be substantiated. However, beyond merely allowing such charge to be made, the coded information 152 actually provides the only technical way that such information can be provided in the restricted communication environment that is defined strictly by the communication protocols of the payment processing network 31.

In an example embodiment, the transaction coding module 150 may provide the coded information 152 in the form of an identification of a separate account that is to be charged for each respective different transaction (e.g., pay now or pay later). Thus, for example, a first account may be charged for pay now transactions, and by identifying the first account in the coded information 152, the payment processor 80 may be informed that the transaction is a pay now transaction and charge the corresponding interchange fee. Meanwhile, a second account may be charged for pay later transactions, and by identifying the second account in the coded information 152, the payment processor 80 may be informed that the transaction is a pay later transaction and charge the corresponding (presumably higher) interchange fee.

FIG. 3 is a block diagram showing integration of the payment card 33 and facilitation agent 44 into a control flow diagram in accordance with an example embodiment. As shown in FIG. 3, a customer 200 and a merchant 205 may engage in a transaction 210, which may be conducted using the payment card 33. Meanwhile, the customer 200 may have previously provided pre-purchase information 220 to the facilitation agent 44. As noted above, when the transaction 210 occurs, the merchant 205 may request authorization for the charge via authorization request 225. The payment processor 80 may receive the authorization request 225 and translate or otherwise pass the authorization request 225’ on to the facilitation agent 44. The facilitation agent 44 may perform any needed account balance checks (e.g., from the customer’s external account 230) that are needed to confirm that the transaction 210 is approved, but may also compare the pre-purchase information 220 to information identifying the transaction in the authorization request 225’ to determine if the authorization request 225’ is apparently associated with a pre-purchase activity previously identified by the customer 200 using the pre-purchase information 220. If the transaction is not associated with any instance of the pre-purchase activity previously identified by the customer 200 using the prepurchase information 220, the transaction 210 may be approved or declined normally. If the transaction is associated with any instance of the pre-purchase activity previously identified by the customer 200 using the pre-purchase information 220, the transaction 210 may be approved or declined normally, but may further be modified to include the coded information 152 described above. If approved, the facilitation agent 44 may communicate via authorization message 240, which may be translated or otherwise passed along as authorization 245 to the merchant 205, and may include the coded information 152.

As noted above, the coded information 152 may include a dynamic interchange indicator that indicates that either a normal or increased interchange rate may be charged for the transaction. In some embodiments, the dynamic interchange indicator may take the form of an identification of a different account from which funds are to flow on behalf of the customer 200 to the merchant 205. In this regard, an issuing bank 250 may have a for benefit of (FBO) account 252 for the facilitator associated with the facilitation agent 44, via which the facilitator transfers funds for the benefit of its various customers when transactions are initiated via respective instances of issued payment cards. The FBO account 252 may further have sub-accounts including a first account 254 and a second account 256. As noted above, the first account 254 may be associated with pay now transactions and the second account 256 may be associated with pay later transactions. The coded information 152 may include information indicating which account (among the first and second accounts 254 and 256) should be used to provide funds to the merchant 205 for the transaction 210. The account used may be indicative of the type of transaction so that the corresponding appropriate interchange fee can be charged based on the attendant risk to the transaction 210. Within this context, the day on which the transaction 210 occurs may be considered to be day 0 in the timeline of events associated with the transaction 210. Also on day 0, and as an immediate result of the transaction 210 being approved via the processes described above, an authorization for funds to be transferred to the merchant 205 may be issued by the issuing bank 250. The issuing bank 250 may also conduct a settlement transfer between day 0 and day 3 after the transaction 210 as part of settlement activity for the transaction 210 with the merchant 205.

In some cases, money may transfer (e.g., about at day 2) for any cases where a pay now or pay later option (e.g., a conventional or installment loan was intended for the transaction 210) is made using the processes described above. The customer’s external account 230 (i.e., at the customer bank) may also be available to transfer funds via the payment processor 80 to the issuing bank 250. Loan maintenance activity may then be initiated and managed directly between the customer 200 and the facilitator thereafter and managed via processes outside the scope of this disclosure. However, and importantly, regardless of the strict limitations on message structures that are associated with the payment processing network 31, the payment processor 80 may be informed through technical means that a particular transaction is to be handled in a corresponding particular way, and that in certain cases (e.g., pay later cases), a dynamic interchange fee may be employed. This may enable the risk attendant to the transactions processing to be adjusted dynamically without changing anything else about the way the system operates. Effectively, the coded information 152 allows a new function to be integrated into an old and somewhat rigid technical context, thereby retrofitting the system to include the new function without changing the system.

FIG. 4 illustrates a block diagram describing control flow and decision processes that occur based on the interactions described in FIG. 3. In this regard, as shown in FIG. 4, a customer may initially attempt to initiate a transaction at operation 300. A determination may then be made as to whether intent information can be determined to be associated with the transaction at operation 310. This determination may include the comparison described above. If no intent information can be determined to be associated with the transaction, the transaction may be handled in a default manner (e.g., as a debit transaction) at operation 320. The transaction may thereafter be processed as a debit transaction at operation 330. Transfer of funds from a pay now account may be conducted thereafter, and the customer’s external account may be debited at operation 340. Note that these activities are not necessarily instantaneous and may, in some cases, be conducted over days.

If intent information can actually be determined to be associated with the transaction at operation 310, then a further determination may be made at operation 350 as to whether the transaction was intended to be a pay now transaction (or pay later). If the intent was for the transaction to be handled as a pay now transaction, the same default processing described above may be performed at operation 320. However, operation 320 could alternatively include an actively signaled indication that the intent of the customer is for a pay now transaction. In either case, flow may proceed through operations 330 and 340, as described above.

However, if instead the transaction was intended for pay later processing (or conversely not intended for pay now processing), signaling may be initiated for indicating that the transaction is a pay later, or interest/installment loan at operation 360. As noted above, this signaling may be accomplished via the coded information 152. Thereafter, the transaction may be processed as a pay later or loan transaction at operation 370, and funds may be transferred from a pay later account at operation 380.

The comparison of information that is used to determine whether to associate the customer intent expressed in the pre-purchase information 220 with a current transaction is reliant upon receiving and recording information indicative of that intent. In an example embodiment, the obtaining of the intent information and the expression of the intent in association with the authorization message 240 may be accomplished over two different networks, which further accentuates the need for the processing described herein, and for the technical tool of providing the coded information 152 in a format that suits the second of these two different networks. The first network (e.g., network 30) may be any conventional communication network, whereas the second of these two networks may be a rigidly structured or protocoled network (e.g., the payment processing network 31). The coded information 152 serves as a technical bridge between these two different networks for the translation of the intent information into a useful form in the second network. In an example embodiment, the receipt of the intent information in the first network may be accomplished via the input of such information into a display of a communication device of the customer (e.g., a cell phone, tablet, laptop or other computer of the customer). FIG. 5 illustrates an example display for providing a selection that indicates the intent information. However, it should be appreciated that other forms may be used to provide such information. In any case, FIG. 5 shows a display screen 400 illustrating pre-purchase identification information 410 and selection options 420. The selection options 420 may include, for example, credit 422, debit 424, installment loan 426, or other options 428.

In an example embodiment, the intent determination module 140 may further include a machine learning module 145 that may facilitate the comparing of information discussed above. The machine learning module 145 may employ one or more instances of a neural network (e.g., a CNN), a support vector machine (SVM), Bayesian network, logistic regression, logistic classification, decision tree, ensemble classifier or other machine learning model to process inputs received by the machine learning module 145 to generate inferences based on the information received to determine whether or not the future transaction matches the current transaction based on the recorded data associated with the future transaction and corresponding data associated with the current transaction. In this regard, the volume of information that must be considered is both very high, and potentially also very diverse. The form of data is such that confusion may exist as to what data is actually usable for comparison given that fields and naming conventions may be wildly varied. The machine learning module 145 may use the long arc of time and massive volumes of examples to help the intent determination module 140 spot matches that would be impossible for humans or even normal computers to find, since the data would otherwise need to be formatted identically to permit finding matches at all, much less finding such matches in a short time needed to provide the speeds of processing required to make example embodiments practical. Thus, the machine learning module 145 may be particularly adept at finding matches in situations where large volumes of diverse data much be considered.

The machine learning module 145 may be supervised (identifying patterns in raw data upon which inference processes are desired to be performed via training examples) or unsupervised (identifying patterns in raw data upon which inference processes are desired to be performed without training examples). In an example embodiment, the machine learning module 145 may include a neural network of nodes where each node includes input values, a set of weights, and an activation function. The neural network node may calculate the activation function on the input values to produce an output value. The activation function may be a non-linear function computed on the weighted sum of the input values plus an optional constant. Neural network nodes may be connected to each other such that the output of one node is the input of another node. Moreover, neural network nodes may be organized into layers, each layer comprising one or more nodes. The neural network may be trained and update its internal parameters via backpropagation during training. A CNN may be a type of neural network that further adds one or more convolutional filters (e.g., kernels) that operate on the outputs of the preceding neural network layer to produce and output to then next layer. The convolutional filters may have a window in which they operate, which is spatially local. A node of a preceding layer may be connected to a node in the current layer if the node of the preceding layer is within the window. If not within the window, then the nodes are not connected.

In an example embodiment, training may occur via the provision of training data (e.g., training transactional data, etc.) along with target data that includes previously made successful matches associated with various matching models stored in the memory 104 and accessible to the machine learning module 145. Thereafter, when inferences are to be drawn with respect to a new set of data including new transactional information to provide an output that is indicative of matches, training backpropagation may be provided to update the learning.

Regardless of the specific form of the machine learning module 145, machine learning may be performed to perform inferences with respect to massively large volumes of data that would take normal computer processing very long periods of time to handle. The machine learning module 145 can handle massive volumes of data, and identify the data pertinent to a given transaction and to particular aspects of the transaction, within constraints that may be unique to the given user, in the context of mountains of information, within seconds, whereas doing so with conventional processing tools (i.e., without machine learning) would take orders of magnitude longer periods of time. The machine learning module 145 therefore enables an acceleration of the processing needed to conduct processing of data, but also to find deep patterns that are meaningful with respect to identifying matches within constraints that apply.

From a technical perspective, the SFP platform 10, and more particularly the facilitation agent 44, described above may be used to support some or all of the operations described above. As such, the apparatus described in FIG. 2 may be used to facilitate the implementation of several computer program and/or network communication based interactions. As an example, FIG. 5 is a flowchart of a method and program product according to an example embodiment of the invention. It will be understood that each block of the flowchart, and combinations of blocks in the flowchart, may be implemented by various means, such as hardware, firmware, processor, circuitry and/or other device associated with execution of software including one or more computer program instructions. For example, one or more of the procedures described above may be embodied by computer program instructions. In this regard, the computer program instructions which embody the procedures described above may be stored by a memory device of a user terminal (e.g., client 20, application server 40, and/or the like) and executed by a processor in the user terminal. As will be appreciated, any such computer program instructions may be loaded onto a computer or other programmable apparatus (e.g., hardware) to produce a machine, such that the instructions which execute on the computer or other programmable apparatus create means for implementing the functions specified in the flowchart block(s). These computer program instructions may also be stored in a computer- readable memory that may direct a computer or other programmable apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture which implements the functions specified in the flowchart block(s). The computer program instructions may also be loaded onto a computer or other programmable apparatus to cause a series of operations to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus implement the functions specified in the flowchart block(s).

Accordingly, blocks of the flowchart support combinations of means for performing the specified functions and combinations of operations for performing the specified functions. It will also be understood that one or more blocks of the flowchart, and combinations of blocks in the flowchart, can be implemented by special purpose hardware-based computer systems which perform the specified functions, or combinations of special purpose hardware and computer instructions.

In this regard, a method of facilitating a dynamic interchange in relation to a transaction associated with a payment card according to one embodiment of the invention is shown in FIG. 6. The method may include receiving pre-purchase information from a customer identifying a future transaction and indicating customer intent with respect to treatment of the future transaction at operation 500, receiving an indication of a current transaction between a customer and a merchant using the payment card at operation 510, and determining whether to assign the customer intent to the current transaction based on the pre-purchase information at operation 520. The method may further include, in response to determining to assign the customer intent to the current transaction, providing coded information into an authorization message to indicate the customer intent and enable a payment processor handling transfer of funds to the merchant in association with completing the current transaction to apply a selected changeable interchange fee to the current transaction at operation 530.

In an example embodiment, an apparatus for performing the method of FIG. 6 above may comprise a processor (e.g., the processor 102) or processing circuitry configured to perform some or each of the operations (500-530) described above. The processor may, for example, be configured to perform the operations (500-530) by performing hardware implemented logical functions, executing stored instructions, or executing algorithms for performing each of the operations. In some embodiments, the processor or processing circuitry may be further configured for additional operations or optional modifications to operations 500 to 530.

In some embodiments, the method (and a corresponding apparatus or system configured to perform the operations of the method) may include (or be configured to perform) additional components/modules, optional operations, and/or the components/operations described above may be modified or augmented. Some examples of modifications, optional operations and augmentations are described below. It should be appreciated that the modifications, optional operations and augmentations may each be added alone, or they may be added cumulatively in any desirable combination. In this regard, for example, receiving pre-purchase information may include receiving a pre-purchase identification of the merchant, a product, an amount, a date and location of the future transaction. In an example embodiment, the customer intent may be indicated by customer selection of an option presented on a display of a communication device of the customer, the option selected indicating a type of transaction to be processed for payment via the payment card for the future transaction. In some embodiments, the type of transaction of the option selected may be either (1) a pay now or debit transaction, or (2) a pay later or loan transaction. In an example embodiment, determining whether to assign the customer intent to the current transaction may include comparing the future transaction to the current transaction to determine a match between recorded data associated with the future transaction and corresponding data associated with the current transaction. In some cases, the pre-purchase information may be received via a first communication network, and the authorization message may be communicated via a payment processing network. In an example embodiment, the authorization message may have a format defined by protocol for the payment processing network to have a limited number of characters or fields, and the coded information may be disposed in a selected portion of the authorization message without modifying the format of the authorization message. In some cases, the coded information may include a dynamic interchange indicator that indicates that either a normal or increased interchange rate is to be charged to the merchant for the current transaction. In an example embodiment, the dynamic interchange indicator may identify a first account or a second account as a source for funds to transfer to the merchant for the current transaction. In some cases, the first account may be associated with a pay now or debit transaction, and the second account may be associated with a pay later or loan transaction.

The processes described above generally relate to situations where a current transaction can be handled based on customer intent previously set forth when identifying a future transaction that is to be handled a particular way at some time in the past. If a match cannot be confirmed, for example, because there was not sufficient matching information uncovered in the comparison step noted above to permit a conclusion of a match, the customer may nevertheless have the opportunity to engage in a conversion activity after the fact that may still engage the above-described dynamic interchange capability. In this regard, for example, if the customer engages in a transaction at operation 300 above, and no intent information can be inferred at operation 310, or if a pay now transaction is elected at operation 350, flow may proceed to operation 320 and pay now processing may occur. Thus, for example, the transaction may be handled as a debit transaction (at operation 330). Rather than immediately proceed to operation 340 as shown in FIG. 4, flow may be interrupted by a post-purchase financing option window at optional operation 335 during which the customer may decide to turn the debit transaction into a loan. The post-purchase financing option window may, for example, be a 24 hour window, or any other suitable delay window.

During the post-purchase financing option window, the customer may have two options made available to them, and such options may be presented on the display of the client 20 via any suitable notification (e.g., email, push message, text message, etc.). The first option (of operation 336) may be to convert the debit transaction to a loan. Such conversion, if chosen, may follow a presentation of loan terms that can be reviewed and accepted via application screens or web interfaces tailored to such purpose. Thereafter, payments may be made to the facilitator in accordance with the terms of the agreed upon loan. The dynamic interchange fee associated with a loan transaction may then ultimately apply instead of the interchange fee associated with a debit transaction using the coding mechanism described above. The second option (of operation 337) may be to keep the transaction as a pay now (e.g., debit) transaction. If the customer takes no action to change the transaction’s character by the time the postpurchase financing option window closes, the second option (i.e., keeping the transaction as a pay now transaction) may be pursued by default, and the corresponding interchange fee may be charged at that time. However, if the customer confirms keeping the transaction as a pay now transaction, then the corresponding interchange fee may immediately be charged (i.e., without waiting for the 24 hr period to close).

Many modifications and other embodiments of the inventions set forth herein will come to mind to one skilled in the art to which these inventions pertain having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the inventions are not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Moreover, although the foregoing descriptions and the associated drawings describe exemplary embodiments in the context of certain exemplary combinations of elements and/or functions, it should be appreciated that different combinations of elements and/or functions may be provided by alternative embodiments without departing from the scope of the appended claims. In this regard, for example, different combinations of elements and/or functions than those explicitly described above are also contemplated as may be set forth in some of the appended claims. In cases where advantages, benefits or solutions to problems are described herein, it should be appreciated that such advantages, benefits and/or solutions may be applicable to some example embodiments, but not necessarily all example embodiments. Thus, any advantages, benefits or solutions described herein should not be thought of as being critical, required or essential to all embodiments or to that which is claimed herein. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

THAT WHICH IS CLAIMED:

1. An apparatus for facilitating a dynamic interchange in relation to a transaction associated with a payment card, the apparatus comprising processing circuitry configured to: receive pre-purchase information from a customer identifying a future transaction and indicating customer intent with respect to treatment of the future transaction; receive an indication of a current transaction between a customer and a merchant using the payment card; determine whether to assign the customer intent to the current transaction based on the pre-purchase information; and in response to determining to assign the customer intent to the current transaction, provide coded information into an authorization message to indicate the customer intent and enable a payment processor handling transfer of funds to the merchant in association with completing the current transaction to apply a selected changeable interchange fee to the current transaction.

2. The apparatus of claim 1, wherein receiving pre-purchase information comprises receiving a pre-purchase identification of the merchant, a product, an amount, a date and location of the future transaction.

3. The apparatus of claim 2, wherein the customer intent is indicated by customer selection of an option presented on a display of a communication device of the customer, the option selected indicating a type of transaction to be processed for payment via the payment card for the future transaction.

4. The apparatus of claim 3, wherein the type of transaction of the option selected is either: a pay now or debit transaction; or a pay later or loan transaction.

5. The apparatus of claim 1, wherein determining whether to assign the customer intent to the current transaction comprises comparing the future transaction to the current transaction to determine a match between recorded data associated with the future transaction and corresponding data associated with the current transaction.

6. The apparatus of claim 1, wherein the pre-purchase information is received via a first communication network, and wherein the authorization message is communicated via a payment processing network.

7. The apparatus of claim 6, wherein the authorization message has a format defined by protocol for the payment processing network to have a limited number of characters or fields, and wherein the coded information is disposed in a selected portion of the authorization message without modifying the format of the authorization message.

8. The apparatus of claim 7, wherein the coded information includes a dynamic interchange indicator that indicates that either a normal or increased interchange rate is to be charged to the merchant for the current transaction.

9. The apparatus of claim 8, wherein the dynamic interchange indicator identifies a first account or a second account as a source for funds to transfer to the merchant for the current transaction.

10. The apparatus of claim 9, wherein the first account is associated with a pay now or debit transaction, and wherein the second account is associated with a pay later or loan transaction.

11. A method of facilitating a dynamic interchange in relation to a transaction associated with a payment card, the method comprising: receiving pre-purchase information from a customer identifying a future transaction and indicating customer intent with respect to treatment of the future transaction; receiving an indication of a current transaction between a customer and a merchant using the payment card; determining whether to assign the customer intent to the current transaction based on the pre-purchase information; and in response to determining to assign the customer intent to the current transaction, providing coded information into an authorization message to indicate the customer intent and enable a payment processor handling transfer of funds to the merchant in association with completing the current transaction to apply a selected changeable interchange fee to the current transaction.

12. The method of claim 11, wherein receiving pre-purchase information comprises receiving a pre-purchase identification of the merchant, a product, an amount, a date and location of the future transaction.

13. The method of claim 12, wherein the customer intent is indicated by customer selection of an option presented on a display of a communication device of the customer, the option selected indicating a type of transaction to be processed for payment via the payment card for the future transaction.

14. The method of claim 13, wherein the type of transaction of the option selected is either: a pay now or debit transaction; or a pay later or loan transaction.

15. The method of claim 11, wherein determining whether to assign the customer intent to the current transaction comprises comparing the future transaction to the current transaction to determine a match between recorded data associated with the future transaction and corresponding data associated with the current transaction.

16. The method of claim 11, wherein the pre-purchase information is received via a first communication network, and wherein the authorization message is communicated via a payment processing network.

17. The method of claim 16, wherein the authorization message has a format defined by protocol for the payment processing network to have a limited number of characters or fields, and wherein the coded information is disposed in a selected portion of the authorization message without modifying the format of the authorization message.

18. The method of claim 17, wherein the coded information includes a dynamic interchange indicator that indicates that either a normal or increased interchange rate is to be charged to the merchant for the current transaction.

19. The method of claim 18, wherein the dynamic interchange indicator identifies a first account or a second account as a source for funds to transfer to the merchant for the current transaction.

20. The method of claim 19, wherein the first account is associated with a pay now or debit transaction, and wherein the second account is associated with a pay later or loan transaction.