CN101490704A - 用于在网络上进行金融交易的系统和方法 - Google Patents

Abstract

本发明的各种实施例为电子商业部门提供了一种更加安全的金融交易系统，所述系统(1)更安全地处理支付交易，(2)帮助保护商家和银行免受欺骗交易、洗钱和未成年赌博，和(3)帮助限制在被看作构成特殊风险的电子商业领域中的其它滥用，诸如因特网赌博、旅游和消费者购买电子商品。为了完成上述目标，所述金融交易系统的各种实施例(1)为商家、因特网支付服务提供商、收单银行和卡组织建立操作和交易处理协议，和(2)提供用于监视和安全地处理支付和金融交易的自动系统。

Description

用于在网络上进行金融交易的系统和方法

背景技术

总体上，当顾客希望与商家(在因特网上或相反)之间使用支付卡(信用卡或借记卡)时，顾客把电子授权请求发送到收单银行。收单银行经由卡发行商网络(例如Visa，MasterCard，AmericanEexpress或者私有卡发行商网络)把电子授权请求传递到发行银行(即把支付卡发行给顾客的银行或者金融机构)。发行银行验证顾客是否具有足够的信用可用，不拖欠支付，以及已经提供的所有信息(例如卡号、卡验证值号和卡持有者明细)是正确的。然后发行银行经由卡发行商网络把授权支付的电子消息发送到收单银行，并且收单银行把电子消息发送到商家。商家接受此授权消息，作为未来由发行银行支付的证据。资金的实际转账在较晚的阶段发生，被称作结算过程。

在因特网上或者其它网络上发生的支付卡交易涉及在面对面支付交易中不一定存在的风险，因为当交易发生时，卡持有者和商家通常不在一起。此外，某些电子商业部门，诸如赌博和成人娱乐，引起了另外的公共利益关注，即进一步强调用于使支付卡交易安全和阻止欺骗和其它滥用的系统的需要。

发明内容

本发明的各种实施例提供了一种用于电子商业部门的更加安全的金融交易系统，其(1)更加安全地处理支付交易，(2)有助于使商家和银行免受欺骗交易、洗钱和未成年人赌博，以及(3)有助于在被看作构成特殊风险的电子商业区域限制其它滥用，诸如因特网赌博、旅游和消费者购买电子商品。为了达到上述目标，金融交易系统的各种实施例(1)为商家、因特网支付服务提供商、收单银行和卡组织建立了操作和交易处理协议，以及(2)提供用于监视并且安全地处理支付和金融交易的自动化系统。这里描述的两个或更多个各种实施例可以被结合以提供满足这些目标中的一个或多个目标的系统和方法。

根据本发明的各种实施例，提供了一种用于处理与在线商家之间的金融交易的系统。该系统包括支付服务提供商模块，其被配置为：(1)接收把资金从顾客账户转账到在线商家的请求；(2)响应于接收到的转账资金的请求把要被支付给在线商家的资金的至少一部分分配给委托账户；以及(3)响应于把要被支付给在线商家的资金的部分分配给委托账户，在较小的预定时间段或者直到退款请求或者偿还请求由系统接收时，在委托账户中存储被分配的资金的部分。此外，在一个实施例中，请求可以从通过网络与支付服务提供商通信的商家计算装置被接收。

在一个实施例中，支付服务提供商模块还被配置为针对每个在线商家周期地生成列出已经接收的转账请求和已经被分配给委托账户的资金的部分的协调账户。在另外的各种实施例中，支付服务提供商模块还被配置为用于接收之前从顾客账户被转账到商家的资金的退款请求或者偿还请求；响应于接收到退款请求或者偿还请求，从存储在委托账户中的资金为退款请求或偿还请求提供资金。

在另一个实施例中，系统还包括欺骗阻止模块，其被配置为用于把一个或多个欺骗过滤器应用到请求。欺骗过滤器可以包括：(1)比较与顾客账户相关联的第一位置和与用于把请求发送到在线商家的顾客计算装置相关联的第二位置，并且根据第一位置位于第二位置的第一预定可接受距离之外，把请求标记为潜在的欺骗；(2)比较与顾客电子邮件地址相关联的第三位置和第二位置，并且根据第三位置位于第二位置的第二预定可接受距离之外，把请求标记为潜在的欺骗；(3)比较与针对顾客账户的顾客账单地址相关联的第四位置和第二位置，并且根据第四位置位于第二位置的第三预定可接受距离之外，把请求标记为潜在的欺骗；(4)比较顾客标识和被禁止进行金融交易的个人的列表，并且根据顾客标识与列表上的个人之一相匹配，把请求标记为潜在的欺骗；和/或(5)比较顾客账户的标识和被禁止进行金融交易的账户的列表，并且根据顾客账户的标识与在列表上的账户之一相匹配，把请求标记为潜在的欺骗。

根据本发明的各种实施例，提供了一种为从顾客处接收的退还请求提供资金的方法。该方法包括以下步骤：(1)为商家(例如在线商家)建立委托账户，其由资金的一部分资助，资金将从一个或多个与一个或多个顾客相关联的账户被支付给商家的；(2)接收支付的退还请求，该支付是之前从与特定顾客相关联的账户支付给商家的；以及(3)使用存储在委托账户中的资金资助退还请求。在一个实施例中，资助退还请求的步骤在没有争议的情况下发生。此外，根据各种实施例，退还请求是退款请求或偿还请求。

此外，在另一个实施例中，该方法还包括在特定时间段内(例如至少六个月)响应被存储在委托账户中的部分资金，把在委托账户中的资金的一部分转账到商家的步骤。在另一个实施例中，该方法还包括以下步骤：(1)响应在特定时间段内商家接收减少数目的退还请求，减少由商家支付到委托账户的资金的部分；和(2)响应在所述特定时间段内商家接收增加数目的退还请求，增加由商家支付到委托账户的资金的部分。在另一个实施例中，该方法包括对退还请求应用被配置为用于识别潜在的欺骗退还请求的一个或多个欺骗过滤器的步骤。根据本发明的一个实施例欺骗过滤器由在计算机可读介质上实现的欺骗阻止模块执行。

本发明的各种实施例提供了一种为顾客的退还请求提供资金的方法，其包括以下步骤：(1)接收对于付费的退还请求，该付费是之前使用与顾客相关联的账户支付给商家的；和(2)使用存储在与商家相关联的账户中资金无争议地为顾客的退还请求提供资金。根据各种实施例，退还请求可以是退款请求或偿还请求。此外，根据一个实施例，退还请求可以从持有与顾客相关联的账户的金融机构处被接收，并且退还请求的资金可以被支付给持有与顾客相关联的账户的金融机构。

根据本发明的其它各种实施例，提供了一种用于为在线商家识别从顾客处接收的潜在欺骗的在线金融交易的欺骗阻止系统。欺骗阻止系统包括欺骗阻止模块，其被配置为用于把上述的一个或多个欺骗过滤器应用到从一个或多个顾客接收的每个一个或多个金融交易。此外，在各种实施例中，欺骗过滤器还可以包括：(1)比较与一个或多个相继的金融交易相关联的信息和存储在欺骗数据库中的金融交易，并且响应于每个一个或多个相继的与任何存储在欺骗数据库中的金融交易相匹配的金融交易的顾客账户、顾客标识或者顾客账单地址，把一个或多个相继的金融交易标记为潜在的欺骗；以及(2)比较第一位置和第三位置，并且响应于第一位置位于第三位置的第一可接受距离之外，把金融交易标记为潜在的欺骗。此外，在其中第二位置包括国家的一个实施例中，欺骗过滤器还包括比较第二位置和禁止与商家进行金融交易的国家的列表，并且响应于位于第二位置处在国家的列表中，阻止金融交易进行。

在另一个实施例中，禁止进行金融交易的账户的列表是被窃账户的列表。在另一个实施例中，第一位置是与管理顾客账户的金融机构相关联的位置。以及，在另一个实施例中，第一位置是与顾客账户相关联的账单地址。根据各种其它实施例，第一位置、第二位置、第三位置和第四位置可以是国家、区域、州、地区、县、城市或者由一个或多个邮政编码规定的邮政区域。此外，在一个实施例中，个人的列表和/或账户的列表可以由政府机构公开。

此外，在本发明的一个实施例中，欺骗过滤器基于商家的位置被选择。在本发明的另一个实施例中，欺骗过滤器基于第二位置被选择。以及，在本发明的另一个实施例中，欺骗过滤器基于第一位置被选择。

在另一个实施中，该系统还包括支付服务提供商模块，其被配置为接收顾客的退还请求，并且欺骗阻止模块还被配置为用于比较请求退还的顾客身份和与在线商家相关联的职员、主管或者业主的列表。响应于顾客处在主管、职员或者业主的列表上，欺骗阻止模块把退还请求标记为潜在的欺骗。

根据本发明的另一个实施例，金融交易是打赌支出请求，并且欺骗阻止模块还被配置为用于比较由顾客命名的用于从商家处接收支出的账户的标识和由顾客与商家打赌时使用的账户的标识。，响应于命名的用于接收支出的账户的标识不匹配于与商家打赌时使用的账户的标识，欺骗阻止模块把支出请求标记为潜在的欺骗。在另一个实施例中，欺骗阻止模块还被配置为用于阻止在支出请求中提供的支出量被转帐到取名为接收支出的账户。在另一个实施例中，取名为接收支出请求的账户与第一支付卡相关联以及用于与商家打赌的账户与第二支付卡相关联，并且欺骗阻止模块还被配置为用于比较第一支付卡和第二支付卡。响应第一支付卡与第二支付卡的不匹配，欺骗阻止模块把支出请求标记为潜在的欺骗。

根据本发明的各种实施例，提供了一种用于监视顾客的强制花费行为的系统。该系统包括处理器和存储器，并且处理器被配置为用于：(1)在存储器中存储与来自顾客的与商家进行金融交易的一个或多个请求相关联的信息，该信息包括一定数量的资金；(2)接收新的请求，该请求包括与商家进行金融交易的新的数量的资金；(3)响应于接收到新请求，提取存储在存储器中的资金总额；(4)把资金总额的总量和在新请求中的资金量与预定的可接受的极限相比较；和(5)响应于超过预定的可接受极限的总量，通知一个或多个顾客与顾客相关联的支付来源，或者通知商家：已经超过了预定的可接受极限。在特定的实施例中，被存储在存储器中的信息还包括其上每个请求都已被商家接收的数据；并且处理器还被配置为用于比较在特定时间段内存储在存储器中的资金总额的总量和在新请求中的具有预定的可接受极限的资金数量。

根据本发明的其它各种实施例，提供了另一种用于监视顾客的强制赌博行为的系统。该系统与以上描述的系统相似，但是处理器还被配置为用于针对在新请求中的金融交易类型提取被存储在存储器中的资金总额以及把资金总额的总量和在新请求中的资金的数量的和值与在新请求中的与金融交易类型相关联的预定的可接受的极限相比较。在本发明的各种实施例中，交易类型可以是把资金从与顾客相关联的账户转账到商家的请求或者使用之前被转账到商家的资金进行打赌的请求。此外，在一个实施例中，请求和新请求由与商家相关联的计算装置从与顾客相关联的一个或多个计算装置在网络上被接收。在特定实施例中，其中被存储在存储器中的信息包括其上请求已被商家接收的数据，处理器还被配置为用于把在特定时间段内由顾客请求的资金总额和在新请求中的资金的数量的和值与预定的可接受极限相比较。在另一个实施例中，处理器还被配置为用于响应于和值超出预定的可接受极限，阻止新请求被处理。

根据本发明的各种实施例，提供了一种用于监视顾客的强制花费行为的第三系统，该系统与以上描述的第一系统相似，但是与请求相关联的信息包括请求被商家接收的日期。第三系统的过程还被配置为用于在特定时间段内提取被存储在存储器中的交易总数，比较交易总数和预定的可接受的极限，以及响应于交易总数超出预定的可接受的极限，通知一个或多个顾客：与顾客相关联的支付来源或者通知商家已经超出了极限。

