Patent Application
20170140358
Stored value card transactions—such as but not limited to activations, deactivations, redemptions, reloads, and refreshes—typically require a retailer point of sale (POS) terminal, system, or host to communicate with a remote processor or server to obtain authorization for the transaction, and/or to conduct the transaction. However, in certain circumstances, communication with the remote processor may not be possible (for example, during power outages or network outrages), or may not be timely (for example, during peak hours or network overloads).
It is therefore desirable to provide systems and methods to locally authorize and/or conduct stored value card transactions. It is further desirable to provide such systems and methods that may communicate when able with the remote processor to update the processor and any associated data stores with new transaction information. Such systems and methods may enable faster processing of transactions and transaction requests.
Various stored value card systems may present some degree of local authorization that may be utilized in very specific circumstances. However, such systems do not provide the ability to (i) continue to reverse certain transaction types upon timeouts, while also adding a stand-in approval facility for designated transaction types; (ii) offer stand-in capabilities for certain “soft declines” as reported; (iii) implement specific requirements such as providing a unique system trace audit number (STAN) on outbound requests emanating from store-and-forward (SAF) transactions; and/or (iv) obtain visibility to SAF content for operational and management level oversight. Note that generally, a “soft decline” is one in which the stored value card processor may decline the transaction, but the issuing party or processor (that is, the actual authorizer for the product and/or transaction) may not have declined the transaction.
Accordingly, such goals are desirable of a system and method in accordance with some embodiments of the present invention.
In accordance with some embodiments of the present invention, aspects may include an apparatus for locally processing stored value card transactions, the apparatus proximate to a retailer point-of-sale (POS) or host, the apparatus in selective communication with the POS or host and a stored value card processor, the apparatus comprising: a POS or host interface enabling the selective communication with the POS or host; a stored value card processor interface, enabling the selective communication with the stored value card processor; and a processing module, enabling selective decision making for certain stored value card transaction requests.
In accordance with some embodiments of the present invention, other aspects may include a method of locally authorizing stored value card transactions, the method conducted amongst a retailer point-of-sale (POS) or host, a bridge processor, and a stored value card processor, the bridge processor being disposed locally with the POS or host, the method comprising: receiving at the bridge processor a transaction request; determining by the bridge processor if the transaction request should be passed through to the stored value card processor, or decided upon locally; upon a determination that the transaction request should be passed through to the stored value card processor; communicating such request from the bridge to the stored value card processor; upon receiving a certain response from stored value card processor, or front the attempted communication with the stored value card processor, locally overriding by the bridge processor the response of the stored value card processor or deciding upon the transaction request locally; upon a determination that the transaction request should not be passed through to the stored value card processor; locally deciding by the bridge processor the transaction request; and communicating by the bridge a transaction request response back to the POS or host.
Other aspects in accordance with some embodiments of the present invention may include an apparatus for locally processing stored value card transactions, the apparatus proximate to a retailer point-of-sale (POS) or host, the apparatus in selective communication with the POS or host and a stored value card processor, the apparatus configured to, receive a transaction request; determine if the transaction request should be passed through to the stored value card processor, or decided upon locally; upon a determination that the transaction request should be passed through to the stored value card processor; communicate such request to the stored value card processor; upon receiving a certain response from stored value card processor, or from the attempted communication with the stored value card processor, locally overriding the response of the stored value card processor or deciding upon the transaction request locally; upon a determination that the transaction request should not be passed through to the stored value card processor; locally deciding by the bridge processor the transaction request; and communicating by the bridge a transaction request response back to the POS or host.
These and other aspects will become apparent from the following description of the invention taken in conjunction with the following drawings, although variations and modifications may be effected without departing from the scope of the novel concepts of the invention.
The present invention can be more fully understood by reading the following detailed description together with the accompanying drawings, in which like reference indicators are used to designate like elements. The accompanying figures depict certain illustrative embodiments and may aid in understanding the following detailed description. Before any embodiment of the invention is explained in detail, it is to be understood that the invention is not limited in its application to the details of construction and the arrangements of components set forth in the following description or illustrated in the drawings. The embodiments depicted are to be understood as exemplary and in no way limiting of the overall scope of the invention. Also, it is to be understood that the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The detailed description will make reference to the following figures, in which:
Before any embodiment of the invention is explained in detail, it is to be understood that the present invention is not limited in its application to the details of construction and the arrangements of components set forth in the following description or illustrated in the drawings. The present invention is capable of other embodiments and of being practiced or being carried out in various ways. Also, it is to be understood that the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting.
The matters exemplified in this description are provided to assist in a comprehensive understanding of various exemplary embodiments disclosed with reference to the accompanying figures. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the exemplary embodiments described herein can be made without departing from the spirit and scope of the claimed invention. Descriptions of well-known functions and constructions are omitted for clarity and conciseness. Moreover, as used herein, the singular may be interpreted in the plural, and alternately, any term in the plural may be interpreted to be in the singular.
With reference to
Service provider 130 may be the party actually issuing or redeeming the stored value card. Stored value card processor 120 may be an intermediate party that may provide services related to a plurality of stored value cards. Retailer 110 may be a typical retailer or merchant with point of sale locations. For example, retailer 110 may be Walgreens, who may offer for sale a plurality of stored value cards. Stored value card processor 120 may be Interactive Communications International, Inc. or InComm, who may provide activation and other services related to a plurality of stored value cards offered by Walgreens. Service provider 130 may be an entity that handles card transactions for the issuer of the card—such as Stored Value Solutions, who may handle card transactions for Bed Bath & Beyond gift cards.
During most transactions, the host may operate merely as a pass-through in which it may convey transaction requests 141 to the stored value card processor 120, and may receive responses 142 from the stored value card processor 120. However, during some circumstances there may be a timeout 143 in the attempted communication between the host and the stored value card processor 120. In such circumstances, the host 110 may generate a timeout reversal 144, which may be provided to a SAF que 145. At a later time, the SAF system may communicate with the stored value card processor 120 to reverse any transaction that may have been improperly or incompletely conducted. It can be seen from
In accordance with some embodiments of the present invention, a bridge may be provided that may, amongst other things, provide for one or more of: (i) implementing stand-in approval at the host level (rather than, or in addition to, at the point-of-sale level); (ii) enable specifically identified transaction types only (for example, only permitting stand-in activations); (iii) enable specifically identified products, or product-transaction type combinations; (iv) automatically enable the bridge to communicate with the SAF system during “soft declines” and/or timeouts; and (v) provide results of bridge/SAF activity to sales associate or technician, for example printed on a receipt or displayed on a POS display.
Such functionality may provide for faster and more efficient processing, since certain transaction may be decided locally, while others may require responses from a stored value card processor. Moreover, during times of non-communication or errors, such a system and method may prevent transactions from piling on to and overloading an inefficient processor, thereby enabling systems to overall run more efficiently and quickly.
In general, the present invention is directed to a bridge disposed between a POS system/host and a stored value card processor. The bridge may provide one or more functions. For example, if communication with the stored value card processor is effective and timely, the bridge may be a pass-through to communicate with the stored value card processor and may assist with the routing of transaction requests. If communication with the stored value card processor is not possible, effective, or timely, the bridge may act as a stand-in processor and may conduct certain transactions. Once proper communication with the stored value card processor resumes, the bridge may update the stored value card processor and any associated data stores with updated information associated with transactions the bridge authorized or conducted as a stand-in.
In accordance with some embodiments of the present invention, the bridge may be positioned intermediate of the POS/host and the stored value card processor. For example, the bridge may be physically located at the POS/host location, in a position to receive and route pass-through transactions, while also having connectivity for necessary stand-in transactions.
Positioning the bridge at the POS/host location provides additional benefits. Since a purpose of the bridge is to provide continuous services for certain stored value card transactions, positioning the bridge at the location of the POS/host ensures that the bridge will be in the same environment as the POS/host. In other words, if the bridge was located remotely from the POS/host, it is foreseeable that the bridge location may be the subject of a power outage or network issues, while the POS/host location may be running as normal. Since one of the goals of the bridge is to provide continuous support for the POS/host, locating the bridge with the POS/host may ensure environmental factors will be the same or similar, and that limited network communications may be required to process stand-in authorizations or transactions.
Systems and methods in accordance with some embodiments of the present invention may utilize on or more solid state drives. Solid state drives may comprise, for example, HP ProLiant DL380P (8 2U, which may, for example, utilize Intel Xeon E5-2609 processors. Solid state drives may be in communication with the POS/host directly, via one or more load balancers, and/or via a multiplexer.
In general, the bridge may implement store-and-forward (SAF) functionality to conduct both stand-in and pass through transactions at a retailer location. In accordance with some embodiments of the present invention, the bridge may provide the ability to (i) continue to reverse certain transaction types upon timeouts, while also adding a stand-in approval facility for designated transaction types; (ii) offer stand-in capabilities for certain “soft declines” as reported; (iii) implement specific requirements such as providing a unique STAN on outbound requests emanating from store-and-forward (SAF) transactions; and/or (iv) obtain visibility to SAF content for operational and management level oversight.
Note that modifications to a retailer system may be desirable, recommended, or required for the bridge to offer full functionality. For example, a retailer may be required to modify the settings of transaction routing to route stored value card transactions to the bridge—rather than directly to the stored value card processor. Similarly, a retailer may modify its system to support new response codes associated with stand-in approvals and stand-in declines. Such response codes may be useful in tracking and correlating SAF events and bridge decision making. Also, retailers may provide additional point-of-sale guidance to customers in certain circumstances. For example, if a purchased product receives a stand-in approval, the customer may be informed that the product will be active in twenty-four (24) hours. This information may be conducted orally (from the sales clerk to the customer), or may be printed on the receipt.
With reference to
At 251, a transaction flow is indicated for circumstances in which the host times out (that is, communication is unable to be effective or timely with the stored value card processor 230), but the specific product type (i.e., the certain stored value card) is not on a “retry” list. In this circumstance, the transaction may originate at the POS 211, pass through the host 212, but may not make it to the stored value card processor 230. Because the product may not be permitted to be transacted by the bridge 220, a time out reversal (TOR) may be issued at 252, which may be stored in the SAF queue 260 for communication with the stored value card processor 230 at a later time.
At 253, a transaction flow is indicated for circumstances in which the host times out, but the specific product type in on the “retry” list. Here, the transaction may originate at the POS 211, flow through the host 212, but may not make it to the stored value card processor 230. However, because the product type is on the “retry” list, the bridge 220 may perform a stand-in approval of the transaction at 254. This stand-in approval may also be stored in the SAF queue 260 for later communication with the stored value card processor 230.
At 255, a transaction flow is indicated for a soft decline for a product type that is on the “retry” list. Again, the transaction originates at the POS 211 and passes through the host 212. The bridge 220 may provide stand-in approval 256 for the transaction, and may again update the SAF queue 260.
At 257 a transaction flow is indicated for transactions that are authorized to be conducted using local bridge action. Here, the transaction may originate at the POS 211, flow through the host 212, and be authorized, approved, or conducted by the bridge 220. Again, the bridge 220 may provide information regarding any stand-in approval or declines to the SAF queue 260 to provide updates to the stored value card processor 230.
Finally, as indicated above, at 259 the SAF system may update the stored value card processor 230 by providing a listing or queue of transactions conducted or declined by the bridge 220.
In order for a customer 210 to properly utilize such SAF system with a bridge, the customer may be advised to modify its system. Such modifications may include, but are not limited to, providing the abilities to (I) validate current SAF queue content on decision making; (ii) discern “soft” declines from “hard” declines; and/or (iii) modify fields on each SAF request attempt.
More specifically, in order to validate current SAF queue content on decision making, SAF decision making may be guided by the specific, current content of the SAF queue. For example, if an activation request is received (or similarly, a reload request is received)—while an activation request for the same stored value card is already present in the SAF queue, the follow-up or subsequent transaction should be locally denied.
With regard to discerning “soft” declines from “hard” declines, a “soft” decline may be a candidate for potential stand-in transactions conducted by the bridge, while a “hard” decline may not be. Fields on each SAF request attempt may be modified to prevent repeated or duplicate uses of the same system trace audit number (STAN). Using the same STAN may trigger the stored value card processor to automatically repeat the same response as before. Accordingly, modifying the STAN for each transaction request—particularly in the case of soft declines—may be advisable.
It is contemplated that the transaction capabilities of the bridge may be integrated into the host, such that the bridge itself may not be necessary. However, since there are often factors that may prevent or delay such integration, the use of the bridge may provide a convenient manner to obtain local stand-in transaction capabilities, without costly and timely modifications to the host of a customer.
In order to configure the host to communicate with the bridge, several configuration files may be helpful or necessary. For example, the ‘QueryHost’ transaction participant may define and control how the bridge connects to an authorizer, and how the bridge should handle responses or lack of responses. The ‘QueryHost’ participant may be called by both the main transaction manager (which may handle real-time requests) and the SAF transaction manager (which may handle subsequent unloading of items that land in the SAF queue as a result of configuration decisions).
In the example below, and in all exemplary coding or files presented herein, note that the specific arrangement, algorithms, and or presentment of information is exemplary only. Numerous approaches or manners may be utilized to achieve the same, substantially the same, or similar results. Moreover, note that the exemplary coding sets forth InComm as the stored value card processor. It is contemplated that the coding presented may be modified in any number of ways, including replacing references to “incomm” with references to other parties.
The participant ‘QueryHost’ may be defined as follows (note that the value, set forth below are exemplary starting values, and are not intended to be any endorsement of final, production settings:
Table 1 below describes each of the properties specified in the QueryInCommHost.
An endpoint on-boarded to the bridge may require a defined and deployed SAF Manager component. Such SAF Manager may be in charge of (i) unloading the SAF queue; (ii) retrying SAF replication; and (iii) synching the SAF. More specifically, a SAF Manager may identify SAF entries that may still need to be delivered to a designated endpoint. If the item is available to send, the SAF manager may place the top relevant entries in a que (SAF.TXN) for handling by the SAF Transaction Manager.
SAF replication may be performed to a peer node as part of an unloading process. If replication fails (for example, the request to the peer times out), the SAF Manager may place the top relevant entries on this list in a queue (RETRY.TXN) for handling by the Retry Transaction Manager.
If a node notices that its peer is down, the node may begin to operate in ‘SOLO” mode—in which it is responsible for delivering SAF entries to both nodes. Subsequently, when the node recognizes that its peer is back up, it must now synch to the peer all actions it undertook on its behalf. If synchronization occurs, the SAF Manager may place the top relevant entries on this list in a queue (SYNC.TXN) for handling by the Sync Transaction Manager.
For example, to integrate an endpoint to the bridge approach, a SAF Manager definition may be:
Table 2 below describes each of the properties specified in the SAF Manager.
Systems and methods in accordance with some embodiments of the present invention may also comprise an Echo Manager, which may control the sending and receiving of network-level messages (for example, 08xx series messages) between the bridge and an external authorizer (e.g., a stored value card processor). An echo message may serve at least two purposes: (i) it may keep permanently connected channels alive in times of low volume (many remote hosts may force-rupture a connection after a period of inactivity; and/or (ii) it may prove an external authorizer, and upon receipt of a valid response to an echo request, can serve to take the bridge out of a suspend mode. The echo manager participant may be defined as follows:
Table 3 below describes each of the properties specified in the Echo Manager.
If the bridge intercedes in a transaction and takes any action, it may send a Response Code (‘RC’—field 39) back to the customer's application in the response. These ‘RC Slates’ are designed to provide insight as to the bridge's decision making and give guidance to the customer's host as to any next steps that may be taken.
The bridge's approval slate may be in the form of ‘Bx’. A customer's application may treat any response in which RC=‘Bx’ (e.g. B1, B1, etc.) as an approved transaction. Table 4 illustrates some of the B slate approval codes below.
Note that for codes B0, B1, B2, B3, and B6, the customer's application should instruct the POS system to advise the customer (either verbally or printed on a receipt), that the product will be available for use within twenty-four (24) hours.
The bridge's decline slate may be in the form of ‘Dx’. The customer's application may treat any response in which RC=‘Dx’ as a declined transaction. Table 5 illustrates some of the D slate decline codes below.
Note that certain decline text may be provided to a POS display. For example, if decline code D1 is issued, the display may show “Original request accepted.” If D2, D3, D4, D5, D8, D9, or DA are issued, the display may show “Try again momentarily.” If D6 or D7 are issued, the display may show “Amount incorrect for product.”
The bridge may record results and metric information to a transaction log (“tranlog”) tranlog table. The bridge may be configured to run “heavier,” where it writes a tranlog record for every transaction that it sees, whether it invokes SAF or not; or “lighter,” where it writes a tranlog record only for transactions in which it invokes SAF. The choice is conveyed via the ‘log-safed-only’ property in the CreateTranLog participant of the Main Transaction Manager:
During configuration of the bridge and its characteristics, a heavier configuration may elected (wherein value=‘false’) if the customer wants recorded evidence of the impact of bridge on transaction duration and throughout. Conversely, a customer may opt for a lighter configuration (wherein value=‘true’) if the customer wants to minimize the footprint of the bridge, both in transaction touch and corresponding database maintenance. In general and in accordance with some embodiments of the present invention, a ‘tranlog’ table may be defined as follows:
Table 6 below describes each of the properties specified in the tranlog.
In accordance with some embodiments of the present invention, and in order to meet specific requirements of (e.g., altering the STAN on outbound requests emanating from SAF, checking the SAF queue for related entries to direct specific processing), the real-time processing engine of the bridge may writes (and subsequently updates) ‘SAF-able’ items as rows into two interrelated database tables, a safMeta table and a safData table. Each is discussed in turn below.
A safMeta table may contain ‘meta’ data about the SAF entry (e.g., ‘endpoint’) as well as dynamic data related to the entry, i.e., values that the bridge may update after each SAF attempt (e.g., ‘lastSent’. ‘lastStan’). Additionally, any field that the bridge uses as part of a SAF-based database query needs to be located in this ‘Meta’ table.
Similarly, a safData table may contain a secure representation of the SAF request as well as static data related to the entry (e.g., ‘reversal’, ‘inboundStan’)
Writing to a row of these tables may occur in one or more of the following situations: (a) a transaction response is received from an authorizer in which the remote response code (‘RRC’) is listed as one of bridge's retry-response-codes' and the transaction's corresponding transaction code is listed in ‘retry-transaction-codes’; (b) No transaction response was received from an authorizer (i.e., a timeout occurred) and the transaction's corresponding transaction is listed in ‘retry-transaction-codes’; (c) When readying a transaction request, it is observed that all lines to the authorizer were disconnected (a multiplexor disconnect 2 scenario) and the bridge customer configured the system as ‘saf-on-disconnect’ to ‘true’; (d) a request is received from a customer and it is determined that there was a complementary, unsent request for the same card in the SAF table; (e) a transaction response was not received from an authorizer (i.e., a timeout occurred and the transaction's corresponding transaction code is not listed in ‘retry-transaction-codes’ (or is listed but the bridge identified the request as a Swipe Reload); or (f) a terminal-based timeout reversal or customer void/cancellation was received from the point of sale. Note that (a)-(e) may be referred to as ‘host-based timeout reversals.’ and may accordingly be referred to as TORs.
In situations (a)-(d) above, the original transaction may be the item written to the table, while the reversal column in the row may be set to ‘false.’ In situation (e), the reversal of the original transaction may be the item written to the table, and the reversal column in the row may be set to ‘true.’ In situation (f), the reversal of the original transaction may be received directly from the POS and the item may be written to the table, while the reversal column in the row may be set to ‘true.’ In each of the situations, the status of the item when written to the table for the first time by a real-time processing engine may be set to ‘RETRY.’
Subsequently and asynchronously, the bridge's SAF Manager may read this table to determine which row may contain candidates still viable for delivery. A viable candidate may be one in which the item (i) has not expired; (ii) has not reached the maximum number of retry attempts; (iii) was not previously delivered successfully; and/or (iv) did not cause a processing exception during a previous send attempt. Accordingly, the items that remain in a ‘RETRY’ status may be viable candidates for delivery.
In accordance with some embodiments of the present invention, a ‘safMeta’ table may be defined as:
Table 7 below describes each of the properties specified in the safMeta table.
As discussed above, an safData table may also be defined.
Table 7 below describes each of the properties specified in the safMeta table.
With reference to
More specifically, at 350 an approval transaction flow may be seen, where the transaction was approved by the stored value card processor or the ultimate service provider. This transaction flow may originate at the POS 311, flow through the host 312 and the bridge 320 to the stored value card processor 330. The stored value card processor 330 may provide a response code (RC) of 00. The bridge 320 may then convey this RC to the POS 311 via the host 312.
At 360 a hard decline transaction is illustrated. Again, this transaction flow may originate at the POS 311, flow through the host 312 and the bridge 320 to the stored value card processor 330. The stored value card processor 330 may provide a response code (RC) of 14. The bridge 320 may then convey this RC to the POS 311 via the host 312.
At 370 a sot decline, with the processing code not on the ‘retry list’ transaction is illustrated. Again, this transaction flow may originate at the POS 311, flow through the host 312 and the bridge 320 to the stored value card processor 330. The stored value card processor 330 may provide a response code (RC) of 96. The bridge 320 may then convey this RC to the POS 311 via the host 312.
With reference to
With continued reference to
The transaction may then be routed to the SAF queue 470 in the bridge 420. At 453 the transaction may be attempted again, though a RC code of 96 is illustrated at 454, noting an additional soft decline. The transaction may be noted as a ‘RETRY’ at 455. At 456 the transaction may be attempted again, and may again receive an RC code of 96 at 457. Again, the transaction may be noted as a ‘RETRY’ at 458. At 459 the transaction may be attempted again, and may be successfully conducted. An RC code of 00 may be returned at 460, after which the transaction may be flagged as ‘TAKEN’ and removed from the SAF queue.
With reference to
With continued reference to
the transaction may then be routed to the SAF queue 570 in the bridge 520. At the transaction may be attempted again, though a RC code of 96 is illustrated at 555, noting an additional soft decline. The transaction may be noted as a ‘RETRY’ at 556. At 557 the transaction may be attempted again, and may again receive an RC code of 96 at 558. Again, the transaction may be noted as a ‘RETRY’ at 559. At 560 the transaction may be attempted again, and may receive a hard decline RC code of 14, illustrated at reference numeral 561. At 562 the item may be flagged as ‘TAKEN’ and removed from the SAF queue 570. Due to the hard decline from the stored value card processor 530, the item should be included in the exception file.
With reference to
With continued reference to
The transaction may then be routed to the SAF queue 670 in the bridge 620. At 654 the transaction may be attempted again, though a RC code of 96 is illustrated at 655, noting an additional soft decline. The transaction may be noted as a ‘RETRY’ at 656. At 657 the transaction may be attempted again, and may again receive an RC code of 96 at 658. Again, the transaction may be noted as a ‘RETRY’ at 659. At 660 the transaction may reach the maximum number of attempts allowable, and may be flagged ‘MAX’ at 661. At this point the SAF manager may remove the item from the queue. Note that due to the maximum number of attempts being reached without final approval or decline from the stored value card processor 630, the item should be included in the exception file.
With reference to
With continued reference to
However, at 754 a host timeout may receive a different outcome. Here, a timeout 755 may occur, and the status may again be set to ‘RETRY.’ but the reversal set to ‘FALSE’ at 756. At 757 an RC of B1 may be sent to the POS to inform the purchaser that “this product will be available for use in twenty-four (24) hours.” At 758 the SAF queue 770 may try to conduct the transaction again, and may again time out at 759. At 760 the item may again be flagged as ‘RETRY.” At 761 the bridge may again try to conduct the transaction, and this time may receive a soft decline from the stored value card processor with an RC code of 96 at 762. Again, the item may be flagged as ‘RETRY’ at 763. Finally, at 764 the transaction may be conducted and an RC code of 00 may be returned, indicating that the transaction was successful. At 766 the item may be flagged as ‘TAKEN’ to remove it from the SAF queue 770.
With reference to
With continued reference to
The transaction may then be routed to the SAF queue 870 in the bridge 820. At 854 the transaction may be attempted again, though again it may timeout at 855. The item may be flagged ‘RETRY’ at 856. At 857 the transaction may be attempted again, and may receive an RC code of 96 at 858. Again, the transaction may be noted as a ‘RETRY’ at 859. At 860 the transaction may again timeout at 861. The transaction may again be flagged as a ‘RETRY’ at 862. However, the time for entry may be recognized to exceed the ‘expire-after’ amount, and at 863 the item may be set to status of ‘EXP.” At this point the SAF manager may remove the item from the queue. Note that due to the maximum amount of time being reached without final approval or decline from the stored value card processor 830, the item should be included in the exception file.
With reference to
While in suspend mode, the bridge may decide on transactions locally without querying any external authorizer. If specified on the ‘retry-transaction-code.’ the bridge may place items into the SAF queue and change the response code before returning the transaction to the POS. The response code may be changed to ‘B3’ (stand-in approval on bridge suspension) or ‘D3’ (decline on bridge suspension). Note that the bridge will not attempt to unload SAF entries until the suspend mode is changed. If the stored value card processor responds to an “echo” request, the bridge will exit suspend mode, resume querying the stored value card processor for transaction requests, and unload the SAF queue via the SAF manager.
With continued reference to
During suspend mode, the bridge 920 may receive transaction requests 954 from the POS 911. The bridge 920 may locally authorize the transactions, setting the status to ‘RETRY’ at 956, and returning a response code of ‘B3’ at 957. Moreover, the bride 920 will continue to send echo requests 958 to the stored value card processor 930, though the echo may timeout at 959.
If the processing code is not on the ‘retry’ list, a transaction 960 may be declined by the bridge and RC code of ‘D3’ (decline on bridge suspension) may be issued. At some point, an echo 962 may be returned by the stored value card processor. The bridge 920 will remove itself from suspend mode, and subsequent transactions—such as 963 will be passed through to the stored value card processor 930, and may receive successful messages with RC of ‘00’ at 964, which the bridge 920 may pass on the to the POS 911 at 965. Subsequently, the SAF queue 970 may be unloaded at 966, receiving RC codes of ‘00’ at 967 and flagging the item as ‘TAKEN’ at 968, thereby removing the item from the SAF queue.
With reference to
With continued reference to
Note that there may be scenarios win which the current content of a SAF table may influence the transaction processing behavior of the bridge. For example, if the bridge had previously placed a card activation in the SAF queue—but has yet to successfully deliver the item—but now receives a deactivation request for the same card, it may be appropriate to place the new item (deactivation) directly into the SAF queue in proper chronological order. The following table illustrates how the bridge may make specific judgments based on pending item content in the SAF tables, where “A” is activation, “AR” is activation reversal, “D” is deactivation, and “DR” is deactivation reversal.
In some cases the top SAF entries depicted above may imply previous items for a card have also been SAF-ed. For example, in case 3 above, the only way a deactivation ends up in the SAF queue is if the activation that preceded it was also placed in the SAF. So a full sequence for case 3 should be, at least, ‘A-D-A.’ In practice, this progression often arises when a card buyer—confronted with a receipt that says “card will be active within twenty-four (24) hours”—demands that the card be retried because they desire immediate use of the product. This may put a sales clerk at a POS in the position of needing to deactivate and reactivate a product. However, until the SAF items have been unloaded, the result presented to the purchaser may remain the same.
With reference to
With continued reference to
With reference to
With continued reference to
If the bridge then receives a second transaction for the same card at 1255, the bridge may not pass this transaction to the stored value card processor 1230, but may flag the item as ‘RETRY’ at 1256 and issue an RC code of ‘B2’ at 1257. The bridge 1220 may then receive a third transaction request for the same card at 1258. The bridge 1220 may again prevent this request from being sent to the stored value card processor 1230, and may instead return RC code ‘B5’ at 1259. Subsequently, at 1260 the SAF queue may send the first item at to the stored value card processor 1230, and may receive a RC code of ‘00’ at 1261, and may flag the first transaction item as ‘TAKEN’ at 1262. At 1263 the SAF queue may send the second transaction item to the stored value card processor 1230, which may again accept the transaction and return RC code of ‘00’ at 1264. At 1265 the second item may also be flagged as ‘TAKEN.’ Both items may be removed from the SAF queue.
With reference to
With continued reference to
With reference to
With continued reference to
All bridge actions may be recorded into a log file, referred to informally as the ‘Q2’ log. Troubleshooting and event analysis may typically start by examining these files. Such files may also assist a reader in understanding how the bridge works. The logs may be governed by a log rotator service—where each log is kept at a manageable size (for example, no greater than 100 MB).
Entries in the logs may show a list of all application components deploying (during start up) and undeploying (during shutdown). The logs may be examined as part of a regular practice to validate a ‘clean’ start-up. This may be pertinent when in the process of adding new features and functions to the application.
For a ‘normal’ transaction, logging may result in four (4) entries: (i) inbound request (from the customer's host); (ii) outbound request (to the external authorizer); (iii) inbound response (from the external authorizer); and/or (iv) outbound response (back to the customer's host). In accordance with some embodiments, in order to save space and reduce processing overhead, only certain pertinent ISO8583 request and response fields (e.g., PC/3, STAN/11. RRN/37. RC/39) may be displayed in the logs
If a transaction is SAF-ed or if any subsequent action takes place in which SAF content is updated, such information may be relayed to the peer node so that the SAF content of both nodes remain in synch. In a ‘normal’ replication attempt, this logging may result in two entries: outbound request (to the peer node) and inbound response (from the peer node). The entry may represent the original replication request. i.e., when the item is first committed to SAF on the node that processed the request.
In addition, attempts to SAF to the external authorizer may also be logged. This may result in two entries: outbound request (to the external authorizer); and inbound response (from the external authorizer). In accordance with some embodiments, the original STAN may be replaced with a unique STAN. In addition, channel-level SAF-ed requests may be discerned (vs. real-time requests) via the ‘01’ denotation in POS Condition Code.
Each time a node completes its attempt to unload a SAF request, the corresponding peer node may be informed. Various replication request fields in exemplary coding may include items such as: (i) 39—Response Code (Field 39) as returned by the authorizer in the SAF response (gets recorded in peer's safMeta.lastRRC column); (ii) 105—Auth ID (Field 38) as returned by authorizer (gets recorded in peer's safMeta, lastAuthid colum); (iii) 121—Tranlog ID of the request (used by the peer—in conjunction with the node value in Field 123 (see below)—to locate the record in safMeta; on any node Pair, node+tranId are a unique identifier within safMeta); (iv) 122—Status of the request (gets recorded in peer's safMeta.status column); (v) 123—Node of the request (see 121 above for lookup role); (vi) 125—Updated attempt count related to the request (gets recorded in peer's safMeta.attempts column); (vii) 126—Time of the attempt (gets recorded in peer's safMeta.lastSent column); and/or (viii) 127—Last STAN of the attempt (gets recorded in peer's safMeta.lastStan column).
A main transaction manager (‘TM’) summary may also be maintained. For example, a summary of a real-time transaction information may be recorded. Such transaction information may include, but is not limited to: (i) outbound request (to the external authorizer); (ii) outbound response (back to the customer's host); (iii) profiler (time spent in each transaction participant); (iv) Remote Response Code (‘RRC’) received from the external authorizer; (v) events relating to SAF checking; and/or (vi) if SAF processing is invoked, the replication request posted to the peer.
A summary SAF attempts may be recorded and packaged, including: outbound request (to the external authorizer); inbound response (from the external authorizer); profiler (time spent in each transaction participant); replication request/response (to/from peer node); and replication status.
On the peer node, a record of all SAF activity generated on the originating node may also be logged. This may be accomplished by means of a ‘replication request.’ The Replication TM may handle replication requests emanating from possible creation points on the originating node, including but not limited to: (i) Main TM—may generate ‘original’ requests (to the peer) during real-time transaction processing for items that end up in SAF; (ii) SAF TM—may generate ‘update’ requests to the peer during subsequent SAF unloading: (iii) Sync TM—may generate ‘original’ or update’ peer requests when the originating node is synching the peer node (after an outage on—or lack of communication from—the peer); and/or (iv) Retry TM—may generate ‘original’ peer requests if the first request from the Main TM failed, or may generate ‘update’ peer requests if the SAF TM or Synch TIM ‘update’ peer request failed.
A request may be an ‘original’ (i.e., the full SAF entry) or an ‘update’ (i.e., a change in status or other information concerning an entry that the originating node knows the peer node has already recorded). The replication logic may discern an ‘original’ from an ‘update’ via ISO Field 3. If present, the request may be processed as an ‘original’; if absent, the request may be processed as an ‘update.’
For High Availability purposes, a State Controller may be used to help the two nodes stay in synch and understand what each other's respective role needs to be at any given point in operation. We record changes in state in the state controller logs.
Moreover, filtering may be applied through logs. The presence of the ‘##’ tag or marker may allow a reader to apply a filter to the log in order to summarize events related to SAF decision-making, SAF events and HA State Control.
A bridge customer may elect to import an ‘item file,’ which may serve to modify stand-in approval rules. The file may be constructed in comma-separated value (‘CSV’) format as follows (one record per item):
A bridge customer may initiate Item File import processing by FTP-ing a full file. For example, a file may be provided into: Bridge/spool/item_file/request (a.k.a., the ‘request’ sub-directory). The naming convention of the file is left to the initiator, but generally must have the suffix ‘.esv’ or .txt’. Any file not having one of these suffixes may be ignored. Periodically—for example, every 60 seconds—the Bridge application may check for the presence of a new import file using a directory polling (‘DirPoll’) facility. When a properly named file is found, the bridge may move it from the ‘request’ sub-directory to the ‘run’ sub-directory for processing. During import processing, the bridge may use the Item File input to construct a database table equivalent for subsequent use by the bridge transaction processing engine.
Upon successful completion of the import, the bridge may produce a report summarizing its actions. These reports may be placed into the ‘response’ sub=directory. On receipt of any malformed input file or upon any event causing processing to run to less than normal completion, the bridge may move a copy of the input file to the ‘bad’ sub-directory. Otherwise, the bridge may move files run to proper completion to the ‘archive’ sub-directory.
The online transaction processing (‘OLTP’) engine of the bridge may use the resulting item file content in the following manner. First, the bridge may determine if a transaction is SAF-able for stand-in approval because one of the following conditions is true: (i) the node is currently in ‘Suspend Mode’; (ii) there are one or more undelivered, complementary items in SAF for the same card; (iii) the request timed-out and the PC is on the retry list; or (iv) the request received a soft decline (as per the ‘retry-re’ list) and the PC is on the ‘retry-pc’ list
Then, if one of the conditions specified in (a) is true, the bridge may check to see if the UPC of the transaction (ISO 8583 Field 54) is on the item table and—if so—whether or not it is designated as a SAF-able item. Based on item file the bridge may override a previous decision to SAF as follows:
The bridge may create an Exception file content to send to the stored value card processor. These files may be scheduled to be created and delivered multiple times per day. The bridge may place an item on the Exception File if one of the following conditions is gtrue of an item on the SAF file: (i) the item expired (safMeta.status—‘EXP’); (ii) the item reached its maximum number of attempts (safMeta.status—‘MAZ’); or (iii) the item was hard-declined by the authorizer (safMeta.status—‘TAKEN’ and lastRRC< >‘00’). The exception file may constructed in pipe-limited format, and in accordance with some embodiments, a header and trailer are required. An empty file is signified by a header and trailer with no detail records. However, note that it is contemplated that empty files may still be sent to the stored value card processor.
Note that if the bridge creates an exception file, the file name may include a timestamp from the system at inception of the file creation, and may also reflect the ID of the exception job run in which the file was created.
The bridge may deliver the files using a secure FTP facility, which may be periodically operated. The bridge may make a recording on the saf.Meta table (in the extractId column) as to whether a SAF entry was included on an exception file, and if so, which one. The table below illustrates exemplary table entries and meanings.
It will be understood that the specific embodiments of the present invention shown and described herein are exemplary only. Numerous variations, changes, substitutions and equivalents will now occur to those skilled in the art without departing from the spirit and scope of the invention. Accordingly, it is intended that all subject matter described herein and shown in the accompanying drawings be regarded as illustrative only, and not in a limiting sense.
