错误地放在庇护所时，您如何说服您理智的人呢？ 直截了当地说出您的理智或者您无意去那里，因为很多人都这么想，很多人都说这是错的，这很可能是行不通的。
经过多次失败的尝试来证明自己的理智之后，您可能会发现自己无法保持镇定自若，脾气暴躁，冷嘲热讽，并且推理，现在已经多次向几个人重申，似乎有些古怪。 当这些人后来离开您时，他们可能会发现您向一个人解释的内容与另一个人的解释有所不同，细节被遗漏或术语被更改，如果您在那里填补空白，则可以，但是您不是因此，他们的最初诊断是正确的，您可能并不理智。
上面的内容意味深长，比喻我在尝试解决我们为组织站点集成新的付款方式时遇到的问题时的感受。 付款方式是一种移动钱包，旨在成为我们要引入该网站的众多不同付款机制中的第一种，因为随着逻辑的发展，人们可以使用更多付款方式支付更多的款项，因此我们希望能收到更多款项。
如果将这种支付方式介绍给利益相关者和开发人员，那么将很难集成，我们的支付发行商已经将其作为附加组件提供！ 启用它，发送令牌和bada-bing bada-boom，我们现在接受这些移动钱包付款。
这种虚假承诺的刺痛导致从该项目中学到了很多教训：在对时间或精力做出任何假设之前，应由软件开发人员/与软件开发人员一起研究软件集成。 提出的虚假缓和是由于付款方式公司的销售人员与我们组织的经理进行了会谈，并且确定的结果已被所有人真诚接受。
忽略的第一个障碍是集成不仅在页面*中包含了几段JavaScript代码*，而且还要求服务器和付款方式之间进行TLS握手以验证会话。
*当然，一旦您设置了开发者帐户，将自己注册为商人，设置并验证了您的域后，就可以了。
考虑移动钱包支付如何在没有这样的步骤的情况下会如何工作，当然会让您意识到，这不可能实现，您需要先验证商家的身份，然后才能安全地进行支付，但是集成中的这一步骤似乎是可行的排除在销售范围之外，而是强调了从文档轻松复制/粘贴JS代码的便利，以支持完整的端到端入门。 更加令人沮丧的是，除了商户身份证明书之外，我们找不到（也许可能有所改善）除了我们的商户身份证明书之外，我们还需要支付方式供应商使用哪些证明书，我们需要证明他们的信用，他们在2天之内做出了回应。
开始使用此验证服务的时间比预期的要晚，这意味着在剩下的sprint中，从事该服务的后端开发人员休假的时间才刚刚开始，因此您的确成为了sprint的继承者。这项工作（我自己选择，我不想假装自己不愿意接受定时炸弹）。 通过验证服务的编写和工作，支付方式供应商成功地吐出了代币，我们可以将其传递给发行人。
头晕！ 我们终于到了容易的部分，现在我们要做的就是将令牌发送给发行人，我们就可以成功付款吗？ 错误。 因此，事实证明，付款方式供应商使用沙箱帐户生成的令牌没有被我们的付款发行人沙箱接受为有效令牌，这就是我开始问“我是否理智”的时候吗？ 我仔细阅读了文档，看我哪里可能出错了，将它们与集成文档中的示例请求一起构造的JSON请求逐行进行了比较，可惜我看不到问题。 在这一点上，我认为我所能做的就是向付款发行人出票，向他们提供我的发现，并希望他们能告诉我我错了。
当您去看医生以为您生病时，最好是犯错并确定自己的健康状况，或者被告知“是的，您实际上生病了，您有虫子”？ 我个人认为我更喜欢后者，特别是如果我感到恶心使我无法健康地做我应该做的事情时，但在这种情况下，发行人又回来说他们也找不到原因一切都失败了，但是他们所关心的不是沙盒不一致，而是为什么我们切换到实时终端上使用真实的移动钱包也失败了，尽管有不同的消息。
这时我被告知，他们已经提出了一份内部调查票，以进一步调查这件事，正是由于这一点，我意识到我已经被送进了庇护所，假设我做错了什么，所以我结束了正在研究交互的缺陷，这就是为什么直到他们对我的研究结果完全精疲力尽之后，他们才决定研究自己的系统。 在组织中的利益相关者之间进行了两周或更长时间的反复交流之后，我和自己终于被告知他们发现了问题。 事实证明，我们的帐户是在这样的时间和/或方式下设置的，以至于仅仅启用这种新的付款方式是不够的，并且需要“数据修复”以便我们使用它，这是针对接下来的星期一（我从来没有发现“数据修复”是什么意思，我真的希望自己有这个意思，但是这时我进入了不稳定的阶段，因此花更少的时间思考这个问题就更明智了）。
星期一临近，真相的时刻到了。 我进入了测试环境（配置为提交实时付款），然后继续使用移动钱包进行付款，因为我一直盯着服务器日志（到目前为止，我已经为请求的几乎每一步都添加了调试打印输出）生命周期），我的心下沉了一下，虽然我没有收到付款请求的错误，但是却看到付款被标记为失败/拒绝。
就在我与公司支持人员通电话的时候，我进入了庇护的短暂阶段，有人建议在他们拿出调查票之前，我应该先向银行查询我是否能够进行手机钱包付款。 这种多余的先决条件检查的荒谬之处使我简短地说：“不，那很愚蠢，您将要出票并进行调查”。 我知道我有能力做很多次付款，一次又一次感觉到这是另一次告诉我必须证明自己理智的事情。
我决定跟进一个关键的细节，希望对他们的调查有所帮助，因为我发现我的银行最初已授权这些付款，因为我收到通知后告诉我，所以后来被拒绝，所以看来像这样是作为后处理步骤而不是前处理或核心处理步骤发生的。 我不知道这是否有帮助，但是一旦发现问题，就会更加清楚为什么会发生这种情况。
地址验证服务（AVS）是一种防欺诈机制，用于信用卡和借记卡，以确保收款人输入的地址与该收款人的银行在其帐户中列出的地址匹配。 当付款发行人首次收到卡付款请求时，他们随后向银行提出请求以请求批准，并且银行对是/否以及有关收款人的一些其他信息（包括其地址详细信息）做出响应，我们的付款发行人将进行其他后处理实施AVS检查的模块，其安全设置可以在每个站点代码的基础上进行配置，因此您可以关心完整地址是否匹配，仅邮政编码匹配还是根本不匹配（还有其他匹配项，但我不记得了） 。 作为一个组织，我们当然会尽可能地减少卡支付欺诈行为，因此，AVS设置和实施我们的站点代码都已到位。
现在，当您第一次在移动钱包中注册支付卡时，会进行AVS支票，因此，如果您输入的地址与银行记录不符，则您将无法将该卡添加到您的钱包中，如果可以，因此当银行收到批准移动钱包交易的请求时，它可以与付款方式提供商核实该请求是否合法，并授权付款，而无需将地址详细信息传递给付款发行人，因为到目前为止它不需要这样做由于银行担心，AVS已很满意，可以将卡链接到钱包。 这对我们而言意味着，由于我们在网站代码上进行了AVS检查，因此无法进行手机钱包付款，这当然不是我们不愿意妥协的事情，为什么我们必须制定我们的标准卡支付的安全性较弱，无法使用手机钱包吗？
最初，我要求我们的支付发行商给我们选择区分标准卡支付和移动钱包支付的方法，这样我们就不必让移动钱包支付因其多余的AVS支票而失败，并被告知他们正在研究错误修复程序取而代之的是AVS模块，因此我们不需要永久地执行此操作，但是他们会临时设置它，因此到这一点为止我们已经有将近几个月的时间了，因此我们将不再受到阻碍。 生成了一组新的站点代码，专用于移动钱包付款，这些代码无需进行AVS支票。我更新了代码，并大声呼喊哈利路亚，因为我们终于完成了付款并可以开始生产。
我不确定接下来的几周会发生什么变化，但是我发现自己正在接近2018年末的时候打电话给公司支持人员及其管理层，他们被告知打算暂时解决的问题现已视为永久解决方案。 这对我来说很合适，但我确实对他们公司中可怜的开发人员感到奇怪，他们可能不得不在重构之前就重构了这个旧模块，并声明他们没有错误修复，这不是错误， AVS不应与手机钱包支付相抵触，并且可能与此类似。
所有这一切中最大的时刻是我组织的一个利益相关者问了一个简单的问题“为什么花了这么长时间？”，付款发行人的经理对他的绝对功劳表示敬意，解释说他们采取了这种方法。从一开始的调查就存在缺陷。 他们通常认为客户做错了事，正是由于这种想法导致他们陷入困境，才最终在自己的帐户设置和管理中找到真正的问题，这是他们的错。
让这个录取通知了我周围所有的人，我有些怀疑，他们感到同样（时间延迟是我的错）太宣泄了，我觉得我终于证明我很理智，每个人都同意并且那种感觉真是欣喜若狂。
我从整个项目中学到了很多有关付款发行人和银行之间如何交互以及可以采用哪些安全机制进行支付的课程，甚至还学到了一些可以用于软件开发的更好方法的课程但最重要的是，我了解到毅力可以回报并证明您理智。