本发明的各种实施例提供了一种用于与在线商家进行金融交易的税务记帐系统。该税务记帐系统包括存储器和处理器，以及存储器被配置为用于存储一种或多种类型的税和一个或多个税收管辖权中的每个的对应税率。该处理器被配置为用于：(1)从顾客接收和与在线商家进行的金融交易相关联的信息；(2)响应接收与金融交易相关联的信息，识别与金融交易相关联的一个或多个税收管辖权；(3)响应识别与金融交易相关联的一个或多个税收管辖权，查询存储器，以确定一种或多种类型的税是否与一个或多个税收管辖权相关联；(4)响应于确定一种或多种类型的税与一个或多个税收管辖权相关联，对与金融交易相关联的信息应用每种一种或多种类型的税的对应的税率，以确定所欠的税的数量；和(5)响应于确定所欠的税的数量，把所欠的税的数量转账到一个或多个相关税务机构。在各种实施例中，税收管辖权与在线商家的位置、顾客的位置和/或由顾客使用的进行金融交易的计算装置的位置相关联。

在另一个实施例中，处理器还被配置为用于经由电子资金转账把数量转账到一个或多个相关税务机构。在另一个实施例中，处理器还被配置为用于使用金融交易信息在特定时间段内把所欠的税的数量和转账到一个或多个相关税务机构的数量存储到存储器中。在另一个实施例中，处理器还被配置为用于为每个一个或多个相关税务机构生成记帐报告，该记帐报告包括所欠相关税务机构的税的数量，转账到相关税务机构的税的数量，和与为此给相关税务机构支付税的金融交易相关联的至少部分的信息。

根据本发明的各种其它实施例，提供了一种用于处理与在线商家进行的金融交易的系统。该系统包括支付服务提供商模块，其被配置为用于：(1)接收把资金从顾客账户转账到在线商家的请求，该请求包括与顾客的地址相关联的第一位置和生成该请求的计算装置的位置；(2)响应于接收到请求，把第一位置、第二位置和在线商家的位置与管理资金到在线商家的转账的位置的列表相比较；(3)响应于第一位置、第二位置或者在线商家的位置与在位置列表上的位置的匹配，确定一个或多个管理机构是管理在第一位置，还是第二位置，还是在线商家的位置处进行的从顾客账户到在线商家的资金转账；和(4)响应于确定一个或多个管理机构管理在第一位置、第二位置或者在线商家的位置处进行的、在线商家的资金转账，通知一个或多个顾客、商家或与和金融交易相关联的顾客的账户相关联的银行：资金转账所承受的一种或多种类型的规章。规章的类型包括一个或多个转账的禁止，转账的限制或转账的税。在一个实施例中，第二位置被与发出到生成请求的计算装置的因特网协议地址相关联。

根据本发明的各种实施例，提供了用于处理与在线商家进行的金融交易的第二系统。该系统包括支付服务提供商模块，其被配置为：(1)接收在顾客账户和在线商家之间进行金融交易的请求(例如与在线商家打赌的请求、把资金转账到在线商家的请求或者来自与在线商家的一个或多个赌博打赌的支付请求)，该请求包括与顾客地址相关联的第一位置和生成该请求的计算装置的第二位置；(2)响应于接收到请求，把第一位置、第二位置和商家的位置与管理与在线商家进行的金融交易的位置的列表相比较；(3)响应于第一位置、第二位置或商家的位置与位置列表的位置向匹配，确定一个或多个管理机构是管理在第一位置、还是第二位置、还是在线商家的位置处的与在线商家进行的金融交易；和(4)响应确定一个或多个管理机构管理在第一位置、第二位置或者在线商家的位置处进行的金融交易，通知一个或多个顾客、商家或与和金融交易相关联的顾客的账户相关联的银行：资金转账所承受的规章类型。

在一个实施例中，支付服务提供商模块还被配置为响应于确定一个或多个管理机构管理在第一位置、第二位置或商家的位置处与在线商家进行的金融交易，阻止金融交易与商家进行金融交易。此外，在另一个实施例中，支付服务提供商模块还被配置为响应于确定一个或多个管理机构管理在第一位置、第二位置或商家的位置处的与在线商家进行的金融交易，通知一个或多个在线商家或与顾客的账户相关联的银行。

附图说明

因此已经概括地描述了本发明的各种实施例，现在将参考附图，其不必要按比例绘制，其中：

图1是根据本发明的各种实施例的金融交易处理系统的高级框图；

图2是根据本发明的各种实施例的在金融交易处理系统中的各种契约关系的图示；

图3A是根据本发明的一个实施例的计算装置的示意图；

图3B是根据本发明的替代实施例的计算装置的示意图；

图4是示出了根据本发明的各种实施例的金融处理系统的示意图；

图5是根据本发明的各种实施例的商家模块的框图；

图6是根据本发明的各种实施例的IPSP模块的框图；

图7A是根据本发明的各种实施例的欺骗阻止子模块的框图；

图7B是根据本发明的各种实施例的欺骗阻止子模块的流程图；

图8是根据本发明的各种实施例的ASP模块的框图；

图9A和9B是根据本发明的各种实施例的授权交易过程的流程图；

图10A和10B是根据本发明的各种实施例的结算交易过程的流程图；

图11是根据本发明的各种实施例的退款交易过程的流程图；和

图12是根据本发明的各种实施例的顾客支付交易过程的流程图。

图13是根据本发明的一个实施例的授权交易请求的流程图。

图14是根据本发明的一个实施例的结算交易请求过程的流程图。

图15是根据本发明的一个实施例的监视强制花费行为的过程的流程图。

图16是根据本发明的一个实施例的监视强制赌博行为的过程的流程图。

图17是根据本发明的一个实施例的确定在金融交易上所欠的任何税的过程的流程图。

图18是根据本发明的一个实施例的识别非法的或承受规章的金融交易的过程的流程图。

具体实施方式

现在将参考附图更加充分地描述本发明的各种实施例，其中示出本发明的某些但是不是全部实施例。实际上，本发明可以以许多不同的形式被实施并且不应该被解释为限制于这里阐述的实施例。而是提供这些实施例使得所公开的内容将满足适用的法律要求。通篇中相同的附图标记是指相似的元件。

简要概述

通常，本发明的各种实施例提供了一种用于电子商业部门的改进的金融交易处理系统，其(1)更加安全地处理支付交易，(2)有助于使商家和银行免受欺骗交易、洗钱和未成年人赌博，以及(3)有助于在被看作构成特殊风险的电子商业区域限制其它滥用，诸如因特网赌博、旅游和顾客购买电子商品。为了达到上述目标，金融交易系统的各种实施例(1)为商家、因特网支付服务提供商、收单银行和卡组织建立了操作和交易处理协议，以及(2)提供用于监视并且处理支付和相关金融交易的改进了的自动化系统。

例如，在本发明的各种实施例中，为每个商家建立并且以减少收单银行或者发行银行损失的风险的方式资助循环储备委托账户。例如，根据一个实施例，通过确保有足够的资金可用于处理由商家接收的退还请求(例如退款和偿还)，损失的风险被减小了。根据一个实施例，支付给商家的某百分率的资金被储备并在某个段时间(例如6个月、1年或者3年)被转账到委托账户，如果在时间段中没有使用该资金，资金被转账回商家。因为资助循环储备委托账户的钱出自商家的潜在利润，使用商家的营业用于洗钱方案可能不太引人注意。此外，根据各种实施例，商家可以争论退款请求的场合被限制为使得可接受的用于争论的场合基本上不增加收单银行或发行银行(例如使用欺骗标志进行标记的交易)的风险。在另一个实施例中，商家可能不被允许在任何场合争论退款。因此，根据各种实施例，循环储备委托账户确保用于处理退款请求的资金的来源，其减少了顾客的损失的风险并可以增加顾客在在线金融交易中将使用担保的可能性。此外，当退还请求被商家资助时，收单银行和发行银行的损失的风险被减小了并可能导致对于商家更有利的营业期(例如更低的交易率或更低的退款率)。

作为另一个例子，在本发明的各种实施例中，金融交易系统的参与者要求彼此遵守本地管理机构。例如，在一个实施例中，如果商家没有遵守，因特网提供商(下面将更加详细地讨论)、收单银行和卡组织可以拒绝与商家交易。作为替代，在一个实施例中，参与者可以罚款不遵守的参与者。此外，顾客还可以拒绝与不遵守的商家交易。通过建立这种协议，金融交易系统试图为保持遵守本地管理机构的参与者提供一种市场激励。

根据本发明的各种实施例，金融交易系统的参与者可以包括在线顾客、在线商家、因特网支付服务提供商(IPSP)、收单银行、发行银行或者卡组织。IPSP在网络上在商家和收单银行之间运作以把与支付相关的服务提供给商家和商家与收单银行之间的界面。此外，IPSP可以与记帐服务提供商(ASP)签订合同以提供与IPSP提供给商家的支付服务相关的记帐管理服务。

图1根据本发明的各种实施例示出了各个参与者怎样与彼此接口的高级示意图。例如，参与者可以在网络(例如因特网、私有网络或者私有LAN网络)上电子地交换交易信息。特别地，交易信息可以包括来自商家的把钱从与顾客支付卡相关联的账户转账到商家的账户的授权请求、来自发行银行的授权钱从顾客的账户转账到商家的账户的授权消息、来自发行银行的请求钱从商家的账户转账到顾客的账户的退还(例如退款或偿还)请求，以及每个商家在特定时间段(例如，24小时、48小时或一周)期间处理的所有交易的结算请求。

尽管以上讨论的实施例描述了使用与账户相关联的支付卡(例如借记卡、信用卡、预付卡或感应卡)从在线商家购买商品和服务，应该理解在各种其它实施例中，其它类型的支付模式可以被用于进行购买。例如，替换的支付模式可以包括使用与账户相关联的支付代币(例如物理的或电子的代币)或使用与账户相关联的号码(例如用于访问账户的账户号和口令)。其它支付模式可以包括通过使用与账户相关联的生物测定数据授权支付，诸如例如虹膜扫描、指纹和声音识别。支付还可以通过账户号和可以由代币或者经由电话、电子邮件或短消息服务(“SMS”)提供的一次性口令的组合被授权。

如以上简单讨论的，根据各种实施例的金融交易系统提供了(1)针对参与者的操作和处理协议和(2)适配于处理具有高级别安全的金融交易的自动化监视和处理系统(例如计算机软件和/或硬件)。这些协议和自动化系统用于保护顾客和参与者免于欺骗交易和可能在电子商业交易中创造风险的其它滥用。以下在部分A中详细描述由系统实施的协议的各种例子，以及以下在部分B中描述自动化系统的各种实施例。在部分C中详细描述通过金融交易系统处理的各种交易的示例性流程。

A.示例性协议

金融交易系统的各种实施例为参与者提供了操作和处理协议。根据各种实施例，阻止有组织的犯罪和使用商家的营业进行洗钱计划的协议服务，减少了通常与在线金融交易相关联的欺骗和未授权交易的风险并减少了收单银行和发行银行的损失的风险，并增加了遵守政府或本地管理规章的或然率。例如，根据本发明的各种实施例，参与者应该能够表明遵守本地或司法管理机构并应该保持在特定时间段(例如，2年、3年或5年)内处理的交易的可审计记录。此外，协议可以要求每个参与者在进入与其它参与者签订合同之前表明遵守本地管理要求，以及协议可以要求参与者周期地验证其它参与者保持与本地管理机构好的声誉。以下描述可以为商家和IPSP建立的各种示例性协议。

商家

根据本发明的各种实施例，商家可以被要求完全地公开公司主管、职员和受益股东的身份并把任何变化报告到IPSP。要求提供这个列表并把该列表与被怀疑参与有组织的犯罪的人和实体的列表比较，可以帮助阻止有组织的犯罪链使用商家的营业用于洗钱或其它非法目的。

此外，根据本发明的各种实施例，商家可以被要求采取有助于减少来自欺骗交易的收单银行、发行银行和顾客的损失的风险的一个或多个步骤。例如，根据各种实施例，商家可以被要求(1)表明遵守所有相关管理要求，(2)任何契约责任被破坏时支付惩罚付费，(3)使用地址验证、年龄验证和在商家的计算装置上的身份验证软件，来验证在在线交易期间提供的支付信息和顾客信息，(4)对所接收的支付和顾客信息执行初始欺骗检验并之后执行随机或周期检验，或(5)把通知提供给正在使用IP地址访问系统的顾客或者提供与其中交易被视为非法的权限相关联的账单地址的顾客。

