储值卡交易，诸如但不限于启用、停用、赎回、重载和刷新，通常需要零售商销售点(pos)终端、系统或主机与远程处理器或服务器进行通信以获得交易授权，和/或进行交易。但是，在某些情况下，可能无法与远程处理器进行通信(例如，在停电或断网时)，或可能不及时(例如，在高峰时段或网络过载期间)。
因此期望提供用于在本地授权和/或进行储值卡交易的系统和方法。进一步期望提供这类系统和方法，当能够与远程处理器进行通信时，该系统和方法利用新交易信息来更新处理器和任何相关数据存储器。这类系统和方法可以实现交易和交易请求的更快处理。
各种储值卡系统可以呈现可以在非常特定的情况下使用的某种程度的本地授权。然而，这类系统不能提供以下能力：(i)在超时后继续撤销某些交易类型，同时为指定的交易类型添加代位批准工具；(ii)为报告中的某些“软拒绝”提供代位能力；(iii)实施具体要求，诸如针对源自存储转发(saf)交易的出站请求提供唯一的系统跟踪审计号(stan)；和/或(iv)获取saf内容的可见性以用于操作和管理级别的监督。应注意，一般而言，“软拒绝”是储值卡处理器可能拒绝交易的一种，但发行方或处理商(即产品和/或交易的实际授权人)可能并未拒绝交易。
因此，这类目标是期望根据本发明的一些实施例的系统和方法。
技术实现要素：
根据本发明的一些实施例，各方面可以包括一种用于本地处理储值卡交易的装置，该装置邻近零售商销售点(pos)或主机，该装置与pos或主机以及储值卡处理器进行选择性通信，该装置包括：pos或主机接口，其实现与pos或主机的选择性通信；储值卡处理器接口，其实现与储值卡处理器的选择性通信；以及处理模块，其实现对某些储值卡交易请求做出的选择性决定。
根据本发明的一些实施例，其它方面可以包括一种本地授权储值卡交易的方法，该方法在零售商销售点(pos)或主机、网桥处理器和储值卡处理器之间进行，网桥处理器与pos或主机本地设置，该方法包括：在网桥处理器处接收交易请求；由网桥处理器确定交易请求是应被传送到储值卡处理器还是在本地对其做出决定；在确定交易请求应被传送到储值卡处理器之后：将该请求从网桥传递到储值卡处理器；在接收到来自储值卡处理器的某个响应或者来自与储值卡处理器的尝试通信之后，由网桥处理器本地覆写储值卡处理器的响应或本地决定交易请求；在确定交易请求不应该被传送到储值卡处理器之后：由网桥处理器本地决定交易请求；以及由网桥将交易请求响应传递回到pos或主机。
根据本发明的一些实施例的其它方面可以包括一种用于本地处理储值卡交易的装置，该装置邻近零售商销售点(pos)或主机，该装置与pos或主机以及储值卡处理器进行选择性通信，该装置被配置成：接收交易请求；确定交易请求是应被传送到储值卡处理器还是本地决定；在确定交易请求应该被传送到储值卡处理器之后：将该请求传递到储值卡处理器；在接收到来自储值卡处理器的某个响应或者来自储值卡处理器的尝试通信之后，本地覆写储值卡处理器的响应或本地决定交易请求；在确定交易请求不应被传送到储值卡处理器之后：由网桥处理器本地决定交易请求；以及由网桥将交易请求响应传递回到pos或主机。
从以下结合附图对本发明的描述中，这些和其它方面将变得显而易见，但在不脱离本发明的新颖概念的范围的情况下可以实现变化和修改。
附图说明
通过与附图一起阅读以下具体实施方式，可以更全面地理解本发明，其中相同参考指示符用于指定相同元件。附图描绘了某些说明性实施例并且可以帮助理解以下具体实施方式。在详细解释本发明的任何实施例之前，应该理解的是，本发明在其应用中不限于以下描述中阐述的或附图中示出的组件的构造和布置的细节。所描述的实施例应被理解为是示例性的并且绝不限制本发明的总体范围。而且，应该理解的是，本文使用的措辞和术语是为了描述的目的，而不应该被认为是限制性的。具体实施方式将参考以下附图，其中：
图1示出了根据本发明的一些实施例的具有有限处理功能的示例性存储转发(saf)模型。
图2示出了根据本发明的一些实施例的具有全处理功能的示例性saf模型。
图3示出了根据本发明一些实施例的通过操作的示例性流程图。
图4示出了根据本发明的一些实施例的用于处理具有代位批准并且没有saf影响的软拒绝的示例性过程。
图5示出了根据本发明的一些实施例的用于处理具有代位批准和saf硬拒绝的软拒绝的示例性过程。
图6示出了根据本发明的一些实施例的当交易处理达到最大重试次数时用于处理具有代位批准的软拒绝的示例性过程。
图7描绘了根据本发明的一些实施例的具有代位批准的主机超时的示例性过程。
图8示出了根据本发明的一些实施例的用于具有代位批准的主机超时的示例性处理器。
图9描绘了根据本发明的一些实施例的用于暂停模式的示例性过程。
图10示出了根据本发明一些实施例的基于发起者的失效和撤销的示例性过程。
图11示出了根据本发明的一些实施例的未决saf交易的示例性过程。
图12示出了根据本发明的一些实施例的用于saf中的补充项目的示例性过程。
图13示出了根据本发明的一些实施例的用于处理具有不在预期范围内的通用产品代码(upc)的产品的示例性过程。
图14示出了根据本发明的一些实施例的用于处理具有对于saf系统不活动的通用产品代码的产品的示例性过程。
具体实施方式
在详细解释本发明的任何实施例之前，应该理解的是，本发明的应用不限于以下描述中阐述的或附图中示出的组件的构造和布置的细节。本发明能够具有其它实施例并且能够以各种方式实践或执行。而且，应该理解的是，本文使用的措辞和术语是为了描述的目的，而不应该被认为是限制性的。
提供本说明书中例示的内容以帮助全面理解参考附图所公开的各种示例性实施例。因此，本领域的普通技术人员将认识到，在不脱离要求保护的本发明的精神和范围的情况下，可以对本文描述的示例性实施例进行各种改变和修改。为了清楚和简明，省略了对众所周知的功能和构造的描述。此外，如本文所使用，单数可以以复数解释，并且可选地，呈复数的任何术语可以被解释为单数。
参考图1，在当前的方法下，如果金融交易在零售商的主机处超时-例如，在等待来自储值卡处理器的响应的过程中-可以产生超时撤销(tor)并且将其提供到saf系统。否则，主机直接与储值卡处理器通信以进行其它交易。继续参考图1和过程10，零售商110可以直接与储值卡处理器120进行通信，继而可以与服务提供商130进行通信。
服务提供商130可以是实际发行或赎回储值卡的一方。储值卡处理器120可以是可以提供与多个储值卡相关的服务的中间方。零售商110可以是具有销售点位置的典型零售商或商家。例如，零售商110可以是walgreens，其可以提供多张储值卡以供出售。储值卡处理器120可以是interactivecommunicationsinternational，inc.或incomm，其可以提供与由walgreens提供的多个储值卡有关的启用和其它服务。服务提供商130可以是处理卡发行方的卡交易的实体-诸如可以处理bedbath&beyond礼品卡的卡交易的storedvaluesolutions。
在大多数交易期间，主机可以仅仅作为传送站(pass-through)进行操作，其中可以将交易请求141传送到储值卡处理器120，并且可以从储值卡处理器120接收响应142。然而，在一些情况下，在主机110与储值卡处理器120之间的尝试通信中可能存在超时143。在这类情况下，主机110可以生成超时撤销144，其可以被提供给saf队列145。在稍后时间，saf系统可以与储值卡处理器120进行通信以撤销可能已经不正确或不完整进行的任何交易。从图1可以看出，这类saf系统的能力非常有限。
根据本发明的一些实施例，可以提供尤其可以提供以下中的一个或多个的网桥：(i)在主机级别(而不是在或者除了在销售点级别之外)实现代位批准；(ii)仅实现明确识别的交易类型(例如，仅允许代位启用)；(iii)实现明确识别的产品或产品交易类型组合；(iv)在“软拒绝”和/或超时期间自动使网桥与saf系统进行通信；以及(v)向销售人员或技术人员提供网桥/saf活动的结果，例如打印在收据上或显示在pos显示器上。
这类功能可以提供更快和更有效的处理，因为某些交易可以在本地对其做出决定，而其它交易可能需要来自储值卡处理器的响应。此外，在未通信或错误期间，这种系统和方法可以防止交易堆积到低效处理器并且使其过载，从而使得系统能够整体上更高效且更快速地运行。
一般而言，本发明涉及设置在pos系统/主机与储值卡处理器之间的网桥。网桥可以提供一个或多个功能。例如，如果与储值卡处理器的通信是有效且及时的，则网桥可以是与存储卡处理器进行通信的传送站，并且可以协助交易请求的路由。如果与储值卡处理器的通信不可行、不有效或不及时，则网桥可以用作代位处理器并且可以进行某些交易。一旦恢复与储值卡处理器的适当通信，网桥可利用与代位网桥所授权或进行的作为代位的交易相关联的更新信息来更新储值卡处理器和任何相关的数据存储器。
根据本发明的一些实施例，网桥可以位于pos/主机和储值卡处理器的中间。例如，网桥可以物理地位于pos/主机位置处，在接收和路由传送式交易的位置，同时还具有用于必要的代位交易的连接。
将网桥定位在pos/主机位置提供了额外的益处。由于网桥的目的是为某些储值卡交易提供持续的服务，所以将网桥定位在pos/主机的位置处确保网桥与pos/主机处于相同的环境中。换句话说，如果网桥位于远离pos/主机的位置，则可以预见网桥位置可能遭受了停电或网络问题，而pos/主机位置可能正常运行。由于网桥的一个目标是为pos/主机提供持续的支持，因此网桥与pos/主机定位在一起可确保环境因素相同或相似，并且可能需要有限的网络通信来处理代位授权或交易。
根据本发明一些实施例的系统和方法可以利用一个或多个固态驱动器。固态驱动器可以包括例如hpproliantdl380pg82u，其可以例如利用intelxeone5-2609处理器。固态驱动器可以经由一个或多个负载平衡器和/或经由多路复用器而直接与pos/主机进行通信。
一般而言，网桥可以实施存储转发(saf)功能以在零售商位置处进行代位式(stand-in)和传送式(pass-through)交易。根据本发明的一些实施例，网桥可以提供以下能力：(i)在超时后继续撤销某些交易类型，同时为指定的交易类型添加代位批准工具；(ii)为报告中的某些“软拒绝”提供代位能力；(iii)实施具体要求，诸如针对源自存储转发(saf)交易的出站请求提供唯一stan；和/或(iv)获取saf内容的可见性以用于操作和管理级别的监督。
应注意，对零售商系统的修改可能是期望的、受推荐的或者网桥所需要的以提供全部功能。例如，可能需要零售商修改交易路由的设置，以将储值卡交易路由到网桥-而不是直接路由到储值卡处理器。类似地，零售商可以修改其系统以支持与代位批准和代位拒绝相关联的新响应代码。这类响应代码可能有助于跟踪和关联saf事件以及做出网桥决定。此外，在某些情况下，零售商可能会为客户提供额外的销售点指导。例如，如果购买的产品收到了代位批准，则可能会通知客户该产品将在二十四(24)小时内处于启用。该信息可以(从售货员到客户)口头传达，或者可以打印在收据上。
参考图2，描绘了根据本发明的一些实施例的利用网桥的改进的saf模型20。一般而言，模型20示出了在客户210中进行的各种交易，客户210可以包括pos211和/或主机212。(应注意，此处“客户”的使用旨在指代作为储值卡处理器的客户的商家或零售商。例如，提供一个或多个储值卡或礼品卡以供销售的零售商可以是“客户”)。预期可以用直接与网桥220进行通信的pos211来进行类似的交易，但通过主机212的通信可能是常见的。客户210可以向网桥220发送通信，继而可以进行一些交易或者可以将交易请求传送到储值卡处理器230。储值卡处理器230可以与服务提供商240进行通信以实现或进行某些交易。
图2阐述了几个示例性交易类型以说明通过客户210、网桥220、储值卡处理器230和服务提供商240的流程。在250处，示出了传送式交易，其中交易在pos发起并经过主机212，经过桥220，并在储值卡处理器230处被接收。储值卡处理器可以与服务提供商240进行通信，但也可以设想，储值卡处理器230也可以是服务提供商，或者可以被授权进行交易而无需额外的通信。交易响应然后经过网桥220和主机212被路由回到pos211。
在251处，针对主机超时(即，通信对储值卡处理器230不有效或不及时)的情况指示交易流程，但是特定产品类型(即，某个储值卡)不在“重试”列表中。在这种情况下，交易可以在pos211发起，经过主机212，但是不能交给储值卡处理器230。因为产品可能不被允许由网桥220进行交易，所以在252处可以发出超时撤销(tor)，其可以存储在saf队列260中以便在稍后时间与储值卡处理器230进行通信。
在253处，针对主机超时的情况指示交易流程，但是特定产品类型在“重试”列表上。这里，交易可以在pos211发起，流经主机212，但是可以不交给储值卡处理器230。然而，因为产品类型在“重试”列表上，所以在254处网桥220可以执行交易的代位批准。该代位批准也可以存储在saf队列260中以用于在稍后时间与储值卡处理器230进行通信。
在255处，针对“重试”列表上的产品类型的软拒绝，指示交易流程。再一次，交易在pos211处发起并经过主机212。网桥220可为交易提供代位批准256，并且可再次更新saf队列260。
在257处，针对被授权使用本地桥接动作进行的交易，指示交易流程。这里，交易可以在pos211处发起，流经主机212，并且由网桥220授权、批准或者进行。再一次，网桥220可以将关于任何代位批准或拒绝的信息提供给saf队列260以向储值卡处理器230提供更新。
最后，如上所述，在259处，saf系统可以通过提供由网桥220进行或拒绝的交易的列表或队列来更新储值卡处理器230。
为了使客户210正确地利用这种具有网桥的saf系统，可以建议客户修改其系统。这种修改可以包括但不限于提供以下能力：(i)在做出决定时验证当前的saf队列内容；(ii)从“硬”拒绝中辨别出“软”拒绝；和/或(iii)修改每个saf请求尝试的字段。
更具体地说，为了在做出决定时验证当前的saf队列内容，saf决定可以由saf队列的特定当前内容来指导。例如，如果接收到启用请求(或者类似地，接收到重加载请求)-同时同一储值卡的启用请求已经存在于saf队列中，则应当在本地拒绝后续或随后的交易。
关于从“硬”拒绝中辨别“软”拒绝，“软”拒绝可能是由网桥进行的潜在代位交易的候选项，而“硬”拒绝可能不是。可以修改每个saf请求尝试的字段，以防止重复或重复使用相同的系统跟踪审计号(stan)。使用相同的stan可能会触发储值卡处理器自动重复与之前相同的响应。因此，修改每个交易请求的stan-特别是在软拒绝的情况下-可能是可取的。
主机集成
可以设想，网桥的交易能力可以被集成到主机中，使得网桥本身可能不是必需的。然而，由于常常有可能阻止或延迟这种集成的因素，因此网桥的使用可以提供便利的方式来获得本地代位交易能力，而不需要对客户的主机进行昂贵且费时的修改。
配置
为了配置主机与网桥进行通信，若干配置文件可能是有用的或必需的。例如，‘queryhost’交易参与者可以定义和控制网桥如何连接授权人，以及网桥如何处理响应或缺少响应。‘queryhost’参与者可以由主交易管理器(其可以处理实时请求)和saf交易管理器(其可以处理由于配置决定而落在saf队列中的项目的随后卸载)两者来调用。
在下面的示例中以及在本文呈现的所有示例性编码或文件中，应注意，信息的具体布置、算法和或呈现仅仅是示例性的。可以利用许多方法或方式来实现相同的、基本相同的或类似的结果。此外，应注意，示例性编码将incomm阐述为储值卡处理器。可以设想，可以以任何方式修改所呈现的编码，包括用对其它方的引用来替换对“incomm”的引用。
参与者的‘queryhost’可以如下定义(应注意，下面给出的值是示例性的起始值，并且不旨在是对最终产品设置的任何认可：
下面的表1描述了在queryincommhost中指定的每个属性。
saf管理器定义
网桥板载的端点可能需要定义和部署的saf管理器组件。这样的saf管理器可以负责(i)卸载saf队列；(ii)重试saf重复；以及(iii)同步saf。更具体地说，saf管理器可以标识可能仍然需要被传送到指定端点的saf条目。如果该项目可用于发送，则saf管理器可以将最前面的相关条目置于队列(saf.txn)中以供saf交易管理器处理。
作为卸载过程的一部分，可以将saf重复执行到对等节点。如果重复失败(例如，对对等方的请求超时)，则saf管理器可以将该列表中的最前面的相关条目置于队列(retry.txn)中以供重试交易管理器处理。
如果节点注意到其对等方已关闭，则该节点可以开始以“solo”模式进行操作-其中它负责将saf条目传送给两个节点。随后，当节点识别出其对等方恢复开启时，它现在必须向其对等方同步它所完成的所有动作。如果同步发生，则saf管理器可以将列表中的最前面的相关条目置于队列(sync.txn)中以供同步交易管理器处理。
例如，为了将端点集成到桥接方法，saf管理器定义可以是：
下面的表2描述了saf管理器中指定的每个属性。
回应管理器
根据本发明的一些实施例的系统和方法还可以包括回应管理器，其可以控制网桥与外部授权人(例如，储值卡处理器)之间的网络级消息(例如，08xx系列消息)的发送和接收。回应消息可以起到至少两个目的：(i)它可以在低量时保持永久连接的频道活跃(许多远程主机可能在一段时间不活动后强制断开连接；和/或(ii)它可以证实外部授权人，并且在接收到对回应请求的有效响应之后，可以使该网桥脱离暂停模式。回应管理器参与者可以被定义如下：
下面的表3描述了在回应管理器中指定的每个属性。
网桥生成的响应代码
如果网桥参与到交易中并采取任何行动，则它可以在响应中发送响应代码(‘rc’-字段39)回到客户的应用程序。这些‘rc记录’旨在为网桥做出决定提供见解，并为客户主机可能采取下一步的步骤提供指导。
网桥的批准记录可以是‘bx’的形式。客户的应用程序可以将rc＝′bx′(例如b1、b1等)的任何响应作为批准的交易进行处理。表4说明了下面的一些b记录批准代码。
应注意，对于代码b0、b1、b2、b3和b6，客户的应用程序应指示pos系统通知客户(口头或印在收据上)该产品将在二十四(24)小时内可用。
网桥拒绝记录可以是‘dx’的形式。客户的应用程序可以将其中rc＝′dx′的任何响应作为拒绝交易进行处理。表5说明了下面的一些d记录拒绝代码。
应注意，某些拒绝文本可以被提供给pos显示器。例如，如果发布拒绝代码d1，则显示器可能会显示“原始请求已接受”。如果发出d2、d3、d4、d5、d8、d9或da，则显示器可能会显示“立即重试”。如果发出d6或d7，在显示器可能会显示“产品数量不正确”。
数据库表定义
网桥可以将结果和度量信息记录到交易日志(“translog”)交易记录表。网桥可以配置成运行“较重”，其中为每个看到的交易写入交易日志记录，不管是否调用saf；或“较轻”，其中仅为调用saf的交易写入交易日志记录。该选择经由主交易管理器的创建交易日志参与者中的“仅限日志”(log-safed-only)属性传送：
在配置网桥及其特性期间，如果客户希望记录网桥对交易持续时间和整个的影响的证据，则可以选择较重的配置(其中值＝‘假’)。相反，如果客户希望在交易接触和对应的数据库维护中尽可能减少网桥的占地面积，则客户可以选择较轻的配置(其中值＝‘真’)。一般而言并且根据本发明的一些实施例，可以如下定义‘交易日志’表：
下面的表6描述了在交易日志中指定的每个属性。
根据本发明的一些实施例，并且为了满足(例如，在源自saf的出站请求上更改stan，检查saf队列中的相关条目以指导特定处理)的特定要求，网桥的实时处理引擎可以将‘saf可执行’作为行写入(并随后更新)到两个相互关联的数据库表中，safmeta表和safdata表。下面依次讨论每一个。
safmeta表可以包含关于saf条目(例如，‘端点’)的‘元’数据以及与该条目有关的动态数据，即网桥可以在每次saf尝试之后更新的值(例如，‘上一次发送’、‘上一个stan’)。此外，网桥用作基于saf的数据库查询一部分的任何字段都需要位于该‘元数据’表中。
类似地，safdata表可以包含saf请求的安全表示以及与条目相关的静态数据(例如，‘撤销’、‘入站stan’)
写入这些表的行可以在以下一种或多种情况下发生：(a)接收到来自授权人的交易响应，其中远程响应代码(‘rrc’)被列为网桥的重试响应代码’中的一个，并且交易的对应交易代码列在‘重试交易代码’中；(b)没有接收到来自授权人的交易响应(即发生超时)，交易的对应交易列在‘重试交易代码’中；(c)在准备交易请求时，观察到授权人的所有线路都已断开连接(多路复用器断开连接的情况)并且网桥客户将系统配置成‘saf断开连接’为‘真’；(d)接收到来自客户的请求，并确定在saf表中存在对同一张卡的补充未发送的请求；(e)没有接收到来自授权人的交易响应(即发生超时，并且交易的对应交易代码未在‘重试交易代码’中列出(或列出，但网桥将该请求标识为刷卡重新加载)；或(f)从销售点接收到基于终端的超时撤销或客户失效/取消。应注意，(a)-(e)可能被称为‘基于主机的超时撤销’，并可能相应地简称为tor。
在上述情况(a)-(d)中，原始交易可以是写入表的项目，而该行中的撤销列可以被设置为‘假’。在情况(e)中，原始交易的撤销可能是写入表的项目，并且该行中的撤销列可能被设置为‘真’。在情况(f)中，可以直接从pos接收原始交易的撤销，并且可以将该项目写入表，而该行中的撤销列可以被设置为‘真’。在每种情况下，由实时处理引擎第一次写入表时的项目状态可以设置为‘重试’。
随后并且异步地，网桥的saf管理器可以读取该表以确定哪个行可以包含仍然可用于传送的候选项。可行的候选项可能是其中的项目(i)尚未过期；(ii)尚未达到重试尝试的最大次数；(iii)以前未成功传送；和/或(iv)在先前的发送尝试期间未引起处理异常。因此，保持处于‘重试’状态的项目可能是可供传送的可行候选项。
根据本发明的一些实施例，‘safmeta’表可以被定义为：
下面的表7描述了safmeta表中指定的每个属性。
如上所述，还可以定义safdata表。
下面的表7描述了safmeta表中指定的每个属性。
参考图3，示出了网桥30的示例性和非限制性角色和操作。图3描述了各种交易流程，并阐述了网桥与其它交易行为者的动作。交易可以在客户310处发起，客户310可以包括pos311和/或主机312。pos311可以发起可以通过主机312流到网桥320的交易。交易可以继续流过网桥320并且被传送到储值卡处理器330。储值卡处理器330然后可以处理交易(例如，通过与服务提供商340的通信)，并且可以将交易响应返回通过网桥320，返回通过主机312并到达pos311。在每个流程中，网桥320可以不为交易增加值，而不是忠实地将请求与相关响应相关联。
更具体地说，在350处，可以看到批准交易流程，其中交易由储值卡处理器或最终服务提供商批准。该交易流可以在pos311处发起，通过主机312和网桥320流到储值卡处理器330。储值卡处理器330可以提供00的响应码(rc)。然后，网桥320可以经由主机312将该rc传送到pos311。
在360处，示出了硬拒绝交易。再者，该交易流程可以在pos311处发起，通过主机312和网桥320流到储值卡处理器330。储值卡处理器330可以提供14的响应码(rc)。网桥320然后可以经由主机312将该rc传送到pos311。
在370处，示出了软拒绝，其中处理代码不在‘重试列表’交易上。再者，该交易流程可以在pos311发起，通过主机312和网桥320流到储值卡处理器330。储值卡处理器330可以提供96的响应码(rc)。网桥320然后可以经由主机312将该rc传送到pos311。
参考图4，示出了具有代位批准(saf＝00)的软拒绝的示例性交易流程40。一般来说，储值卡处理器可能会“软拒绝”交易，并且交易在‘重试交易代码’列表中进行配置。因此，网桥可以将项目置于其saf队列中，并将rc更改为客户，以反映消息‘b0’-拒绝的代位批准。随后，并且与交易异步地，网桥可以将项目的saf编辑请求发送到储值卡处理器。第一次尝试可能会被拒绝-rc为96。然而，因为saf交易管理器可能遵循与主(实时)交易管理器相同的配置规则，因此每个“软拒绝”响应可能会导致另一次尝试-至少达到配置的最大尝试次数或最大的分配时间。当交易成功时(即，由授权人或储值卡处理器批准)，该项目可能被标记为“采取”，并且可能会被考虑用于将来的saf卸载动作。
继续参考图4，图形示出了上面的示例。交易可以在客户410处发起，客户pos411可以通过其主机412发送交易请求450并且发送到网桥420。如之前所述，网桥420可以尝试将交易发送到储值卡处理器430。如果网桥420接收在附图标记451处示出的软拒绝-rc为96，则网桥420可以将项目的状态设置为‘重试’，在459处将rc设置为b0，并且提示pos411向购买者通知称“本产品将在二十四(24)小时内可用”。
交易然后可以被路由到网桥420中的saf队列470。在453处，可以再次尝试交易，但在454处示出了rc代码96，并注释了附加的软拒绝。在455处，交易可以被注释为‘重试’。在456处，可以再次尝试交易，并且可以在457处再次接收到rc代码96。再者，在458处，交易可以被注释为‘重试’。在459处，可以再次尝试交易，并可能成功进行。可以在460处返回rc代码00，之后该交易可以被标记为‘采取’并且从saf队列中移除。
参考图5，示出了具有代位批准和saf＝硬拒绝的软拒绝的示例性情景50。一般来说，储值卡处理器或最终服务提供商可能会软拒绝交易，并且交易可再次在‘重试交易代码’列表中进行配置。因此，网桥可以提供拒绝的代位批准，并且可以将该项目置于saf队列中，并且向b0的pos报告rc代码。随后并且可能异步地，网桥可以将项目的saf编辑请求发送到储值卡处理器。两次尝试授权该项目可能会接收到额外的软拒绝。第三次尝试可能会接收到来自储值卡处理器的硬拒绝。该项目然后从saf队列中移除，并且应该被包括在异常文件中。
继续参考图5，图形示出了上面的示例。交易可以在客户510处发起。客户pos511可以通过其主机512发送交易请求550并且发送到网桥520。如之前所述，网桥520可以尝试将交易发送到储值卡处理器530。如果网桥520接收在附图标记551处示出的软拒绝--rc为96，则网桥520可以将项目的状态设置为‘重试’，在559处将rc设置为b0，并且提示pos411向购买者通知称“本产品将在二十四(24)小时内可用”。
交易然后可以被路由到网桥520中的saf队列570。在554处，可以再次尝试交易，但在555处示出了rc代码96，注释了附加的软拒绝。在556处，交易可以被注释为‘重试’。在557处，可以再次尝试交易，并且可以在558处再次接收到rc代码96。再者，在559处，交易可以被注释为‘重试’。在560处，可以再次尝试交易，并且可以接收硬拒绝rc代码14，如附图标记561所示。在562处，项目可以被标记为‘采取’并且从saf队列570中移除。由于来自储值卡处理器530的硬拒绝，项目应该被包括在异常文件中。
参考图6，示出了saf满足最大重试次数的具有网桥代位批准的软拒绝的示例性情景60。一般而言，交易可以由储值卡处理器或最终服务提供商“软拒绝”，但交易可以在‘重试交易代码’列表中进行配置。然后网桥可以将项目置于saf队列中，并且可以提供代位批准，从而将rc改变为‘b0’。随后并且可能异步地，网桥可以将项目的saf编辑请求发送到储值卡处理器。在这个示例中，网桥可能不会成功获得批准或硬拒绝，而是可能达到最大尝试次数。最终，saf管理器可能会认识到已经满足了‘最大传输’阈值。在任何成功的尝试之前，saf管理器可能会将该项目标记为‘最大’，并将其从针对未来saf卸载动作的考虑中移除。该项目也可能包括在异常文件中。
继续参考图6，图形示出了上面的示例。交易可以在客户610处发起。客户pos611可以通过其主机612发送交易请求650并且发送到网桥620。如之前所述，网桥620可以尝试将交易发送到储值卡处理器630。如果网桥620接收在附图标记651处示出的软拒绝--rc为96，则网桥620可以在652处将项目的状态设置为“重试”，在653处将该rc设置为b0，并且提示pos611向购买者通知称“本产品将在二十四(24)小时内可用”。
交易然后可以被路由到网桥620中的saf队列670。在654处，可以再次尝试交易，但在655处示出了rc代码96，注释了附加的软拒绝。在656处，交易可以被注释为‘重试’。在657处，可以再次尝试交易，并且可以在658处再次接收到rc代码96。再者，在659处，交易可以被注释为‘重试’。在660处，交易可以达到允许的最大尝试次数，并且可以在661处被标记为‘最大’。此时，saf管理器可以从队列中移除项目。应注意，由于达到最大尝试次数而没有来自储值卡处理器630最终批准或拒绝，所以该项目应该被包括在异常文件中。
参考图7，示出了具有代位批准的主机超时的示例性场景70。一般而言，示出了两次超时情况以说明网桥采取动作的时间。在第一种情况下，处理代码不在‘重试’列表上；在第二种情况下，处理代码处于‘重试’列表中。第一种情况，可能会收到拒绝，其中rc代码为‘d2’(拒绝查询远程主机超时)。可以创建撤销请求并将其发送到saf以发送到储值卡处理器。在第二种情况下，网桥可能超时请求，但可以在rc代码为‘b1’的情况下记录代位批准。可以将saf编辑的请求发送到储值卡处理器，直到它被储值卡处理器接受和批准为止-此时该项目可能被标记为‘采取’并且从将来saf卸载动作的考虑中移除。
继续参考图7，图形示出了上面的示例。交易可以从客户710处发起。客户pos711可以通过其主机712发送交易请求750并且发送到网桥720。如之前所述，网桥720可以尝试将交易发送到储值卡处理器730。如果网桥720在751处超时，则可以将状态设置为‘重试’，并且在752处将撤销设置为‘真’。然后网桥可以在753处传送rc‘d2’，从而通知pos711“立即重试”。
然而，在754处，主机超时可以接收不同的结果。这里，可能发生超时755，并且可以再次将状态设置为‘重试’，但是在756处将撤销设置为‘假’。在757处，rcb1可以被发送到pos以通知购买者称“本产品将可在二十四(24)小时内可用”。在758处，saf队列770可以尝试再次进行交易，并且可能在759处再次超时。在760处，项目可能再次被标记为‘重试’。在761处，网桥可以再次尝试进行交易，并且这次可以在762处从存储卡处理器接收到具有rc代码96的软拒绝。再者，项目可以在763处被标记为‘重试’。最后，在764处，可以进行交易，并且rc的代码00可以返回，从而致使交易成功。在766处，该项目可以被标记为‘采取’以将其从saf队列770中移除。
参考图8，示出了具有由网桥代位批准的主机超时的示例性情景，其中达到了最大尝试次数。一般来说，交易请求可以从pos发送到网桥，并且请求可能会超时。然后网桥可以将项目置于其saf队列中，提供代位批准，并向pos报告的rc代码‘b1’。然后网桥可以将项目的saf编辑请求发送到储值卡处理器。第一次尝试可能会超时；第二次尝试可能会收到软拒绝。所有后续尝试可能会超时或收到软拒绝。最终，saf管理器可能会认识到，saf条目的创建(‘safmeta.created’)之间的时间段现在超过了‘过期之后’中指定的时间量。管理器可能会将该项目标记为‘过期’并将其从用于进一步saf卸载动作的考虑中移除。该项目应该被包括在异常文件中。
继续参考图8，图形示出了上面的示例。交易可以从客户810处开始。客户pos811可以通过其主机812发送交易请求850并且发送到网桥820。如之前所述，网桥820可以尝试将交易发送到储值卡处理器830。如果网桥820在如附图标记851所示处超时，在网桥820可以将项目的状态设置为‘重试’，在852处将撤销＝‘假’，在853处将rc设置为b1，并且提示pos811向购买者通知称“本产品将在二十四(24)小时内可用”。
交易然后可以被路由到桥820中的saf队列870。在854处，可以再次尝试交易，但其可能在855处超时。在856处，项目可以被标记为‘重试’。在857处，可以再次尝试交易，并且可以在858处接收rc代码96。再者，在859处，交易可以被注释为‘重试’。在860处，交易可以再次在861处超时。在862处，交易可以再次被标记为‘重试’。然而，条目的时间可以被认为超过‘到期之后’的量，并且在863处项目可以被设置为‘过期’的状态。此时，saf管理器可以移除该项目。应注意，由于达到最大时间量而没有来自储值卡处理器830的最终批准或拒绝，所以该项目应该被包括在异常文件中。
参考图8，示出了暂停模式80的示例性场景。一般来说，图8示出了当处理代码处于以及不处于‘重试’列表中时的暂停模式。当处理代码不在‘重试’列表中时，网桥可能会超时请求，并将该项目置于saf队列中，提供代位批准，并将报告给客户的rc更改为‘b1’。网桥可能会超时多次、超过回应管理器中指定的‘最大超时’值，这可能会使网桥进入‘暂停’模式。
处于暂停模式时，网桥可以在本地对交易做出决定而无需查询任何外部授权人。如果在‘重试交易代码’中指定，则网桥可以将项目置于saf队列中并在将交易返回到pos之前更改响应代码。响应代码可以被更改为‘b3’(网桥暂停的代位批准)或‘d3’(网桥暂停的拒绝)。应注意，在暂停模式更改之前，网桥不会尝试卸载saf条目。如果储值卡处理器响应“回应”请求，则网桥将退出暂停模式，针对交易请求恢复查询储值卡处理器，并经由saf管理器卸载saf队列。
继续参考图9，图形示出了上面的示例。交易可以在客户910处发起。客户pos911可以通过其主机912发送交易请求950并且发送到网桥920。如之前所述，网桥920可以尝试将交易发送到储值卡处理器930。如果网桥920在如附图标记951所示处超时，则网桥920可以在859处将项目的状态设置为‘重试’，在859处使撤销＝‘假’，在953处将rc设置为b1，并且提示pos911向购买者通知称“本产品将在二十四(24)小时内可用”。交易将重试，直到在955处达到最大超时数，并且网桥进入暂停模式。
在暂停模式期间，网桥920可以从pos911接收交易请求954。网桥920可以在本地授权交易，在956处将状态设置为‘重试’，并且在957处返回响应代码‘b3’。此外，网桥920将继续发送回应请求958到储值卡处理器930，但回应可能在959处超时。
如果处理代码不在‘重试’列表上，则交易960可以被网桥拒绝，并且可以发布rc代码‘d3’(桥接暂停的拒绝)。在某个时刻，储值卡处理器可以返回回应962。网桥920将自己从暂停模式中移除，并且随后的交易-诸如963将被传送到储值卡处理器930，并且可以在964处接收具有rc‘00’的成功消息，网桥920可以在965处将其传送到pos911。随后，在966处可以卸载saf队列970，在967处接收rc代码为‘00’并且在968处将该项目标记为‘采取’，由此从saf队列中移除该项目。
参考图10，示出了涉及基于发起者的失效和撤销的情景1000。一般来说，网桥可能会收到来自客户主机的撤销类(mti0400)消息。该交易请求可以基于(i)pos处的取消/失效；(ii)pos处的系统超时；或者(iii)主机的系统超时。网桥可以在本地接受这类请求，并且将这些项目置于saf队列中并用rcb4进行响应(强制批准/接受撤销)。随后并且可能异步地，网桥可以将saf编辑的请求发送到储值卡处理器。如果该重试成功，则该项目可能被标记为“采取”，并且从未来saf卸载动作的考虑中移除。
继续参考图10，图形示出了上面的示例。交易可以在客户1010处发起。客户pos1011可以通过其主机1012发送交易请求1050并且发送到网桥1020。与之前不同，网桥1020可以不尝试将交易发送到储值卡处理器1030，但是可以在1051处将项目标记为‘重试’，并在1052处返回rc‘b4’。在1053处，pos1011可以接收该响应。然后该项目将被提供给saf队列1060，并且将在1054处被提供给储值卡处理器1030。如果由储值卡处理器1030接受，则可以在1055处将rc设置为‘00’，并且可以在1056处将该项目标记为‘采取’，从而将其从saf队列中移除。
应注意，可能存在saf表的当前内容可能影响网桥的交易处理行为的情景。例如，如果网桥先前在saf队列中放置了卡启用-但尚未成功传送项目-但现在接收到对同一张卡的停用请求，则可能适合以适当的时间顺序将新项目(停用)直接放置在saf队列中。下表说明了网桥如何基于saf表中的未决项目内容做出特定判断，其中“a”为启用，“ar”为启用撤销，“d”为停用，“dr”为停用撤销。
在一些案例中，上面描述的最前面的saf条目可能暗示卡的先前条目也已经被saf编辑。例如，在上面的案例3中，在saf队列中结束停用的唯一方式是如果之前的启用也放置在saf中。因此，案例3的完整序列应至少为‘a-d-a’。在实践中，这通常在当卡买家在面对一张称“卡片将在二十四(24)小时内启用”的收据时产生，卡买家会要求重试卡，因为他们希望立即使用该产品。这可能会让pos销售员处于需要停用和重新启用产品的处境。然而，直到已经卸载saf项目，提交给购买者的结果都可能保持不变。
参考图11，现在将讨论示例性未决saf情况1100。一般来说，当交易被储值卡处理器软拒绝时，可能会发生这种情况，并且交易在‘重试交易代码’列表中进行配置。网桥可以将项目置于saf队列中并将rc代码更改为b0(拒绝代位批准)。网桥可通知pos向购买者通知称“本产品将在二十四(24)小时内可用”。然而，网桥可能接收同一产品的第二次交易。网桥可以检查saf队列并确定saf队列中存在未决项目。因此网桥可能会将拒绝记录为‘d1’，并将其报告回来。随后并且异步地，网桥可以将项目的saf编辑请求发送到储值卡处理器。
继续参考图11，图形示出了上面的示例。交易可以在客户1110处发起。客户pos1111可以通过其主机1112发送交易请求1150并且发送到网桥1120。如之前所述，网桥1120可以尝试将交易发送到储值卡处理器1130。如果网桥1120在1151处接收到软拒绝，则它可以在1152处将项目标记为‘重试’，并且在1153处将rc代码作为b0返回到pos。在1154处，网桥可以发送该项目saf队列1170以供稍后处理。如果网桥在1155处接收到同一张卡的第二次交易，则网桥可以不将该交易传送到储值卡处理器1130，但可以在1156处发出rc代码‘d1’或拒绝。这可以是在1157处提供给pos1111，并且可以被通知“接受原始请求”。随后，在1158处，saf队列1170可以将交易请求1158发送到储值卡处理器1130，并且在1159处接收指示交易被接受的rc代码‘00’。在1160处，该项目可以被标记为‘采取’并且从saf队列1170中移除。
参考图12，现在将讨论saf中的补充项目的一些示例性情景1200。一般来说，交易可以被发送到储值卡处理器，可以被软拒绝，并且交易可以在‘重试交易代码’列表上进行配置。网桥可以将项目置于saf队列中，并将报告给客户的rc更改为‘b0’(拒绝代位批准)。然后网桥可以接收针对同一张卡的第二交易请求，这次是停用。网桥可以检查saf队列并识别有未决启用。网桥可以将项目置于saf队列中并且将rc代码‘b2’(在saf中未决补充项目的代位批准)报告回给客户。网桥可能会接收到另一个停用。再者，网桥可以检查saf队列并确定队列中有未决的停用。因此，网桥可以报告rc代码‘b5’(重复批准)。随后并且异步地，网桥可以将两个项目的saf编辑请求(启用和第一停用)发送到储值卡处理器。
继续参考图12，图形示出了上面的示例。交易可以在客户1210处发起。客户pos1211可以通过其主机1212发送交易请求1250并且发送到网桥1220。如之前所述，网桥1220可以尝试将交易发送到储值卡处理器1230。如果网桥1220在1251处接收到软拒绝，则它可以在1252处将项目标记为‘重试’，并且在1253处将rc代码作为b0返回到pos。在1254处，网桥可以发送该项目saf队列1270以供稍后处理。
如果网桥在1255处接收到同一张卡的第二交易，则网桥可以不将该交易传送到储值卡处理器1230，但可以在1256处将项目标记为‘重试’并且在1257处发出rc代码‘b2’。在1258处，网桥1220然后可以接收同一张卡的第三交易请求。网桥1220可以再次防止该请求被发送到储值卡处理器1230，并且可以在1259处替代地返回rc代码‘b5’。随后，在1260处，saf队列可以在1260处将第一项目发送到储值卡处理器1230，并且可以在1261处接收rc代码‘00’，并且可以将第一交易项目标记为‘采取’。在1263处，saf队列可将第二交易项目发送到储值卡处理器1230，其可再次接受该交易并在1264处返回rc代码‘00’。在1265处，第二项目也可被标记为‘采取’。这两个项目都可以从saf队列中移除。
参考图13，示出了在可接受的最小-最大范围之外的upc的示例性情况1300。一般而言，可能会尝试重新加载一个产品，其金额可能低于允许的最小值，也可能超过允许的最大值。交易将被发送到储值卡处理器，储值卡处理器可能会发出软拒绝。然后网桥可以检查项目文件上upc的配置的最小/最大范围，并确定金额是否小于或大于该限额。如果金额小于限额，则网桥可能会返回rc代码‘d6’(upc小于定义的最小金额的拒绝)，而如果金额大于最大值，则网桥可能会返回代码‘d7’(upc超过定义的最大金额的拒绝)。
继续参考图13，图形示出了上面的示例。交易可以在客户1310处发起。客户pos1311可以通过其主机1312发送交易请求1350并且发送到网桥1320。网桥1320可以尝试将交易发送到储值卡处理器1330。如果网桥1320在1351处接收到软拒绝，则它可以在1352处检查upc最大/最小表1354，并在1353处返回rc代码‘d6’或‘d7’。
参考图14，示出了针对saf不活动的upc的示例性场景1400。一般来说，交易可能会由储值卡处理器软拒绝，并且该交易可以在‘重试交易代码’列表上进行配置。网桥可以检查upc上的项目文件的配置的最小/最大范围以确定请求的值是否在范围内。网桥还可以检查upc的项目文件上的活动标志并确定它被设置为‘n’。因此，网桥可能会返回rc‘d8’(该项目针对saf不活动；未采取软拒绝的代位批准)。
继续参考图14，图形示出了上面的示例。交易可以在客户1410处发起。客户pos1411可以通过其主机1412发送交易请求1450并且发送到网桥1420。网桥1420可以尝试将交易发送到储值卡处理器1430。如果网桥1420在1451处接收到软拒绝，则它可以检查upc最大/最小表1452，并返回rc代码‘d8’。
日志记录
所有网桥动作可以被记录到日志文件中，非正式地称为‘q2’日志。故障排除和事件分析通常可以通过检查这些文件开始。这些文件也可以帮助读者了解网桥的工作原理。日志可以由日志轮转服务来管理-每个日志都保持可管理的大小(例如，不超过100mb)。
日志中的条目可以显示部署(在启动期间)和非部署(在关机期间)的所有应用程序组件的列表。可作为常规实践的一部分来检查日志，以验证‘干净’的启动。这在向应用程序添加新特性和功能的过程中可能是恰当的。
对于‘正常’交易，日志记录可能导致四个(4)条目：(i)入站请求(来自客户的主机)；(ii)出站请求(向外部授权人)；(iii)入站响应(来自外部授权人)；和/或(iv)出站响应(回传给客户的主机)。根据一些实施例，为了节省空间和减少处理开销，可以在日志中仅显示某些相关的iso8583请求和响应字段(例如，pc/3、stan/11、rrn/37、rc/39)
如果交易是saf编辑的或者如果发生其中saf内容被更新的任何后续动作，则可以将这样的信息中继到对等节点，使得两个节点的saf内容保持同步。在‘正常’重复尝试中，此日志记录可能会导致两个条目：出站请求(到对等节点)和入站响应(从对等节点)。该条目可以表示原始重复请求，即，当项目首次被提交给处理该请求的节点上的saf时。
另外，也可以记录对外部授权人的saf尝试。这可能会导致两个条目：出站请求(到外部授权人)；以及入站响应(来自外部授权人)。根据一些实施例，原始stan可以被替换为唯一的stan。另外，可以经由pos条件代码中的‘01’表示识别通道级saf请求(相对于实时请求)。
每当节点完成其尝试卸载saf请求时，可以通知对应的对等节点。示例性编码中的各种重复请求字段可以包括诸如以下项目：(i)39-授权人在saf响应中返回的响应代码(字段39)(记录在对等方的safmeta.lastrrc列中)；(ii)105-授权人返回的验证id(字段38)(记录在对等方的safmeta.lastauthid列表中)；(iii)121-请求的tranlogid(由对等方使用-与字段123(参见下文)中的节点值一起)-在safmeta中定位记录；在任何节点对上，node+tranld是safmeta内的唯一标识符)；(iv)122-请求的状态(记录在对等方的safmeta.status列中)；(v)123-请求的节点(参见121上面的查找角色)；(vi)125-与请求相关的更新的尝试计数(记录在对等方的safmeta.attempts列中)；(vii)126-尝试的时间(记录在对等方的safmeta.lastsent列中)；和/或(viii)127-尝试的上一个stan(记录在对等方的safmeta.laststan列中)。
主交易管理器(‘tm’)摘要也可以被维护。例如，可以记录实时交易信息的摘要。这种交易信息可以包括但不限于：(i)出站请求(到外部授权人)；(ii)出站响应(回传给客户的主机)；(iii)探查器(每位交易参与者花费的时间)；(iv)从外部授权人接收到的远程响应代码(‘rrc’)；(v)与saf检查有关的事件；以及/或(vi)如果saf处理被调用，则将重复请求发布到对等方。
可以记录和打包摘要saf尝试，包括：出站请求(到外部授权人)；入站响应(来自外部授权人)；探查器(每个交易参与者花费的时间)；重复请求/响应(到/来自对等节点)；以及重复状态。
在对等节点上，也可以记录在发起节点上生成的所有saf活动的记录。这可以通过‘重复请求’来完成。重复tm可以处理源自发起节点上的可能创建点的重复请求，包括但不限于：(i)主tm-可以在针对在saf中结束的项目实时交易处理期间产生‘原始’请求(到对等方)；(ii)saftm-可以在随后的saf卸载期间向对等方生成‘更新’请求；(iii)同步tm-当发起节点同步对等节点时(在对等方发生中断-或缺少通信之后)，可以生成‘原始’或‘更新’对等方请求；和/或(iv)重试tm-如果来自主tm的第一请求失败，则可能产生‘原始’对等请求，或者如果saftm或同步tm‘更新’对等请求失败，则可能产生‘更新’对等请求。
请求可以是‘原始’(即，完整的saf条目)或‘更新’(即，关于发起节点知道对等节点已经记录的条目的状态或其它信息的改变)。重复逻辑可以经由iso字段3从‘更新’中辨别‘原始’。如果存在，则该请求可以作为‘原始’处理；如果不存在，则该请求可以作为‘更新’进行处理。
为了高可用性目的，可以使用状态控制器来帮助两个节点保持同步，并理解在操作中的任何给定点处彼此相应的角色需要是什么。我们在状态控制器日志中记录状态的变化。
而且，可以通过日志应用过滤。‘##’标签或标记的出现可以允许读者对日志应用过滤器以总结与saf决策、saf事件和ha状态控制相关的事件。
支持功能
网桥客户可以选择导入‘项目文件’，该项目文件可用于修改代位批准规则。该文件可能以逗号分隔值(‘csv’)格式构建，如下所示(每个项目一个记录)：
网桥客户可以通过ftp完整文件来启动项目文件导入处理。例如，文件可以被提供到：bridge/spool/item_file/request(也称为，‘请求’子目录)。文件的命名约定留给发起者，但通常必须具有后缀‘.csv’或‘.txt’。任何没有这些后缀的文件都可能被忽略。定期-例如，每60秒-网桥应用程序可以使用目录轮询(‘dirpoll’)工具检查是否存在新的导入文件。当找到正确命名的文件时，网桥可能会将其从‘请求’子目录移动到‘运行’子目录进行处理。在导入处理期间，网桥可以使用项目文件输入来构建等效于网桥交易处理引擎随后使用的数据库表。
在成功完成导入之后，网桥可以产生汇总其动作的报告。这些报告可以置于‘响应’子目录中。在接收到任何格式错误的输入文件或导致处理运行到低于正常完成的任何事件时，网桥可能会将输入文件的副本移动到‘错误’子目录。否则，网桥可能会将运行的文件移动到‘归档’子目录。
网桥的在线交易处理(‘oltp’)引擎可以以下面的方式使用所得项目文件内容。首先，由于以下条件中的一个为真，网桥可以确定交易是否为saf可执行的代位批准：(i)节点当前处于‘暂停模式’；(ii)针对同一张卡在saf中有一个或多个未传送的补充项目；(iii)请求超时并且pc处于重试列表上；或(iv)请求接收到软拒绝(按照‘重试rc’列表)，并且pc处于‘重试pc’列表上
然后，如果(a)中指定的条件中的一个为真，则网桥可以检查以查看交易的upc(iso8583字段54)是否在项目表上，并且-如果是的话-则它是否被指定为saf可执行的项目。基于项目文件，网桥可以覆写先前对saf的决定，如下所示：
异常文件处理
网桥可以创建异常文件内容以发送给储值卡处理器。这些文件可能预定为每天创建并传送多次。如果以下条件中的一个对于saf文件上的项目为真，则网桥可以将项目置于异常文件上：(i)项目已过期(safmeta.status-′exp′)；(ii)项目达到其最大尝试次数(safmeta.status-′maz′)；或者(iii)授权人硬拒绝该项目(safmeta.status-′taken′andlastrrc<>′00′)。异常文件可以以管道受限格式构建，并且根据一些实施例，需要标头(header)和尾标(trailer)。空文件由没有详细记录的标头和尾标表示。然而，应注意，可以想到空文件仍然可以被发送到储值卡处理器。
详细记录
尾标记录
应注意，如果网桥创建异常文件，则文件名称可以在文件创建开始时包括来自系统的时间戳，并且还可以反映创建文件的异常作业运行的id。
网桥可以使用可以周期性操作的安全ftp工具来传送文件。网桥可以在saf.meta表(在提取id列中)上记录saf条目是否包括在异常文件中，如果是，则是哪一个。下表说明了示例性表条目和含义。
应该理解，本文示出和描述的本发明的具体实施例仅仅是示例性的。在不脱离本发明的精神和范围的情况下，本领域技术人员将会想到许多变化、改变、替换和等效物。因此，本文所描述的和附图中示出的所有主题都被认为仅仅是说明性的，而不是限制性的。