而且，根据各种实施例，商家可以被要求执行减轻与商家的营业相关联的滥用(如果有)的风险或者与商家进行的交易的可见的社会影响(例如强制花费，如果商家是在线赌博商家或成人娱乐提供商)的协议。例如，商家可以被要求提供关于它的营业的社会影响的建议和帮助资源(例如免费的帮助热线电话号码、提供有帮助的信息的网站或顾问的联系信息)。此外，根据一个实施例，商家可以被要求在顾客的支付卡清单上提供商家的姓名和免费电话号码，使顾客可以呼叫顾客服务和查询交易。根据本发明的各种实施例，顾客服务代表应该是24/7可用的。

IPSP

根据本发明的各种实施例，IPSP可以被要求实施一个或多个以下的安全特征以帮助阻止有组织的犯罪链或来自使用商家营业用于洗钱目的其它犯罪，并为各种参与者减少与在线金融交易相关联的风险：(1)为每个商家建立将处理来自它的退还请求的循环储蓄委托账户，诸如以上讨论的委托账户，(2)监视交易，以识别可疑的活动，(3)以每张支付卡为基础监视交易的频率和数值，(4)为跟踪和审计的目的，把每个商家(或网站)的交易保持在分开的流中，(5)周期地(例如每2秒或每10秒)保存交易信息以创建审计审问以及在特定时间段(例如1年、2年或5年)存储交易信息，(6)验证卡持有者的身份，(7)要求商家公开公司主管和受益股东给IPSP，(8)限制从因特网赌博商家到卡持有者的奖金的支付并从可适用的制裁列表(例如U.S.“特别指定国家列表”)筛选收款人的姓名，(9)要求商家在可适用本地法律和规章下被许可并保持好的金融和法律声誉，(10)惩罚被发现破坏契约责任的商家(例如，通过终止与商家的合同或罚款商家)，(11)在良好管理的司法中使用几个Tier1收单银行并由它们保证，(12)要求商家实施目的在于保持卡持有者信息安全的政策、步骤和标准(例如，由VISA的账户信息安全(“AIS”)项目保证)，和(13)操作和应用Financial Action Task Force on MoneyLaundering的推荐(例如，www.FATF-GAFL.org)(例如，参见附录A中的“Anti-Money Laundering/Combating Terrorist FinancingMethodology(with FATF 40+9 incorporated)”(由InternationalMonetary Fund发行))。此外，在各种实施例中，IPSP保持欺骗数据库42，如在图1中所示的，用于存储关于由IPSP处理的呈现为或被确定为欺骗的交易的信息。根据一个实施例，当处理交易时IPSP允许其它参与者利用欺骗数据库，进一步减少了发行银行、收单银行、商家和顾客的损失的风险。尽管IPSP可以管理它自己的记帐和欺骗数据库、协调它处理的交易，并为商家生成协调报告，但根据另一个实施例，IPSP可以与ASP签订合同以提供这些服务中的一个或多个服务。

此外，根据本发明的一个实施例的示例性协议可以要求IPSP为每个商家创建分开的公司实体(例如，SG1、SG2、SG3等)，以及这些公司实体在IPSP和/或ASP的指导下操作，以管理为与公司实体相关联的特定商家接收的资金，这将参考图14更详细地讨论。根据各种实施例，该公司结构把每个商家的操作分离。此外，根据各种实施例，该公司结构提供确保公平和客观地管理委托资金的合法结构，委托资金是为了保护金融交易系统和顾客。

收单银行

根据本发明的各种实施例，示例性协议可以要求收单银行实施一个或多个以下的安全特征以减少与在线交易相关联的发行银行和顾客的风险：(1)监视在线商家的信用活动以确保顾客能够从商家接收奖金或点数到他们的支付卡上(例如，由VISA赞助的卡持有者资金转账(CFT)导引，，和由MasterCard赞助的Money Flow导引)，(2)确保所有卡组织规章被传送到IPSP和商家，(3)确保交易信息具有正确的数据单元，如由卡组织和发行银行规定的，和(4)确保IPSP遵守可适用的管理计划。

参与者之间的约定

根据本发明的各种实施例，一个或多个系统协议可以被并入参与者之间的约定以确保遵守建立的协议。例如，图2根据本发明的各种实施例示出参与者之间的契约关系的示意图。特别地，收单银行36、IPSP 34和每个商家31、32、33可以进入三方处理合同45，其阐述了关于交易怎样被处理的每方的责任。该约定45可以要求每方保持与本地管理机构的良好声誉，提供主管、职员和受益股东的更新列表给其它方，执行某种身份验证和对交易信息的欺骗检验，并在特定时间段(例如，1年、3年、5年)为了审计目的存储交易信息。此外，根据一个实施例，约定45可以包括一个或多个其中商家可以争论退款请求的场合。根据另一个实施例，约定45可以建立商家31、32、33针对退款应担负的费用。

此外，收单银行36和IPSP 34可以进入信任约定47，其阐述IPSP应该对交易数据实施的特定欺骗检验和以每个商家的名义，IPSP何时应该请求结算(例如，每天或每周)。

ASP35和每个商家31、32、33可以进入委托约定49，其阐述商家ASP将怎样以商家的名义管理循环储蓄委托账户(例如资金被拿出用于委托账户的百分比，资金被存储在委托账户中的时间长度或者协调报告的格式)。

此外，ASP 35和IPSP 34可以进入服务约定43，其阐述关于由ASP提供给IPSP的记帐服务的每方的责任(例如，在ASP和IPSP之间交换的数据的格式和可访问性，为IPSP 34或以IPSP 34的名义由ASP生成的摘要报告的类型和格式，可支付给一个或多个参与者的费用的计算，或者为商家审批协调报告的审批步骤)。此外，在一个实施例中，ASP 35可以由约定43要求，以响应于来自商家31、32、33的关于由IPSP 34或由ASP 35为了IPSP 34处理的交易的查询。此外，在另一个实施例中，ASP 34可以被要求(a)识别由ASP 35以IPSP 34的名义处理的所有交易数据和(b)把识别的数据转发到商家31、32、33以确定如果有，关于退款请求商家31、32、33希望采取什么进一步的行动。

B.用于监视和处理交易的自动化系统

本领域的技术人员将理解，本发明可以作为一种方法、一种交易处理系统或一种计算机程序产品被实施。因此，本发明可以采取完全硬件实施例、完全软件实施例或软件和硬件方面结合的实施例的形式。此外，本发明可以采取在计算机可读存储介质上具有在存储介质中实施的计算机可读程序指令(例如计算机软件)的计算机程序产品的形式。更特别地，本发明可以采取网站实现的计算机软件的形式。任何合适的计算机可读存储介质可以被利用，包括硬盘、CD-ROM、光学存储介质或磁存储介质。

以下将参考根据本发明的实施例的方法、设备(即系统)和计算机程序产品的框图和流程图描述本发明。应该理解，框图和流程图的每个方块，以及在框图和流程图中的方块的组合，可以分别由计算机程序指令实施。这些计算机程序指令可以被下载到通用计算机、专用计算机或者其它可编程数据处理设备上以产生一种机器，使得在计算机上或其它可编程数据处理设备上执行的指令创建一种用于实施在流程图框中指定的功能的装置。

这些计算机程序指令还可以被存储在能够指导计算机或其它可编程数据处理设备以一种特定的方式运行的计算机可读存储器中，使得存储在计算机可读存储器中的指令产生一种包括用于实现在流程图或框中指定的功能的计算机可读指令的产品。计算机程序指令还可以被下载到计算上或其它可编程数据处理设备上以使在计算机上或其它可编程设备上执行的一系列操作步骤生成计算机实现过程，使得在计算机上或其它可编程设备上执行的指令为实现在流程图框中指定的功能。

因此，框图和流程图的方块支持用于执行指定功能的装置的组合、用于执行指定功能的步骤的组合和用于执行指定功能的程序指令装置。还应该理解，框图和流程图的每个方块，和在框图和流程图中的方块的组合可以通过执行指定功能或步骤的基于硬件的专用计算机系统或者专用硬件和计算机指令的组合被实现。

在这里描述的各种实施例中，“计算机”或“计算装置”可以被提及。这种计算机可以是，例如大型机、台式机、笔记本电脑或膝上型电脑、诸如数据获取和存储装置的手持装置，或者它可以是配备在另一个设备中的处理装置，诸如例如无线电话。在某些例子中，计算机可以是用于在网络上访问数据或处理器的“哑”终端。转到图3A，计算装置的一个实施例被示出，其可以被用于实现本发明的各种实施例。在图3A中，处理器1，诸如微处理器，被用于执行实现规定步骤的软件指令。处理器从当需要时也为其它部件提供能量的电源17接收能量。处理器1使用通常是16或32比特宽(例如，并行的)的数据总线5通信。数据总线5被使用来转送数据和程序指令，典型地在处理器和存储器之间。在各种实施例中，存储器可以被认为是仅在运行期间保留内容的RAM或其它形式的主存储器2，或者它可以是非易失性存储器3，诸如ROM、EPROM、EEPROM、FLASH或其它类型的在所有时间都保留存储内容的存储器。存储器还可以是辅助存储器4，诸如存储大量数据的磁盘存储器。在某些实施例中，磁盘存储器可以使用I/O总线6，代替地或专用总线(未示出)与处理器通信。辅助存储器可以是软盘、硬盘、光盘、DVD或者计算机领域的技术人员已知的任何其它类型的大容量存储器类型。

处理器1还使用I/O总线6与各种外围或外部装置通信。在各种实施例中，外围I/O控制器7被用于提供标准接口，诸如RS-232、RS422、DIN、USB或合适与各种输入/输出装置接口的其它接口。典型的输入/输出装置包括本地打印机18、监视器8、键盘9和鼠标10或其它典型的指向装置(例如、轨迹球、触摸板、操纵杆等)。

处理器1通常还使用通信I/O控制器11与外部通信网络通信，并可以使用各种接口，诸如数据通信有关的协议12，诸如X.25、ISDN、DSL、线缆调制解调器等。通信控制器11还可以并入用于与标准电话线13接口和通信的调制解调器(未示出)。最终，通信I/O控制器可以并入用于LAN上通信的以太网接口14。这些接口中的任何一个可以被用于访问广域网，诸如因特网、内联网、LAN或其它数据通信设施。

此外，处理器1可以与可操作地连接到天线15用于通过使用例如IEEE 802.11协议、802.15.4协议或标准3G无线通信协议诸如CDMA20001x EV-DO、GPRS、W-CMDA或其它协议与另一个装置进行无线通信的无线接口16通信。

在图3B中示出可以使用的处理系统的替代实施例。在该实施例中，示出了包括与本地客户计算机26a或远程客户计算机26b通信的服务器20的分布通信和处理体系结构。服务器20通常包括与数据库22(例如SQL数据库)通信的处理器21，其可以被看作辅助存储器以及主存储器24的一种形式。处理器还使用通常与LAN25接口的I/O控制器23与外部装置通信。LAN可以提供与网络打印机28和本地客户计算机26a的本地连接。这些可以被置于与服务器相同的设施中，尽管不一定在同一个房间中。与远程装置的通信典型地通过通信设施把来自LAN25的数据路由至广域网27、诸如因特网而完成。远程客户计算机26b可以执行网络浏览器，如有需要，通过广域网27在LAN25上把数据发送到服务器20，而允许远程客户26b与服务器交互。此外，网络浏览器可以包括例如以Java Scrip和Microsoft.net开发的用户接口。

数据网络的技术人员将意识到许多其它替代和体系结构是可能的，并且可以被用于实施本发明的各种实施例。在图3A和3B中所示的实施例可以以不同的方式被修改并且在本发明的范围之内。

图4示出根据本发明的各种实施例的、与每个参与者相关联的、并且与经由一个或多个网络115(例如私有网络、私有LAN网络或因特网)互相通信的计算装置101-109。例如，根据一个实施例，IPSP34可以建立可由商家31、32、33和收单银行36通过把IPSP网络连接到由商家31、32、33和收单银行利用的网络的IPSP网关40访问的IPSP网络。根据各种实施例，IPSP网关40可以完全作为硬件、完全作为软件或作为两者的组合被实施。在一个实施例中，IPSP网关40通过选择性地允许访问IPSP网络确保被发送到IPSP网关40的和从其发送的信息的安全。例如，与IPSP 34没有契约关系的商家31、32、33或收单银行36可以被拒绝通过IPSP网关40访问IPSP网络。

此外，根据本发明的各种实施例，收单银行36可以利用卡组织网络以与收单银行37、38、39交换信息。卡组织网络的例子包括但不限于VISA、MasterCard和American Express网络。

如上参考图3A和3B讨论的，根据各种实施例，商家31、32、33、IPSP 34、ASP 35、收单银行36和发行银行37、38、39可以与一个或多个计算装置(例如，一个或多个服务器、SQL服务器或网络浏览器)相关联，并且这些计算装置中的一个或多个可以包括用于处理金融交易的自动化系统。例如，系统100提供了被配置为在商家的系统101、102、103上运行的商家模块200，被配置为在IPSP的系统104上运行的IPSP模块300，和被配置为在ASP的系统105上运行的ASP模块400。根据一个实施例，这些模块200、300、400使每个参与者的处理功能自动化。这些模块可以完全作为硬件、完全作为软件或作为两者的组合被实施。

此外，根据本发明，如果IPSP 34与ASP 35签订合同提供记帐相关的服务，ASP模块400可以被配置为在ASP系统105上运行，或者，在另一个实施例中，ASP模块400可以被配置为在IPSP的系统104上运行。以下参考图5-8更加详细描述这些模块的各种实施例。

商家模块

图5示出根据本发明的各种实施例的商家模块200的框图。根据各种实施例，商家模块200在商家系统101、102、103上运行，并且使商家执行的处理交易的步骤的至少一部分自动化。例如，商家模块200被配置为处理授权请求，这被示为步骤202。在步骤202，商家模块200从顾客接收支付信息，其可以包括商家的全名和账单地址、电子邮件地址、信用卡号、CVV2号、支付数量或卡发行商名称中的某些或全部。然后商家模块200验证接收的支付信息的格式，诸如验证信用卡号是否是有效的号码以及是否所有的字段都已经被完成。商家模块200还可以被配置为比较顾客信息和之前存储的与3-D安全软件插件(例如，Visa的Verify和MasterCard的SecureCode)相关联的标识和口令。如果格式是正确的，商家模块200生成并且发送授权请求到IPSP系统104，用于进一步的处理。

根据本发明的各种实施例，商家模块200还被配置为在接收的交易请求上执行初步欺骗检验，如步骤206所示。初步欺骗检验步骤206可以包括例如比较信用卡号和被窃的信用卡号的列表，验证由顾客提供的账单地址与支付卡的账单地址匹配，比较提供的账单地址和当顾客初始商家向商家登记时提供的账单地址，或者验证卡发行商的名称与卡的银行识别号(BIN)匹配。此外，欺骗检验步骤206可以在授权请求被发送到IPSP(步骤202)后，如在图5中所示，或者在生成和发送授权请求之前(未示出)被执行。在一个实施例中，欺骗检验步骤206在授权请求已经被发送(步骤202)之后但是在与发行银行结算之前被执行。

如果在欺骗检验步骤206中没有检测出潜在问题，商家模块200验证顾客的年龄和身份，如步骤210所示。例如，年龄可以通过检验卡持有者的政府记录被验证，诸如投票人登记记录或驾驶证记录，或者通过建立与电子年龄和/或身份验证服务(例如，由基于UK的GBGroup提供的“URU”服务)的网络连接和提供顾客的信息给该服务而被验证。根据各种实施例，所述服务比较顾客的信息和政府或者其它公共记录，以验证顾客的身份和年龄。在一个实施例中，当顾客建立与商家的新账户时商家模块200可以执行年龄和身份验证步骤210。步骤210的过程可以被周期地或随机地重复进行，之后重新验证现有顾客的身份和年龄。此外，在图5中所示的实施例中，年龄和身份验证步骤210被示出为在欺骗检验步骤206和授权请求步骤202之后发生。然而，在其它实施例中，年龄和身份验证步骤210可以在授权请求步骤202或欺骗检验步骤206之前发生。

根据一个实施例，如果顾客的年龄和身份没有在年龄和身份验证步骤210中验证或者如果欺骗检验步骤206检测到交易的潜在问题，商家模块200可以通知顾客交易被拒绝，和通知IPSP交易应该被拒绝，如步骤208所示。

此外，根据各种实施例，商家模块200被配置为显示或者相反通知顾客特定时间段(例如，每次会话、24小时或一周)期间花在商家的网站上的时间数量。拥有这种信息可以帮助顾客避免关于商家的网站的强制行为。此外，商家模块200可以被配置为允许顾客访问由商家保存的顾客的交易日志。此外，商家模块200可以被配置为实现自身动调节方针，诸如例如损失的极限(例如赌博交易)，或者在商家的网站上花的时间和/或钱。

为了避免洗钱，商家模块200还可以被配置为执行反洗钱软件(例如把可获得的数据与在由International Monetary Fund发行的“Anti-Money Laundering/Combating Terrorist FinancingMethodology(with FATF 40+9 incorporated)”中阐述的参数比较的软件)，作为附录A附上，以评估在选择的数量中(例如15000英镑或20000美元)的任何交易。软件的评估可以包括身份验证和重新验证，跟着是对验证的个人或公司的检验。

IPSP模块

图6示出根据本发明的各种实施例的IPSP模块300的流程图。根据一个实施例，IPSP模块300被配置为在IPSP系统104上运行。从步骤302开始，根据一个实施例，IPSP模块300处理从商家系统101、102、103接收的授权请求。每个授权请求可以包括特定交易的支付信息和与交易相关联的顾客信息，诸如顾客的全名、顾客的电子邮件地址和由顾客使用以发起交易的计算装置的IP地址。根据本发明的各种实施例，然后IPSP模块300把授权请求发送到收单银行系统106，收单银行系统把授权请求发送到合适的发行银行系统107、108、109。如以下参考图9A和9B更详细地讨论的，根据各种实施例，IPSP模块300从发行银行系统107、108、109经由收单银行系统106接收授权消息，授权或拒绝交易，并且IPSP模块300把授权消息发送到商家系统101、102、103。

根据各种实施例，在步骤304，IPSP模块300存储由IPSP模块300处理的交易信息(例如授权请求、退款请求、偿还请求和结算请求)。存储的交易信息可以被用于审计目的，基于每个顾客、每个支付卡或每个商家监视交易的类型和频率，以及生成结算请求并响应于结算请求，分配接收的资金的支付。例如，授权、退款和偿还请求可以被周期地存储，诸如例如每秒或每十秒，或者基于每次交易，诸如每当IPSP模块300接收和处理交易信息时。这些请求可以被存储特定时间段(例如一天或一周或更长)。此外，根据各种实施例，请求可以基于每个商家被存储(或如果商家具有多于一个网站支持电子商业交易，则基于每个URL(统一资源定位器))。IPSP模块300周期地(例如每天或每周)把每个商家的授权请求集合成每个商家的结算请求文件，并把商家的结算请求在批处理文件中发送到收单银行系统106用于结算，下面将参考步骤310对其进行讨论。IPSP模块300可以把集合的交易信息作为分开的文件存储一定的时间段(例如，一年、两年或三年)。

在本发明的各种实施例中，IPSP模块300还被配置为执行欺骗阻止子模块350，其在图6中作为步骤306被示出并以下参考图7A和7B更详细地讨论，用来验证交易应该由系统100进行结算。例如，如果支付卡号被在偷窃的支付卡号的列表上列出，顾客的IP地址的国家与支付卡发行的国家不匹配，或者顾客在国家制裁列表上(例如，美国的“Specially Designated Nationals list”)，IPSP模块300将不显示结算的交易。在图6中所示的实施例中，欺骗阻止子模块350的执行被示出，其在授权请求处理步骤302和交易信息存储步骤304之后发生。然而，根据本发明的其它实施例，步骤306可以在步骤302中的发送授权请求到收单银行系统106之前或者在步骤304中的存储交易信息之前由IPSP模块300执行。

根据本发明的各种实施例，如果欺骗阻止子模块350在步骤306中检测到交易的潜在的欺骗的活动，IPSP模块300被配置为把被怀疑的欺骗活动通知合适方，这在步骤308中被示出。根据各种实施例的合适方可以包括收单银行36(其可以把通知传递到发行银行)、发行银行37、38、39(直接地)、商家31、32、33和/或顾客。此外，根据各种实施例，IPSP模块300被配置为在欺骗数据库42中存储关于潜在的欺骗交易的信息，如步骤312所示。欺骗数据库42可以由IPSP模块300利用来分析随后的交易。此外，在一个实施例中，欺骗数据库42可以被卡发行商网络和/或收单银行访问以分析接收的交易。此外，欺骗数据库42可以包括一个或多个以下字段：顾客姓名、地址、IP地址、支付信息(例如卡或账户号)、电话号码和识别之前欺骗活动的代码或描述。

如在步骤310中所示，根据本发明的各种实施例，如果欺骗阻止子模块350在步骤306中没有检测到任何潜在的欺骗活动，IPSP模块300被配置为生成和发送结算请求到收单银行系统106或发行银行系统107、108、109。结算请求是基于在特定时间段(例如一天或一周)中由IPSP模块300接收的授权、退款和偿还请求。根据一个实施例，结算请求可以仅包括那些没有被IPSP模块300和商家模块200作为潜在的欺骗被检测出的交易。作为替代，结算请求可以包括已经被IPSP模块300或商家模块200作为潜在的欺骗检测出的、但是在结算请求中标记或标志为潜在的欺骗的一个或多个交易。

如上所述，IPSP模块300在步骤306中执行欺骗阻止子模块350。根据本发明的各种实施例，示例性欺骗阻止子模块350在图7A和7B中被示出。如在图7A和7B中所示，欺骗阻止子模块350执行各种步骤，这里被称为“欺骗过滤”，以检测潜在的欺骗交易活动，并可以被配置为根据特定欺骗过滤器的结果或来自欺骗过滤器组的结构的组合，阻挡或标志交易。根据本发明的各种实施例，步骤352-368示出可以由欺骗阻止子模块350执行的几个欺骗过滤器。图7B示出根据本发明的各种实施例的由欺骗阻止子模块350执行的确定对交易信息应用哪个欺骗过滤器的步骤。

例如，如在图7A中的步骤352中所示，欺骗阻止子模块350可以比较支付卡信息和标识被窃支付卡的列表。此外，如在步骤354中所示，欺骗阻止字模块350可以比较与发行支付卡的金融机构相关联的位置和与和顾客的计算装置相关联的IP地址相关联的位置。当交易信息由商家系统101、102、103初始接收时，与顾客的计算装置相关联的IP地址可以由商家模块200获得(例如通过使用被集成到商家模块200中的IP地址检测软件)。此外，欺骗阻止子模块350可以被配为比较与顾客的计算装置的IP地址相关联的位置和顾客的账单地址以确保顾客的计算装置的位置在账单地址的特定范围之内(例如50英里)。相似地，欺骗阻止子模块350可以比较与发行支付卡的金融机构相关联的位置和与顾客提供的电子邮件地址相关联的位置，如在步骤356中所示，或者比较顾客的计算装置的IP地址的位置和与顾客提供的电子邮件地址相关联的位置，如在步骤357中所示。以上比较的位置可以包括国家、区域、州、地区、县、城市或者由一个或多个邮政编码限制的邮政区域中的一个或多个。

此外，如在步骤358中所示，欺骗阻止子模块350可以比较支付卡的银行识别号(BIN)和可疑的BIN的列表，以及在步骤360中，欺骗阻止子模块350可以识别和标志由具有网络邮件电子邮件地址(例如，HOTMAIL或YAHOO电子邮件地址)的顾客发起的交易。此外，如在步骤362中所示，欺骗阻止子模块350可以比较顾客的信息和政府编译的在政府的权限中被禁止与商家进行金融交易的个人的列表。如果顾客被识别为在受到由权限公布的金融制裁的个人、集团和实体的列表上，诸如由U.S.发行的“Specially Designate Nationalslist”，则交易可以被拒绝。相似地，如在步骤368中所示，欺骗阻止子模块350可以比较与顾客的计算装置的IP地址相关联的国家和在特定权限中被禁止与商家进行交易的国家的列表，并且如果IP地址的国家在所述列表上，则交易可以被拒绝。此外，如在步骤367中所示，欺骗阻止子模块350可以比较顾客的信息和在线商家的职员、主管或业主商家的列表，并且如果顾客在列表上，则交易可以被标志为潜在的欺骗或被拒绝。

根据各种实施例，欺骗阻止子模块350还可以被配置为监视在特定时间段期间(例如一个月、一年)每个顾客或每张卡的交易的频率，如在步骤364中所示。此外，如在步骤366中所示，欺骗阻止子模块350可以被配置为监视在特定时间段期间为顾客或卡的交易的类型(例如，赌博交易、旅游交易、成人娱乐交易)。根据本发明的各种实施例，通过基于每卡或每顾客监视交易的频率和类型，欺骗阻止子模块350可以(1)如果卡的使用显著地改变，则识别它的潜在欺骗的使用和(2)如果顾客更加频繁地或太频繁地参与特定类型地交易，则识别潜在的嗜好或滥用。根据一个实施例，监视步骤364和366可以通过基于顾客之前的交易建立交易的频率和类型范围和比较将来的交易与所建立的范围而被完成。根据其它实施例，欺骗阻止子模块350使用的范围可以由本地政府或管理机构公开，可以从学术的或学院的研究等等得出，或者可以由一个或多个参与者建立。

图15示出根据本发明的各种实施例的监视强制花费行为的过程。具体地，从步骤502开始，由IPSP模块300接收金融交易的新请求。响应于接收到新请求，IPSP模块300提取已经存储在存储器24中的、与之前请求的在特定商家31、32、33和顾客之间的金融交易相关联的资金总额，如步骤504所示。在步骤506，提取的资金总额的总数量和在新请求中的资金的数量与预定的可接受的花在商家31、32、33上的资金的极限相比较。如果总数量超过预定的可接受的极限，IPSP模块300通知合适方(例如顾客、发行银行和/或商家)已经超出极限，如在步骤508中所示。在本发明的替代实施例中，IPSP模块300被配置为用于比较在特定时间段期间在顾客和商家之间进行的交易的数量，并且如果进行的交易的数量超出预定的可接受的极限，那么IPSP模块300通知顾客、发行银行和/或商家：极限已被超出。

相似地，图16示出根据本发明的各种实施例的监视强制赌博行为的过程。从步骤602开始，金融交易的新请求由IPSP模块300接收。新请求可以包括资金的数量和交易的类型(例如，把资金转账到商家，与商家打赌，请求从商家支出)。接下来，在步骤604，IPSP模块300为在新请求中的金融交易类型提取被存储在存储器24中的资金总额。然后，在步骤606，资金总额的总数量和在新请求中的资金数量与预定的可接受的、与在新请求中的金融交易类型相关联的极限。如果总数量超出预定可接受的极限，IPSP模块300通知合适方(例如，顾客、发行银行和/或商家)：已经超出极限，这在步骤608中被示出。在一个实施中，如果总数量超出预定的可接受的极限，则拒绝新请求。此外，从存储器提取的资金总额可以被限制于在特定时间段内存储的那些资金，并且预定的可接受的极限可以基于查询的时间段被改变。

除了以上提到的监视交易的类型，根据本发明的各种实施例，欺骗阻止子模块350还可以被配置为监视退还请求交易和识别可疑的交易。响应于识别可疑的退还请求交易，诸如通过识别其中退还请求信息与在原先交易中的信息不一致的交易或者通过识别特定时间段期间(例如，在一周、一个月或者几个月中)特定支付卡的很大数量的退还请求交易，支付卡号可以被添加到禁止的支付卡的列表，因此阻止使用该支付卡的未来购买交易。

除了以上的过滤器，根据本发明的各种实施例，欺骗阻止子模块350还可以被配置为(1)确保每个顾客仅使用一个支付卡和(2)把在特定时间期间每个顾客的某种活动的支付限制为特定的频率(例如，每天一次支付或每36小时三次支付)。此外，根据一个实施例，可以设置在特定时间段期间(例如，每天、每周或每月)在特定服务(例如，因特网赌博或成人娱乐)上每卡或每顾客可以花费的数量的最高限度。在一个实施例中，最高限度可以按照顾客的要求设置。在另一个实施例中，IPSP系统104可以对可以花费在某种活动上的数量引进默认的极限(例如，与支付卡相关联的信用卡的极限的20％)，如果没有顾客的明确的请求这不能增加。根据一个实施，IPSP系统104或商家系统101、102、103可以被配置为响应于接收增加花费极限的请求，把关于过度花费的风险的材料呈现给顾客，诸如经由来自专门培训的雇员的电话或到顾客的电子邮件，并且当潜在的滥用被检测到时呈现材料或资源(例如，赌博者匿名电话号码、网站地址或其它材料)。

根据本发明的各种实施例，IPSP系统104还包括存储来自欺骗阻止模块350的结果的欺骗和滥用数据库(未示出)。在一个实施例中，当处理交易(步骤302)时或当执行欺骗阻止子模块(步骤306)根据之前的特定支付卡或顾客的欺骗检验，以确定交易是否应该被拒绝时，IPSP模块300访问数据库。

如在图7B中所示，根据本发明的一个实施例，欺骗阻止子模块350可以使用以上描述的欺骗过滤器中的一个或多个以评估接收的交易信息。从步骤370开始，欺骗阻止子模块350从IPSP模块300接收交易数据。接下来，在步骤372中，欺骗阻止子模块350确定该一个或多个过滤器在评估交易数据中使用。例如，根据一个实施例，欺骗阻止子模块350使用之前由商家选择使用的欺骗过滤器。根据另一个实施例，使用的欺骗过滤器的类型依赖于交易的类型(例如，授权请求、退款请求、结算请求或支付请求)或者交易的哪一个阶段(例如交易信息是否还没有被发送到发行银行或者它是否已经被发行银行授权)。在另一个实施例中，使用的欺骗过滤器的类型依赖于与顾客相关联的IP地址的国家。并且在另一个实施例中，选择应该应用哪一个欺骗过滤器由IPSP和/或本地管理机构决定。最后，在步骤374中，欺骗阻止子模块350执行合适的欺骗过滤器以评估交易数据。

根据本发明的各种实施例，除了执行欺骗阻止子模块350以外，IPSP模块300还被配置为用于识别非法的或受管理限制的金融交易。例如，图18示出识别非法或被限制的金融交易的示例性过程。从步骤802开始，IPSP模块300从顾客的支付卡接收把资金转账到商家31、32、33的请求。转账资金的请求包括顾客的账单地址和与由顾客使用以生成请求的计算装置相关联的IP地址的位置。接下来，在步骤804中，IPSP模块300把顾客的账单地址、IP地址的位置和商家31、32、33的位置与管理到商家31、32、33的资金转账的位置的列表比较。如果这些位置中的任何一个与位置列表上的位置匹配，则IPSP模块300确定一个或多个管理机构是否管理在这些位置中的任何一个中的资金转账，如在步骤806中所示。如果IPSP模块300确定一个或多个管理机构管理资金的转账，则IPSP模块300通知合适方(例如，顾客、商家和/或发行银行)资金的转账承受的一种或多种类型的规章，如在步骤808中所示。金融交易可能承受的规章的类型包括禁止转账(例如，在赌博是非法的州或地区中的赌博交易)或限制转账(例如，在限制打赌的资金数量州或地区中的赌博交易)。

ASP模块

图8示出根据本发明的各种实施例的ASP模块400的框图。尽管根据一个实施例，ASP模块400可以被配置为在ASP系统105上运行，但根据另一个实施例，如果IPSP没有与ASP签订合同提供记帐管理服务，它还可以被配置为在IPSP系统104上运行。

从步骤402开始，根据一个实施例，ASP模块400从IPSP系统104和收单银行系统106获得交易信息。从IPSP系统104获得的交易信息针对每个交易可以包括以下数据字段：(1)商家识别(“MID”)号，其由收单银行授予，以标识商家或商家的交易实体(例如，特定网站)；(2)交易的日期和时间；(3)顾客的姓名：(4)支付卡号或支付卡号的一部分(例如，最后四位数字)；(5)卡持有者的电子邮件地址；(6)交易的货币；(7)使用的支付卡的类型(例如，Visa、MasterCard或American Express)；(8)支付数量；(9)商家分配给交易的定单参考号；(10)授权代码，其是由发行银行生成的唯一代码，表明交易是否被授权；(11)交易的结算状态(例如，“100”代表完成的交易)；(12)“结算时间”，其是IPSP把结算请求发送到收单银行的时间；(13)卡持有者的街道和街道号；(14)卡持有者的城镇；(15)卡持有者的国家；(16)卡持有者的邮政编码；(17)起源交易参考，其在偿还请求的情况下成为被偿还的原先的交易的参考；(18)定单信息，商家如果他们愿意，可以使用它以包括更多关于交易的信息；(18)“地点参考”，其是商家的IPSP参考；(19)交易的类型，其可以包括授权的交易、退款交易和取消的交易(例如，被取消的交易，或在钱由发行银行转账到商家之前并且在结算请求从IPSP被发送到收单银行之后应商家的请求数量改变的交易)；和(20)唯一参考号(URN)，其唯一地识别在ASP系统105中的交易。根据本发明的一个实施例，该信息还可以被包括在从IPSP被发送到收单银行的结算请求中，以上参考图6中的步骤310对此进行了讨论，以下将参考图10A中的步骤1102和1104对其进行讨论。从收单银行系统106获得的交易信息可以包括从收单银行请求的资金总额，例如，每个商家在一批或多批中聚集的资金总额。

根据各种实施例，为了获取交易信息，ASP模块400可以访问其上张贴交易信息的安全网页(例如，由每个系统104、106保存的)并且把信息下载到ASP系统105中，通过另一类型的电子交易(例如，经由电子邮件或传真)或两者的组合接收交易信息。

在各种实施例中，在步骤402中获得的交易信息被存储在ASP系统105上，如在步骤404中所示，并且从IPSP系统104获得的信息与从收单银行系统106获得的信息相比较，如在步骤406中所示。在图8中所示的实施例中，步骤406被显示为在步骤404之后发生，但是在其它实施例中，这两个步骤可以同时发生或以相反的次序发生。

根据本发明的各种实施例，在比较步骤406中，ASP模块400识别由IPSP系统104提供的交易信息与由收单银行系统106提供的信息不匹配的任何交易。在一个实施例中，任何非匹配交易被标志并且在由ASP模块400生成的例外报告中被报告给商家、IPSP和/或收单银行，以下将参考步骤410更详细地对其进行讨论。在另一个实施例中，其中收单银行系统106把资金直接地转账到与每个商家相关联的、并且由IPSP 36和/或ASP35保存的账户，以下将参考图14对其进行讨论，ASP模块400还被配置为把由IPSP系统104和收单银行系统106提供的交易信息与被转账到每个商家账户的数量相比较。

在协调由IPSP系统104和收单银行106提供的交易信息之后，然后ASP模块400可以把在结算过程期间接收的支付数量分配给各种参与者，这在图8中的步骤408中被示出。支付数量可以包括，例如，支付给商家31、32、33的数量、欠IPSP 34、收单银行和ASP 35的佣金，和为每个商家31、32、33存储在循环储蓄委托账户41中的资金的百分比。例如，根据各种实施例，各种参与者可以要求把由商家31、32、33接收的资金的某个百分比作为他们与商家31、32、33的合同43、45、47、49中服务的支付。例如，收单银行36可以从收单银行37、38、39收费由商家31、32、33接收的资金的3％，卡组织可以收费使用他们的卡转账的资金的1％，IPSP 34可以收费与支付相关的服务的5％，以及ASP 35可以为它的记帐管理服务向IPSP 34收费由IPSP 34接收的钱的3％。如另一个例子，ASP 35还可以计算由IPSP 34招致的各种服务的临时花费，诸如卡验证、给各种参与者的佣金支付和针对接收的退款可由商家31、32、33收费的任何费用。

此外，根据各种实施例，金融交易系统100可以建立指定被用于资助循环储蓄委托账户41的资金的百分比的协议。例如，系统协议可以要求ASP模块400把要由每个商家31、32、33接收的资金的7.5％分配给每个商家31、32、33的循环储蓄委托账户。在另一个例子中，根据一个实施例，针对循环储蓄账户的指定的百分比可以被自动地增加或减少，依赖于为特定商家31、32、33接收的退款请求的数量。此外，根据一个实施例，ASP模块400监视并识别特定时间段(例如，六个月、一年或三年)保留在账户中的资金，并且在时间段的末尾重新把那些资金分配给商家31、32、33。此外，委托账户41在图1的实施例中作为ASP系统35的一部分被示出。然而，在其它实施例中，委托账户41可以处在或由银行或其它金融机构保持。

接下来，在步骤410中，根据各种实施例，ASP模块400被配置为为每个商家生成协调报告、或“建议通知书”。在一个实施例中，建议通知书提供给每个商家在特定时间段期间(例如，一天或一周)为商家处理的交易的摘要、在协调步骤406中创建的例外报告(如果需要)、分配给在步骤408中的各种参与者中的每个的支付的摘要、在特定时间段期间在委托账户中的活动的摘要和支付被转账到商家31、32、33的日期。在另一个实施例中，建议通知书的各个部分被包括在分开的报告中(例如，例外报告、支付分配报告和交易摘要报告)。以及，在另一个实施例中，ASP模块400被配置为根据由每个指定的特定的格式为IPSP 34和每个商家31、32、33生成一个或多个摘要报告。

在图8中所示的实施例中，ASP模块400还被配置为(1)为每个商家31、32、33把建议通知书发送到IPSP 34用于审批，这被示为步骤412，和(2)一旦从IPSP 34接收到建议通知书的批准，这被示为步骤414，把建议通知发送到商家31、32、33，这被示为步骤416。在其中IPSP 34没有与ASP签订提供记帐管理服务(未示出)的合同的另一个实施例中，步骤412和414可能不执行。

此外，根据本发明的各种实施例，ASP模块400被配置为准备和把支付发送到各种参与者和委托账户，如在步骤418中所示。步骤418可以包括，例如，物理地把支付(例如，支票或现金)发送到每个参与者，准备请求从与ASP系统105相关联的账户到与欠钱的各种参与者相关联的账户的电子资金转账(EFT)，或者两者的结合。此外，尽管支付步骤418被示为在图8中所示的实施例中的步骤416之后发生，根据其它实施例，ASP模块400可以被配置为与步骤416同时或在其之前执行支付步骤418。

在本发明的其它实施例中，ASP模块400还可以被配置为在发送支付到每个商家31、32、33之前扣留相关电子商业交易(例如，因特网赌博交易或零售购买)的本地或地区税。例如，在一个实施例中，ASP模块400可以被配置为基于居住地或每个顾客和/或商家的交易的地点应用使用的税或发证率，以及把资金直接地转账到相关税或发证机构。

特别地，图17示出在金融交易上所欠的任何税的示例性记帐过程。从步骤702开始，一种或多种税收管辖权的税的合适类型和对应的税率被存储在存储器24中。接下来，在步骤704，与在顾客和商家31、32、33之间进行的金融交易相关联的信息被接收。响应于接收与金融交易相关联的信息，识别出与金融交易相关联的一种或多种相关税收管辖权，如步骤706所示。接下来，在步骤708，查询存储器以确定与识别的税收管辖权相关联的一种或多种类型的税。如果一种或多种类型的税与识别的税收管辖权相关联，那么税的类型对应的税率被应用到金融交易以确定交易欠的税，这作为步骤710示出。此外，一旦确定交易欠的税，欠税的数量转账到相关税务机构，如步骤712所示。在各种实施例中，可以基于交易发起者(例如，商家)、顾客的位置和/或顾客从其下定单的计算装置的位置征税。

在各种实施例中，扣留的税的数量和支付给税务机构的数量被存储在一段时间段内具有交易信息的系统中，在某些实施例中，其允许审计跟踪。例如，在一个实施例中，应付款的数量被保存在指定的银行账户中，并被周期地(例如，每月、每周、每天或即时)支付给税务机构。在一个实施例中，应付款的数量经由电子资金转账(EFT)被支付给税务机构。

根据各种实施例，该税务记帐功能减轻了商家、顾客和税务机构的负担，并提供了有税交易的可信的记帐系统。此外，在一个实施例中，ASP模块400生成总结到期应纳税款和/或已征的税的、用于税务机构的记帐报告。

此外，在各种实施例中，交易记录可以被电子地或人工地通过ASP模块400进行审计。特别地，当交易通过系统被处理时，与每个交易相关联的唯一参考号(“URN”)被跟踪。例如，在一个实施例中，多个交易可以被分组成批处理文件并被发送到收单银行进行结算。ASP模块400在批处理文件中存储与每个交易相关联的URN以及识别批处理文件的信息，使得每个单独的交易可以独立地被审计。

C.示例性处理流程

授权处理流程

图9A示出根据本发明的各种实施例的处理授权请求的流程图100。在一个实施例中，授权请求的处理当顾客等待时在线发生，并且它通常花费两到二十秒进行处理。如果授权请求被发行银行接受，商家接受顾客的支付，并发行银行阻挡请求的数量超过与支付卡相关联的信用极限或余额。

根据本发明的各种实施例，授权请求处理1000在步骤1002通过商家31、32、33从顾客接收从顾客的支付卡到商家的账户的转账的请求开始。该请求可以包括，例如，转账的数量和顾客的信息和支付卡信息(假设商家不具有从之前的交易存储顾客的信息和支付卡信息)。在一个实施例中，顾客和支付卡信息可以包括顾客的全名和地址、顾客的电子邮件地址和支付卡号、有效日期和与支付卡相关联的任何其它识别信息。在一个实施例中，请求可以由商家的系统101、102、103接收，并被存储在其上。

接下来，在步骤1006中，根据本发明的各种实施例，商家31、32、33验证在顾客的请求中接收的信息的格式。在一个实施例中，如以上对于在图5和步骤204中所示的商家模块200讨论的，商家模块200验证支付卡号的格式是否是正确的，以及是否所有要求的字段都已经完成。

在步骤1006中验证完信息的格式之后，商家31、32、33把交易信息转移到IPSP34进行进一步处理，这被示为步骤1010。IPSP34接收并在IPSP系统104上存储交易信息，并且把收单银行36和发行银行37、38、39需要的信息转移到收单银行36以处理授权请求，如步骤1012所示。例如，根据本发明的各种实施例，该信息可以由IPSP模块300转移到收单银行系统106，并且可以包括支付卡号、支付数量和顾客的账单地址。

接下来，在步骤1014中，收单银行系统106接收并在收单银行系统106上存储授权请求。然后，在步骤1016中，收单银行系统106识别合适的卡发行商和发行银行，并把授权请求经由合适的卡发行商网络(例如，Visa、MasterCard或American Express网络)路由到发行银行。一旦接收到授权请求，发行银行系统107、108、109验证支付卡是可操作的和有效的，这被示为步骤1018，以及有足够的资金用于支付卡，这被示为步骤1020。一旦批准授权请求，发行银行系统107、108、109通过卡发行商网络把批准消息发送到收单银行系统106，示为步骤1022，而收单银行系统106接收批准消息并在步骤1024中把批准消息发送到IPSP系统104。然后，在步骤1026中，IPSP系统104接收并存储批准消息并把批准消息发送到发起授权请求的商家系统101、102、103。

根据各种实施例，以上参考图5讨论的初级欺骗检验和身份/年龄验证步骤(步骤204和206)可以由商家模块200与把授权请求信息从商家转移到IPSP的步骤1010同步、在其之前和在其之后执行。此外，根据本发明的各种实施例，执行欺骗阻止子模块350的步骤，这在图6中被示为步骤306，可以由IPSP模块300与把授权请求信息从IPSP转移到收单银行的步骤1020同步、在其之前和在其之后执行。

在本发明的另一个实施例中，在图13中示出，当被发送到商家系统101a、102a、103a和经由网络115a被发送到到IPSP系统104a时，顾客的信息被加密(例如，具有2048比特可变加密)。此外，IPSP模块300a执行欺骗阻止子模块350a的一个或多个欺骗过滤器，并且如果欺骗过滤器检测到潜在可疑活动，IPSP模块300a在发送授权请求到收单银行之前把欺骗检验的结果发送到商家用于审批，然后收单银行把请求发送到发行银行。在收单银行从发行银行接收授权消息之后，收单银行在收单银行系统106a(例如，数据库)的存储区域中存储交易信息并把授权消息发送到IPSP系统104a。IPSP模块300a把授权消息转发到商家，并可以在生成对于交易的结算请求之前在交易信息上执行一个或多个欺骗过滤器。

结算处理流程

图10A和10B示出根据本发明的各种实施例的处理结算请求的示例性流程图1100。根据各种实施例，结算请求是由收单银行(或代表收单银行的IPSP)生成的把钱从发行银行转账到收单银行用于支付给商家的请求。根据本发明的各种实施例，结算请求过程1100在步骤1102开始，其中IPSP系统104为每个商家31、32、33生成结算请求并且把结算请求在批处理文件中发送到收单银行36。在各种实施例中，每个结算请求包含在特定时间段期间(例如，24小时、48小时或一周)由IPSP34处理的交易的数据。根据本发明的各种实施例，结算请求可以包括授权的和未授权的交易或仅包括授权交易。接下来，根据本发明的各种实施例，在步骤1104中，IPSP系统104把结算请求存储在IPSP系统104上。结算请求可以通过从IPSP系统104的安全部分下载结算请求而被转移到ASP系统105，或者IPSP34可以发送结算请求的物理拷贝或电子拷贝到ASP35(例如，经由电子邮件、传真、CD、DVD或软盘)。根据本发明的各种实施例的结算请求的内容是以上参考图8进行讨论的。

如在步骤1106中所示，收单银行36接收批处理文件并把结算请求发送到合适的发行银行37、38、39。此外，收单银行36生成并存储用来总结被包括在每个发行银行37、38、39的每个结算请求中的资金数量(例如集合的资金数量)的用于ASP 35的支付报告，这作为步骤1108示出。由收单银行36为ASP 35生成的支付报告的一个实施例是以上参考图8进行讨论的。

然后，在步骤1110中，发行银行37、38、39把请求的资金转账到收单银行36。接下来，在步骤1112中，收单银行把接收的资金转账到IPSP 34。在IPSP 34(或ASP35)把资金分发到合适的参与者和委托账户之前，ASP系统105获取由IPSP系统104生成的结算请求和由收单银行36生成的支付报告，并在步骤1114中协调获取的信息。根据本发明的各种实施例，步骤1114中执行的协调的结果可以在协调报告(或“建议通知书”)中由ASP 35总结。最后，在步骤1116中，ASP 35组织每个参与者的支付和用于转账到委托账户的数量，并把支付转账到参与者和委托账户。

根据一个实施例，ASP模块400被配置为执行步骤1114和1116，这是在以上参考图8进行讨论的。例如，ASP模块400总结来自协调数据的结果，该数据由IPSP和收单银行在周期地(例如，每天或每周)被发送到每个商家31、32、33的协调报告中提供的。协调报告总结商家31、32、33可能希望在商家的银行账户中在特定的日期前接收的数量。此外，协调报告包括顾客放置在他们各自的商家账户中的总额，并且示出以下减免和增加：(1)减去佣金和费用(覆盖在支付链中的给所有参与者的支付)；(2)减去对应于特定时间段期间(例如，六个月或一年)在循环储蓄委托账户中作为保障退款和偿还安全而保留的总额的百分比的“信任减免”；(3)增加在某个时间段期间和建议通知的日期的前一天保留的“信任钱”；(4)减去任何由收单银行在关于之前交易的建议通知书的当天发送的任何退款。在把资金转账到合适的参与者和循环存储委托账户之前，IPSP 34回顾包括其上支付被表明为已支付的日期的协调报告。一旦接收IPSP 34针对协调报告的批准，ASP 35把协调报告发送到各种商家31、32、33，并且把支付转账到合适的参与者和委托账户。在一个实施例中，资金的转账可以在委托报告被生成并批准之后发生。在另一个实施例中，资金的转账可以在协调报告的批准之前发生。

根据在图14中所示的替代实施例，资金直接地由收单银行存入与每个商家(例如，SG1、SG2、SG3等)相关联的每个公司实体的账户中。此外，ASP模块400a还被配置为用于协调接收到每个具有结算请求的账户的数量和从IPSP和收单银行分别获得的支付报告。在一个实施例中，没有从账户支付给各种参与者或委托账户的任何数量被支付给商家

退款处理流程

退款请求是由发行银行代表顾客发起的请求偿还特定费用到顾客的支付账户的请求。例如，发行银行可以响应顾客争辩在顾客的支付卡上的费用：顾客声称没有被顾客授权，而发起退款请求。图11示出根据本发明的各种实施例的处理退款请求的示例性流程图1200。

在步骤1202开始，发行银行37、38、39接收来自顾客的退款请求。然后，在步骤1204，发行银行37、38、39把退款请求发送到收单银行。在步骤1206中，收单银行36接收退款请求并且把它发送到IPSP 34。接下来，在步骤1208，IPSP 34比较退款请求和来自原始交易的数据。如果退款请求中的数据显示与来自原始交易的数据匹配，在步骤1210中，IPSP 34把请求发送到ASP 35。根据如上所述的本发明的各种实施例，比较和发送步骤1208和1210可以由IPSP模块300执行。接下来，在步骤1212中，根据本发明的各种实施例，ASP35把退款数量从商家的委托账户转发到收单银行36，然后收单银行把退款数量转发到发起退款请求的发行银行37、38、39。在替代实施例中，ASP 35在结算请求中通过把它从应该支付给商家31、32、33的总额中扣除而把退款数量支付给发行银行37、38、39。然后，在步骤1214，ASP 35存储退款请求。在本发明的各种实施例中，ASP模块400被配置为执行步骤1212和1214。

根据本发明的一个实施例，如果在步骤1208中退款请求数据与来自原始交易的数据不匹配，则退款请求可以被标志。此外，如果标志的与特定支付卡相关联的退款请求的数量在特定时间段内(例如，一周或一个月内两次退款请求)超出某个数量，则IPSP可以把特定的支付卡号包括在商家在将来不应该接受支付的支付卡的列表上(例如，在由IPSP 34保存的欺骗和滥用数据库中)。

除了上述的以外，根据各种实施例，ASP 35协调由收单银行36和IPSP 34在特定时间段期间(例如，每天或每周)处理的退款请求与来自原始交易的交易数据。为了协调请求，ASP 35获取由收单银行36生成的退款交易报告和由IPSP 34生成的退款交易报告，并且把这两个报告和来自原始交易的数据比较，如步骤1216所示。在一个实施例中比较步骤1216通过链接在退款报告中的数据和来自已经被存储在ASP系统105的存储器中的原始交易的数据而被执行。根据一个实施例，退款数据报告包含以下信息的至少一部分：(1)参考被退款的原始交易；(2)MID号；(3)提出退款请求的日期；(4)作为“退款”的交易的描述；(5)完全的卡号；(6)由收单银行担保的参考号；(7)“原因代码”，由卡发行银行发出的、表明卡持有者发起退款的原因的代码号；(8)发起退款的原因的描述；(9)退款数量的货币类型；(10)退款数量；(11)收单银行提供的卡号或部分卡号(例如，卡号的头四位数字)；(12)原始交易被“张贴”或被授权的日期；(13)原始交易发生的日期；(14)原始交易的“类型”；(15)原始交易的货币；(16)原始交易的数量；(17)交易结算的货币；(18)结算的数量；(19)收单银行提供的原始的“默认”货币；(20)收单银行提供的原始“默认货币”数量；(21)“原始单”，是“批处理”交易的参考，交易是当收单银行把它的关于特定日期的交易释放给IPSP时的一部分；(22)收单银行的“项目单”；(23)原始交易的授权代码；(24)收单银行的“批处理号”；和(25)“商家DBA名称”，其是商家显示在顾客的支付卡声明上的名称。如以上参考图8描述的，根据本发明的各种实施例，ASP模块400可以被配置为执行协调步骤1216。

根据本发明的各种实施例，报告可以被张贴到IPSP系统104和收单银行系统106上，并且由ASP系统105下载，或者报告可以物理地或电子地经由例如电子邮件、传真、CD、DVD或软盘被发送。

支付处理流程

在某些电子商业部门(例如，赌博)，钱可能需要退还给顾客。支付给钱可能引起洗钱滥用的风险的担忧，特别是对于因特网赌博。根据本发明的各种实施例，系统100通过专门地给由顾客使用以进行给商家的原始支付的支付卡账户支付，在顾客和商家之间创建完全透明的“封闭环”，而解决了某些与电子商业交易相关联的风险。因此，根据一个实施例，资金起源于并流回相同账户，并且所有的资金流动是可跟踪的，这使电子商业对于洗钱计划没有吸引。

例如，图12示出当顾客提交支付请求时处理和发送支付给顾客的示例性流程1300。从步骤1302开始，商家从顾客接收支付的请求，并把请求发送到IPSP。接下来，在步骤1304中，IPSP验证顾客没有被包括在政府或本地机构制裁列表(例如，由U.S.公开的“SpeciallyDesignated Nationals list”)上。此外，根据一个实施例，IPSP验证顾客的国籍(例如，基于顾客的账单地址或顾客计算装置的IP地址)不是在其中商家可以进行交易的被禁止的国家的列表上。根据各种实施例，如果顾客(或顾客的国家)在列表上，支付请求不能够由系统100处理，并且请求被拒绝。如果顾客没有被包括在制裁列表上(或没有与被禁止国家相关联)，IPSP 34把支付请求发送到商家的银行，这被示为步骤1306。响应于接收请求和验证支付资金在商家的账户中，商家银行把资金发送到IPSP 34，这被示为步骤1308。在IPSP 34已经接收资金并在IPSP系统104中存储它们的记录之后，IPSP 34把资金转账到收单银行36，如在步骤1310中所示。接下来，在步骤1312中，一旦接收资金，收单银行36把资金发送到与顾客的、用于在商家的网站上进行购买(例如，下赌注)的支付卡相关联的发行银行37、38、39。根据各种实施例，在步骤1314中，然后针对从商家31、32、33接收的数量，发行银行37、38、39可以相信与支付卡相关联的账户，或者发行银行37、38、39可以发送支票给被列为卡持有者的顾客。

电子钱包

在本发明的另一个实施例中(未示出)，金融交易系统100被配置为允许顾客从IPSP 34购买电子代币，然后这可以被用于与参加商家31、32、33商定价格，创建预付的“电子钱包”账户。根据各种实施例，金融交易系统100的特征可延伸到电子钱包系统。例如，IPSP34接收把资金从顾客的电子钱包账户转账到IPSP的账户的请求，而不是商家31、32、33从顾客接收把资金从与顾客的支付卡相关联的账户转账到商家的账户的请求。根据一个实施例，IPSP 34执行商家模块200和IPSP模块300生成并处理与发行银行的授权和结算请求的步骤。一旦结算，IPSP 34把代表转账的资金的数量的电子代币的数量存入顾客的电子钱包账户。顾客可以使用代币和同参与商家31、32、33进行购买。周期地(例如，每天或每周)，IPSP 34把代表在每个商家的网站花费的代币的数量的资金转账到每个商家31、32、33。在一个实施例中，ASP 35管理电子钱包账户并且把支付从IPSP 34分配给参与商家31、32、33。

在得到上述的描述和相关联的附图中呈现的指导的好处后，本发明的许多修改和其它实施例将出现在本发明属于的技术领域的技术人员的脑海中。因此，应该理解本发明不限于公开的特定实施例，以及修改和其它实施例打算被包括在附加的权利要求的范围内。尽管这里使用了特定的词语，但它们仅在一般的和说明的意义上被使用，而不是为了限制的目的。

Claims (60)

1.一种用于处理和在线商家进行的金融交易的系统，所述系统包括：

支付服务提供商模块，其被配置为：

接收把资金从顾客账户转账到在线商家的请求，所述请求包括与所述顾客的地址相关联的第一位置和生成所述请求的计算装置的第二位置；

响应于接收所述请求，把所述第一位置、所述第二位置和所述在线商家的位置与管理资金转账到所述在线商家的位置的列表比较；

响应于所述第一位置、所述第二位置或所述在线商家的位置匹配于在所述位置的列表上的位置，确定一个或多个管理机构管理在所述第一位置、还是在所述第二位置、还是在所述线商家的位置处资金从所述顾客账户到所述在线商家的转账；和

响应于确定所述一个或多个管理机构管理在所述第一位置、所述第二位置或所述在线商家的位置处到所述在线商家的所述资金转账，通知所述顾客、所述商家或与所述顾客的账户相关联的银行中的一个或多个，所述顾客的账户与所述资金的转账承受的一种或多种类型的规章的金融交易相关联，

其中所述一种或多种类型的规章包括转账的禁止、转账的限制或转账税中的一个或多个。

2.如权利要求1中所述的系统，其中所述第二位置与被发到生成所述请求的计算装置的因特网协议地址相关联。

3.一种用于处理与在线商家进行的金融交易的系统，所述系统包括：

支付服务提供商模块，其被配置为：

接收在顾客账户和在线商家之间进行金融交易的请求，所述请求包括与所述顾客的地址相关联的第一位置和生成所述请求的计算装置的第二位置；

响应于接收所述请求，把所述第一位置、所述第二位置和所述商家的所述位置和管理与所述在线商家进行的金融交易的位置的列表进行比较；

响应于所述第一位置、所述第二位置或所述商家的位置匹配在所述位置的列表上的位置，确定一个或多个管理机构管理在所述第一位置、还是在所述第二位置、还是在所述在线商家的位置处与所述在线商家进行的金融交易；和

响应确定所述一个或多个管理机构管理在所述第一位置、所述第二位置或所述商家的位置处的金融交易，通知所述顾客、所述商家或与顾客的账户相关联的银行中的一个或多个，所述顾客的账户与所述金融交易承受的类型的规章的金融交易相关联。

4.如权利要求3中所述的系统，其中所述支付服务提供商模块还被配置为用于响应于确定所述一个或多个管理机构管理在所述第一位置、所述第二位置或所述在线商家的位置处与所述在线商家进行的金融交易，阻止与所述商家进行所述金融交易。

5.如权利要求3中所述的系统，其中所述支付服务提供商模块还被配置为用于响应于确定所述一个或多个管理机构管理在所述第一位置、所述第二位置或所述在线商家的位置处与所述在线商家进行的金融交易，通知所述在线商家或与所述顾客的账户相关联的所述银行中的一个或多个。

6.如权利要求3中所述的系统，其中所述金融交易是对于与所述在线商家进行赌博的请求。

7.如权利要求3中所述的系统，其中所述金融交易是把资金转账到所述在线商家的请求。

8.如权利要求3中所述的系统，其中所述金融交易是由于一个或多个与所述在线商家的赌博造成的支出的请求。

9.一种用于与在线商家进行的金融交易的税务记帐系统，所述系统包括：

存储器，被配置为存储一种或多种类型的税和一个或多个税收管辖权的对应的税率；

处理器，被配置为：

从顾客接收与和在线商家进行的金融交易相关联的信息；

响应于接收与所述金融交易相关联的所述信息，识别与所述金融交易相关联的一个或多个税收管辖权；

响应于识别与所述金融交易相关联的所述一个或多个税收管辖权，查询所述存储器以确定一种或多种类型的税是否与所述一个或多个税收管辖权相关联；

响应于确定一种或多种类型的税与所述一个或多个税收管辖权相关联，把所述一种或多种类型的税中的每一种的所述对应税率应用到与所述金融交易相关联的信息以确定所欠税的数量；和

响应于确定所述所欠税的数量，把所述所欠的税的数量转账到一个或多个相关税务机构。

10.如权利要求9中所述的税务记帐系统，其中所述一个或多个税收管辖权与所述在线商家的位置、所述顾客的位置或所述顾客使用的计算装置的位置中的一个或多个相关联，以进行所述金融交易。

11.如权利要求9中所述的税务记帐系统，其中所述处理器还被配置为用于经由电子资金转账把数量转账到一个或多个相关税务机构。

12.如权利要求9中所述的税务记帐系统，其中所述处理器还被配置为用于把所欠税的数量和转账到一个或多个相关税务机构的数量和所述金融交易信息一起在特定时间段内存储在存储器中。

13.如权利要求12中所述的税务记帐系统，其中所述处理器还被配置为用于为一个或多个相关税务机构中的每个生成记帐报告，所述记帐报告包括欠所述相关税务机构的税的数量，转账到所述相关税务机构的税的数量，和与其中税被支付给所述相关税务机构的所述金融交易相关联的信息的至少一部分。

14.一种用于处理与在线商家的金融交易的系统，所述系统包括：

支付服务提供商模块，其被配置为用于：

接收把资金从顾客账户转账到在线商家的请求；

响应于接收所述转账资金的请求，把要被支付给所述在线商家的所述资金的至少一部分分配给委托账户；和

响应于把要被支付给所述在线商家的所述资金的至少一部分分配给委托账户，在小于预定时间段内或直到退款请求或偿还请求由所述系统接收之前，把所述资金的所分配的部分存储在所述委托账户中。

15.如权利要求14中所述的系统，其中所述支付服务提供商模块还被配置为用于为每个在线商家周期地生成协调报告，所述协调报告列出已经接收的转账请求和已经被分配给所述位图账户的资金的一部分。

16.如权利要求14中所述的系统，其中所述请求从与所述支付服务提供商模块在网络上通信的商家计算装置被接收。

17.如权利要求14中所述的系统，其中所述系统还包括被配置为把一个或多个欺骗过滤器应用到所述请求的欺骗阻止模块，所述一个或多个欺骗过滤器从以下的一个或多个进行选择：

(1)把与顾客账户相关联的第一位置和与用于发送请求到所述在线商家的顾客计算装置相关联的第二位置相比较，并且响应于所述第一位置位于所述第二位置的第一预定可接受距离之外，把所述请求标记为潜在的欺骗；

(2)把与顾客电子邮件地址相关联的第三位置和所述第二位置相比较，并且响应于所述第三位置位于所述第二位置的第二预定可接受距离之外，把所述请求标记为潜在的欺骗；

(3)把与顾客账户的顾客账单地址相关联的第四位置和所述第二位置相比较，并且响应于所述第四位置位于所述第二位置的第三预定可接受距离之外，把所述请求标记为潜在的欺骗；

(4)把顾客标识和禁止进行金融交易的个人的列表相比较，并且响应于所述顾客标识匹配于在列表上的一个个人，把所述请求标记为潜在的欺骗；或者

(5)把顾客账户的标识与被禁止进行金融交易的账户的列表比较，并且响应于所述顾客的标识匹配于在所述列表上的一个账户，把所述请求标记为潜在的欺骗。

18.如权利要求14中所述的系统，其中所述支付服务提供商模块还被配置为：

接收之前从所述顾客账户转账到所述商家的资金退款请求；和

响应于接收所述退款请求，从被存储在委托账户中的资金资助退款请求。

19.如权利要求14中所述的系统，其中所述支付服务提供商模块还被配置为：

接收之前从所述顾客账户转账到所述商家的资金偿还请求；和

响应于接收所述偿还请求，从被存储在委托账户中的资金资助偿还请求。

20.一种用于处理从顾客接收的退还请求的系统，所述系统包括：

用于为商家建立委托账户的装置，所述委托账户由要从一个或多个与特定顾客相关联的账户支付给所述商家的资金的一部分提供资助；

用于接收之前从与特定顾客相关联的账户支付给所述商家的退还支付请求的装置；和

用于使用被存储在所述委托账户中的资金资助所述退还请求的装置。

21.如权利要求20所述的系统，还包括用于响应于一部分资金在特定时间段中被存储在所述委托账户，把该资金转账到所述商家的装置。

22.如权利要求20所述的系统，还包括用于响应于一部分资金在至少六个月中被存储在所述委托账户，把该资金转账到所述商家的装置。

23.如权利要求20中所述的系统，还包括：

用于响应于在特定时间段期间所述商家接收减少数量的退还请求，减少要由所述商家支付到委托账户中的资金的一部分的装置；和

用于响应于在所述特定时间段期间所述商家接收增加数量的退还请求，增加要由所述商家支付到委托账户中的资金的一部分的装置。

24.如权利要求20中所述的系统，其中所述用于资助退还请求的装置包括用于无争论地资助所述退还请求的装置。

25.如权利要求20中所述的系统，其中所述商家是在线商家。

26.如权利要求20中所述的系统，还包括用于把一个或多个欺骗过滤器应用到所述退还请求上的装置，所述一个或多个欺骗过滤器被配置为用于识别潜在的欺骗的退还请求。

27.如权利要求26中所述的系统，其中所述一个或多个欺骗过滤器由在计算机可读介质上的欺骗阻止模块执行。

28.如权利要求20中所述的系统，其中所述退还请求是退款请求。

29.如权利要求20中所述的系统，其中所述退还请求是偿还请求。

30.一种处理从顾客接收的退还请求的系统，所述系统包括：

用于接收对于之前用与顾客相关联的账户对商家作出的支付的退还请求的装置；和

用于无争议地用被存储在与所述商家相关联的账户中的资金资助顾客的退还请求的装置。

31.如权利要求30中所述的系统，其中所述退还请求是退款请求或偿还请求。

32.如权利要求30中所述的系统，其中所述退还请求从持有与所述顾客相关联的账户的金融机构接收。

33.如权利要求32中所述的系统，其中所述退还请求的资金被支付给持有与所述顾客相关联的账户的金融机构。

34.一种用于为在线商家识别从顾客接收的潜在的欺骗在线金融交易的系统，所述系统包括欺骗阻止模块，被配置为：

对从一个或多个顾客接收的一个或多个金融交易中的每个金融交易应用一个或多个欺骗过滤器，所述一个或多个欺骗过滤器从以下一个或多个选择：

(1)把与顾客账户相关联的第一位置和与用于发送所述金融交易到所述在线商家的顾客计算装置相关联的第二位置相比较，并且响应于所述第一位置位于所述第二位置的第一预定可接受距离之外，把所述金融交易标记为潜在的欺骗；

(2)把与所述顾客账户的顾客账单地址相关联的第四位置和所述第二位置比较，并且响应于所述第四位置位于所述第二位置的第三预定可接受距离之外，把金融交易标记为潜在的欺骗；

(3)把顾客标识和被禁止进行金融交易的个人的列表比较，并且响应于所述顾客标识匹配于在列表上的一个个人，把所述金融交易标记为潜在的欺骗；或

(4)把顾客账户的标识与被禁止进行金融交易的账户的列表比较，并且响应所述顾客账户的标识匹配于在列表上的一个账户，把所述金融交易标记为潜在的欺骗；以及响应于所述金融交易标记为潜在的欺骗，把与所述金融交易相关联的信息存储在欺骗数据库。

35.如权利要求34中所述的系统，其中一个或多个欺骗过滤器还包括：把与顾客电子邮件地址相关联的第三位置和所述第二位置比较，并且响应于所述第三位置位于所述第二位置的第二预定可接受距离之外，把所述金融交易标记为潜在的欺骗。

36.如权利要求34中所述的系统，其中所述一个或多个欺骗过滤器还包括：把与一个或多个随后金融交易相关联的信息和被存储在所述欺骗数据库中的金融交易比较，并且响应于所述一个或多个随后金融交易中的每个金融交易的顾客账户、顾客标识或顾客账单地址匹配于被存储在所述欺骗数据库中的金融交易的任何一个，把所述一个或多个随后的金融交易标记为潜在的欺骗。

37.如权利要求34中所述的系统，其中所述一个或多个欺骗过滤器还包括：把所述第一位置和所述第三位置比较，并且响应于所述第一位置位于所述第三位置的第一预定可接受距离之外，把所述金融交易标记为潜在的欺骗。

38.如权利要求34中所述的系统，其中所述第二位置包括国家，以及所述一个或多个欺骗过滤器还包括：把所述第二位置和被禁止与所述商家进行金融交易的国家的列表比较，并且响应于第二位置在国家的列表上，阻止金融交易进行。

39.如权利要求34中所述的系统，其中被禁止进行金融交易的账户的列表是被窃账户的列表。

40.如权利要求34中所述的系统，其中所述第一位置是与管理所述顾客账户的金融机构相关联的位置。

41.如权利要求34中所述的系统，其中所述第一位置是与所述顾客账户相关联的账单地址。

42.如权利要求34中所述的系统，所述第一位置、所述第二位置、所述第三位置和所述第四位置从国家、区域、州、地区、县、城市或者由一个或多个邮政编码限制的邮政区域中的一个或多个选择。

43.如权利要求34中所述的系统，其中所述个人的列表被政府机构禁止。

44.如权利要求34中所述的系统，其中所述账户的列表被政府机构禁止。

45.如权利要求34中所述的系统，其中：

所述支付服务提供商模块还被配置为为顾客接收退还请求；和

所述欺骗阻止模块还被配置为用于把请求退还的顾客的身份和与所述在线商家相关联的职员、主管或业主的列表比较，并且响应于所述顾客在职员、主管或业主的列表上，把所述退还请求标记为潜在的欺骗。

46.如权利要求34中所述的系统，其中所述金融交易是赌博支出请求，并且所述欺骗阻止模块还被配置为用于把由顾客命名的用于从商家接收支出的账户的标识和由与商家打赌的顾客使用的商家账户比较，并且响应于用来接收支出的账户的标识不匹配于用于与商家打赌的账户的标识，把支出请求标记为潜在的欺骗。

47.如权利要求46中所述的系统，其中所述欺骗阻止模块还被配置为用于阻止在所述支出请求中提供的支出数量被转账到用来接收所述支出的所述账户。

48.如权利要求46中所述的系统，其中所述用来接收所述支出请求的账户与第一支付卡相关联，以及用于与商家打赌的账户与第二支付卡相关联，以及所述欺骗阻止模块还被配置为用于把所述第一支付卡和所述第二支付卡比较，并且响应所述第一支付卡不匹配于所述第二支付卡，把所述支付请求标记为潜在的欺骗。

49.如权利要求34中所述的系统，其中所述一个或多个欺骗过滤器基于所述商家的位置被选择。

50.如权利妖气34中所述的系统，其中所述一个或多个欺骗过滤器基于所述第二位置被选择。

51.如权利要求34中所述的系统，其中所述一个或多个欺骗过滤器基于所述第一位置被选择。

52.一种用于监视顾客的强制花费行为的系统，所述系统包括处理器和存储器，所述处理器被配置为用于：

在所述存储器中存储与一个或多个来自顾客的与商家进行金融交易的请求相关联的信息，所述信息包括一定数量的资金；

接收与商家进行金融交易的新请求，所述请求包括一定数量的资金；

响应接收新请求，提取被存储在所述存储器中的资金总额；

把资金总额的总数量和在新请求中的资金的数量与预定的可接受的极限比较；和

响应于超出所述预定的可接受极限的总数量，通知所述顾客、与所述顾客相关联的支付源或所述商家中的一个或多个：预定的可接受极限已经被超过。

53.如权利要求52中所述的系统，其中被存储在所述存储器中的信息还包括每个请求被商家接收的日期；以及其中所述处理器还被配置为把在特定时间段内被存储在所述存储器中的资金总额和在新请求中的具有预定的可接受极限的资金数量相比较。

54.一种用于监视顾客的强制赌博行为的系统，所述系统包括处理器和存储器，所述处理器被配置为用于：

在所述存储器中存储与一个或多个来自顾客的与商家进行金融交易的请求相关联的信息，所述信息包括一定数量的资金和金融交易的类型；

接收与商家进行金融交易的新请求，所述请求包括一定数量的资金和金融交易的类型；

响应于接收新请求，为在所述新请求中的金融交易的类型提取存储在所述存储器中的资金总额；

把资金总额的总数量和在新请求中的资金的数量和与在所述新请求中的金融交易的类型相关联的预定的可接受的极限比较；和

响应于超出所述预定可接受极限的总数量，通知所述顾客、与所述顾客相关联的支付源或所述商家中的一个或多个：预定的可接受极限已经被超过。

55.如权利要求54中所述的系统，其中所述交易的类型是把资金从与顾客相关联的账户转账到商家的请求。

56.如权利要求54中所述的系统，其中所述交易的类型是使用之前转账到商家的资金进行打赌的请求。

57.如权利要求54中所述的系统，其中所述一个或多个请求和新请求由与商家相关联的计算装置通过网络从一个或多个与顾客相关联的计算装置被接收。

58.如权利要求54中所述的系统，其中处理器还被配置为用于响应于总数量超出所述预定可接受极限，阻止所述新请求被处理。

59.如权利要求54中所述的系统，其中被存储在所述存储器中的信息还包括请求被商家接收的日期；和其中所述处理器还被配置为用于把在特定时间段内由顾客请求的资金总额和在所述新请求中的资金数量的和值与所述预定的可接受的极限相比较。

60.一种用于监视顾客的强制花费行为的系统，所述系统包括处理器和存储器，所述处理器被配置为用于：

在所述存储器中存储与一个或多个把资金从顾客转账到商家的请求中的每个请求相关联的信息，和所述请求被商家接收的日期；

接收转账资金到商家的新请求；

响应于接收新请求，在特定时间段内提取被存储在所述存储器中的资金总额；

把交易的资金总额的总数量和预定的可接受的极限比较；和

响应于交易总额超出所述预定的可接受极限，通知所述顾客、与所述顾客相关联的支付源或所述商家中的一个或多个：预定的可接受极限已经被超过。

Images