上周，一家工业润滑油在线商店的店主写信给我。一名男子销售机油、液压油、防冻剂等需要运送到俄罗斯各地的重型大件货物。他是这样说的：他的网站上有五个独立的交付插件。一张用于 SDEK，一张用于 Boxberry，一张用于 Business Lines，另一张用于 Russian Post，最后一张用于 KIT。每个插件每年的费用从三到一万卢布不等。每一项都按照自己的时间表进行更新。每个都有自己的设置界面。于是他坐下来思考——真的不可能在一个地方完成所有工作吗？这样买家在结帐时就可以立即看到所有送货选项，并可以在地图上选择一个提货点，而不必挖掘无休止的单选按钮？
我听了他的话，意识到这并不是一个独特的情况。这是俄罗斯几乎每个 WooCommerce 店主都面临的痛苦。而且商店越大，这种痛苦就越剧烈。因为五个插件不仅仅是五个订阅。这是五个潜在的失败点。五个不同的开发团队可能会放弃他们的产品或发布破坏与最新版本 WordPress 兼容性的更新。结账台上有五种不同风格的展示，它们彼此不一致，给买家一种网站是由胶带上的碎片组装而成的感觉。
当我们为 COS WP Woo 设计交付模块时，我们从一个简单的想法开始：一个插件 - 所有运营商。不是针对每个订单向您收取佣金的聚合商。不是一个通用包装器，只要运输公司的 API 发生变化，就会损坏。并与每个运营商的 API 进行全面的直接集成，通过单一软件界面统一起来。听起来很简单？在实践中，这意味着数月的工作、数百小时的测试以及我想谈论的数十个细微差别。
但我们不是从技术细节开始，而是从经济角度开始。因为最终，店主感兴趣的不是我们把建筑设计得有多漂亮，而是他会节省多少钱，有多少问题会从他的日常生活中消失。
不言而喻的算术
让我们算一下。 SDEK 插件 - 普通版本每年 5000 卢布起，支持 API v2。黄杨莓——差不多，可能便宜一点，三四千。业务线 - 这里的选择较少，好的插件从六千起。俄罗斯邮政 - 另外三到五千。 KIT——很少有人做，但做的时候要五七千，因为市场很小，几乎没有竞争。总计 - 每年十五至五万卢布仅用于交付插件。这还没有考虑到您的技术人员（或您自己）花费在设置、同步和维护工作秩序上的时间。
但钱并不是最糟糕的事情。最糟糕的是冲突。我记得有一个案例，我们的一个客户将 WordPress 更新到 6.5 后，五分之二的交付插件停止工作。他们就停了下来。其中一个的开发人员在一周内做出了回应，第二个则在三周内做出了回应。一直以来，该商店的送货选择有限，订单丢失，并收到负面评论。因为买家不会明白为什么他最喜欢的运输公司不在收银台——他只会去找竞争对手。
还有一点很少有人谈论。每个交付插件都会将自己的脚本和样式添加到结帐页面。第一个连接地图的 jQuery 小部件，另一个连接它自己的 React 组件，第三个连接其他东西。结果，结帐页面在四到五秒内加载，而不是所需的两秒，并且转化率下降。研究表明，结账时加载时间每增加一秒，转化率就会降低百分之七到百分之十。将其乘以您的平均账单和每月订单数量 - 这个数字令人印象深刻。
当所有运营商都使用一个插件工作时，这是一个脚本下载、一张地图、一个用于成本计算的 AJAX 请求。不是对五个不同 API 的五个请求，而是对您的服务器的一个请求，该服务器在后端并行查询所有必要的 API 并返回合并的结果。速度上的差异是巨大的。
我们如何构建这一架构：一个接口 - 所有运营商
您知道好工程系统和坏工程系统的区别是什么吗？一个好的系统经过精心设计，添加新元素不会破坏现有元素。当我们开始设计交付模块时，我们做的第一件事就是为所有运营商定义一个通用合同。在编程中，这称为接口，我们的 CarrierInterface 准确描述了每个承运商应该能够执行的四件事：提供其代码和名称、计算交付成本、返回取货点列表以及检查是否配置了 API 密钥。
作为店主，为什么这对您很重要？因为这意味着从系统角度来看，所有运营商的工作方式完全相同。结账时，买家会看到一个统一的表格，其中显示了每个承运商的费用、送货时间以及是否可以送货上门或送货到提货点。无需了解不同插件的不同接口。一切看起来都像一，因为它就是一。
我们实施了五个运营商：SDEK、KIT、Business Lines、Russian Post 和 Boxberry。它们中的每一个都是实现公共接口的单独类。 CdekCarrier 与 SDEK API 2.0 版配合使用，使用 OAuth 授权并支持两种费率 - 送货到发货点和快递到门。 KitCarrier 与 KIT Auto API 集成，特别适合重型和超大货物的城际运输。 DellineCarrier 与俄罗斯最大的运输公司之一 Business Lines 合作，如果您发送托盘或大型货物，这是必不可少的。 PostRussiaCarrier 通过 otpravka-api.pochta.ru 连接到俄罗斯邮政 API，并计算包裹、包裹、EMS 和快递递送的费用。最后，BoxberryCarrier 与 Boxberry API 配合使用，该 API 在中小型包裹领域尤其受欢迎。
这就是我想停下来解释为什么我们选择直接 API 集成而不是聚合器的地方。市场上有像 eShopLogistic 这样的解决方案，它充当商店和运输公司之间的中介。这个想法很美好——您连接一项服务并通过单个 API 访问所有运营商。我们自己在一个项目中使用了这种方法，并遇到了许多问题，迫使我们重新考虑我们的策略。
第一个也是最明显的问题是额外的故障点。当您的商店和 SDEK 之间存在其他服务时，该服务一侧的任何故障都意味着您的所有运营商同时停止工作。我们在六个月内遇到了两次这种情况 - 聚合器瘫痪了几个小时，整个结帐瘫痪了。通过直接集成，如果 SDEK API 没有响应，所有其他运营商将继续工作。买家根本看不到 SDEK 选项，但可以选择 Boxberry 或 Business Lines。
第二个问题是速度。通过聚合器的请求如下所示：您的服务器→聚合器→运营商API→聚合器→您的服务器。每个请求都会额外花费一百到两百毫秒，这会导致结帐时出现明显的延迟。通过直接集成，您的服务器直接访问运营商的API，响应速度更快。
第三个问题是数据相关性。聚合商并不总是立即发现运输公司 API 的变化。当 SDEK 将其 API 更新到版本 2.0 时，一些聚合商仍在旧版本上工作了数月，并返回了不准确的成本和条款数据。通过直接集成，您可以使用最新版本的 API 并获得最准确的计算。
老实说，直接集成有一个缺点 - 难以支持。当每个运营商更新其API时，我们需要更新插件中相应的类。但这正是存在单一 CarrierInterface 的原因 - 一个运营商的更改不会影响其他运营商。我们可以轻松更新 CdekCarrier，而无需触及 BoxberryCarrier，一切都会继续工作。
如果我们从另一个角度来看呢？想象一下，明天市场上出现一家新的运输公司，为您所在地区提供优惠的价格。在我们的架构中，添加一个新的载体就是创建一个实现相同接口的新类。无需更改现有代码，没有破坏任何内容的风险。我们创建了一个课程，并在系统中注册了它 - 它已经在结帐时出现在其他课程旁边。尝试使用来自不同开发人员的五个独立插件来实现此目的。
FIAS、地址以及为什么字符串搜索是一条无路可走的道路
有一个话题交付插件开发人员通常害羞地保持沉默。这是一个确定接收城市的问题。看起来这里并没有什么复杂的事情——买家进城，系统转给运输公司，然后他们就收到了计算结果。但实际上一切都更有趣。
尝试在不同的 API 中输入“Chelyabinsk” - 一切都会正常工作。现在试试下塔吉尔。或“卡马河畔切尔尼”。或“顿河畔罗斯托夫”。每个运输公司都有自己的城市目录、自己的名称格式和自己的代码。 SDEK 使用自己的内部城市代码。黄杨莓 - 我们的。业务线 - 您自己的终端。俄罗斯邮政根据邮政编码运营。现在，您正在编写从一种格式到另一种格式的转换器，处理拼写差异（有或没有连字符，单词出现的顺序），这变成了无休止的支持噩梦。
我们从根本上解决了这个问题。我们使用 FIAS - 联邦信息地址系统，而不是在不同 API 之间匹配字符串城市名称。这是俄罗斯联邦的官方地址分类器，每个地点都分配有一个唯一的标识符 - GUID。该标识符并不取决于您如何书写城市名称 - 西里尔字母、拉丁字母，无论是否有拼写错误。
在我们的系统中，WooCommerce 中的每个运输类别都与发货城市的 FIAS 代码相关联。这意味着当产品从某个仓库发送时，系统可以准确地知道它是从哪个城市发送的 - 不是通过其字符串名称，而是通过联邦目录中的唯一标识符。对于收件人所在的城市，我们使用多种方法的组合 - FIAS 代码（如果有），或俄罗斯邮政的邮政编码，或提供城市搜索 API 的运营商的内部城市代码。
我很长时间以来一直想知道为什么其他开发人员不使用这种方法。与往常一样，答案很简单——实施起来却更困难。字符串搜索就是一行代码。 FIAS 集成是一个单独的 ShippingFias 类，它将 FIAS 代码列添加到 WooCommerce 运输类别设置中，将这些代码存储在分类元数据中，并在计算运输时提供它们。但结果是值得的 - 计算对于俄罗斯的任何城市都正确，不会因名称拼写差异而出现错误。
这是我们实践中的一个具体示例。一位客户在俄罗斯各地销售石油，并面临这样一个事实：当发送到诺亚布尔斯克市时，旧的SDEK插件无法找到该城市，因为在其内部目录中该城市被记录为“诺亚布尔斯克（秋明州地区）”，而买家只需输入“诺亚布尔斯克”。订单被卡住了，经理打电话给客户，澄清了地址，并在SDEK网站上手动创建了一个应用程序。将此乘以每月二十到三十个这样的案例，您就会了解问题的严重程度。有了 FIAS，这个问题就根本不存在了，因为诺亚布尔斯克在联邦目录中只有一个 GUID，并且所有运营商都会准确地接收到该 GUID。
使用地址还有一个方面值得一提 - 按调度仓库对货物进行分组。在实际业务中，尤其是在B2B领域，货物通常存储在不同的仓库中。我们的一位客户在车里雅宾斯克的仓库中存放有壳牌油，在内尔森的仓库中存放有卢克石油公司的油，在另一个地点的营销仓库中存放有液压油。每个仓库在 WooCommerce 中都有自己的交付类，并具有关联的 FIAS 代码。当买家将不同仓库的商品添加到购物车时，我们的系统会自动将它们分组并单独计算每个组的运费。买方看到壳牌油品的运输成本如此之高，卢克石油公司油品的运输成本如此之高，总成本是这样的。透明、易于理解，没有隐藏的惊喜。
值得您自豪的结帐：配送矩阵和取货点地图
现在我们来谈谈买家所看到的。因为您可以在后端构建完美的架构，但如果结帐时一切看起来都像 1998 年的 Excel 电子表格，那么没有人会过得更好。
我们建立了一个交付矩阵 - 买家可以在其中看到所有连接运营商的所有可用选项的表格。对于每个选项，都会显示承运商的名称、送货类型（送货上门或送货点）、费用和预计时间。买家一键选择合适的选项。如果他选择送货到取货点，则会打开一张地图，其中标有他所选择的承运商的标记点。您可以在地图上找到最近的接载点、查看其地址和开放时间。
你知道现有的交付插件一直让我烦恼的是什么吗？它们按顺序显示选项 - 首先是所有 SDEK 选项，然后是所有 Boxberry 选项，然后是所有 Russian Post 选项。买家本人必须滚动浏览这个无穷无尽的清单，比较价格和条款。我们的矩阵中的一切都很清楚 - 所有运营商都在附近，可以进行比较和选择。我相信这会显着影响转化，尽管我们还没有针对这个特定元素进行准确的 A/B 测试。但逻辑表明：一个人越容易做出决定，他下订单的速度就越快。
值得单独提及的是结帐时矩阵的技术实现。 WooCommerce 提供了标准的运输方法机制，我们的模块使用 ID wpaic_shipping 注册单个运输方法。一种方法，而不是五种单独的方法。这意味着所有承运商都使用相同的 WooCommerce 运输方式，与 WooCommerce 运输区域正确集成，并且不会与您可能使用的其他运输方式冲突（例如，路边取货或超过一定订单金额的免费送货）。
费用计算通过每个运营商的 API 实时进行。当买家在结账时输入地址时，我们的插件会将订单参数（重量、尺寸、申报价值、收件人城市）发送到每个连接的 API，并接收回成本和交货时间。结果会缓存十分钟（这是一个可配置的设置），以避免在客户刷新页面或更改购物车中的商品数量时给 API 带来冗余请求的负担。
在这里我想谈谈一个看似微不足道的技术细微差别，但实际上却花费了我们几天的调试时间。在 WooCommerce 中，会话数据是字符串。当您从会话中获取某个项目的重量时，您会得到字符串“1.5”而不是数字 1.5。如果您将此字符串传递给 PHP 8.x 中的 round() 函数，而没有显式地将其转换为 float，则会出现错误。这听起来微不足道，但想象一下您有五个运营商，每个运营商都从会话中接收数据 - 如果至少一个开发人员忘记了类型转换，则成本计算将会中断。在我们的代码中，参数中的每个数值在数学运算之前都会显式转换为浮点数。琐事？是的。但正是这些小事，才构成了稳定的工作。
我认为还有一点非常重要。交付计算是通过 woocommerce_review_order_before_ payment 挂钩呈现的，而不是像许多指南建议的那样通过 before_order_review 呈现。为什么？因为 before_order_review 无法与正在成为标准的块 WordPress 主题一起正常工作。我们花了很多时间来弄清楚为什么交付矩阵根本没有出现在具有“二十二十五”主题的测试站点之一上，直到我们发现块主题中的 before_order_review 挂钩在结帐表单完全呈现之前被触发。切换到 before_ payment 解决了这个问题。有许多这样的细微差别，它们是“似乎可以工作”的插件与可靠工作的插件的区别。
追踪：从订单创建到包裹递送
送货不仅仅是在结账时计算成本和选择承运人。这也是下订单后发生的情况。买家想知道他的包裹在哪里、什么时候到达以及如果出现问题该怎么办。这就是大多数 WooCommerce 商店混乱开始的地方。
典型场景如下所示：经理将货物放在运输公司的网站上，获取跟踪号码，复制它，将其粘贴到 WooCommerce 中的订单备注中，也许 - 也许！ — 向买家发送一封包含该号码的电子邮件。买家收到一封信，访问承运商的网站，输入跟踪号码并检查状态。如果运营商不同，他需要知道要检查哪个网站。如果订单包含来自多个承运商的货物（还记得按仓库分组吗？），买家需要在不同网站上跟踪多个跟踪号。
我们已将货运跟踪直接集成到系统中。当经理在订单卡中输入跟踪号码时，买家会在商店网站上的个人帐户中看到它。无需访问第三方网站，无需记住哪个承运商交付订单的哪一部分。一切都集中在一处 - 运营商名称、轨道编号、当前状态。当货件状态发生变化时，买家会收到电子邮件通知。
我经常听到这样的问题：“如果买家已经可以在运营商网站上查看曲目，为什么要在插件中执行此操作？”答案很简单 - 因为这关系到客户体验。如果一家商店的所有信息都集中在一个地方（即您的个人帐户中），则被认为更加专业和可靠。买家不会认为“我在某个网站上订购了，但它是由SDEK交付的”。他认为，“我从这家商店订购，他们确保我可以轻松跟踪交货情况。”正是这些小事才能建立忠诚度。
现在我们来谈谈卖方方面。如果您的在线商店每天有数十个订单，那么管理送货就变成了一件苦差事。跟踪号码、状态、通知——所有这些都需要控制。我们的交付模块与 1C 模块集成，这也是 COS WP Woo 的一部分。这意味着发货状态可以与您的会计系统同步。 1C中的经理看到订单已发送，其轨道号是多少，承运商是什么，当前状态是什么。无需在多个系统之间切换 - 一切都是同步的。
我知道很多人对“多合一插件”的想法持怀疑态度。我理解这种怀疑。就阐述而言，通用解决方案通常不如专业解决方案。但这里有一个重要的细微差别：我们不会为所有事情制作一个插件。我们正在为 WooCommerce 商店生态系统制作一个插件，其中所有模块一起工作并交换数据。交付模块了解 1C 模块。 1C 模块了解 B2B 模块。 B2B 模块了解电子邮件通知模块。这并不是将不同功能塞进一个 ZIP 文件中的集合 - 它是一个集成系统，其中每个模块都增强了其他模块。
俄罗斯邮政是一家始终与众不同的承运商
我想单独谈谈俄罗斯邮政，因为它的整合是一个单独的故事，同时充满痛苦和喜悦。俄罗斯邮政是该国最大的物流网络。超过四万二千个分支机构。送货到任何地方，包括村庄和城镇，没有商业承运人会去的地方。对于许多商店来说，俄罗斯邮政是将货物运送到偏远地区的唯一途径。
同时，温和地说，俄罗斯邮政 API 是一个奇特的东西。他们有两个 API：关税计算器（公共，未经授权）和发送 API（通过令牌和登录进行授权）。关税计算器通过邮政编码工作 - 您通过发送索引、接收索引、重量、物品类型和声明价值，并获得费用。听起来很简单，但一如既往，细节决定成败。
调度类型让大多数开发人员感到困惑。包裹、包裹邮寄、EMS、快递递送 - 每种类型都有自己的代码、自己的重量和尺寸限制以及自己的关税表。我们的俄罗斯邮政承运商会根据订单的重量和申报价值自动确定最佳的运输类型。如果包裹较轻，则按包裹邮寄计算（比较便宜）。如果很重，就像一个标准包裹。如果买家想要更快，他提供EMS或快递。买家可以看到所有可用的选项以及价格和条款，并选择适合他的选项。
错误处理则不同。俄罗斯邮政 API 可能会因完全不明显的原因返回错误 - 例如，因为邮政编码指的是军事单位或封闭领土实体。在这种情况下，我们的插件不会向买家显示加密错误消息，而只是不显示俄罗斯邮政选项，从而让其他运营商可用。这似乎是一件小事，但对于买家来说，“交货计算错误，稍后重试”与正常工作的结帐（其中一个选项根本不可用）之间存在巨大差异。
从架构的角度来看，这就是乐趣的开始。还记得我谈到过单一 CarrierInterface 吗？ calculate() 方法中的每个承运商都会返回一个标准化结果 - 成功状态、价格、截止日期、错误文本（如果有）和承运商代码。这意味着所有承运人的结果处理系统完全相同。如果 SDEK 返回错误，我们将显示其余部分。如果俄罗斯邮政返回错误，我们将显示其余部分。如果每个人都返回成功的结果，我们将显示完整的矩阵。该逻辑简单且可靠，因为它不依赖于特定运营商的具体情况。
SDEK 和 Boxberry 是两个应该成为朋友的巨头
SDEK 和 Boxberry 可能是俄罗斯在线商店最受欢迎的两个运营商。 SDEK 拥有庞大的配送点网络 - 遍布全国超过 4000 个。 Boxberry 有自己的优势，特别是在小包裹领域和 SDEK 代表性较差的地区。许多商店将这两种服务结合起来，为买家提供最大的选择。
SDEK 切换到 API v2.0，它使用 OAuth 授权。这意味着要访问 API，您必须首先通过将 client_id 和 client_secret 交换为临时不记名令牌来获取访问令牌。我们的 CdekCarrier 会自动处理此问题 - 接收令牌，将其缓存在 WordPress 瞬态中，并在其过期时自动更新。对于作为用户的您来说，这意味着您在插件设置中输入 client_id 和 client_secret 一次，就再也不用考虑它了。
Boxberry 的情况更简单 - 他们通过令牌进行授权，该令牌作为请求参数传递。但 Boxberry 在定义城市方面也有其自身的困难。 Boxberry 使用自己的内部城市目录和自己的代码。我们的 BoxberryCarrier 首先解析买家的城市 - 通过名称和邮政编码在 Boxberry 目录中查找其代码 - 然后才计算送货费用。如果找不到该城市（这种情况发生在小镇），Boxberry 就不会出现在配送矩阵中，买家可以选择其他承运商。
在多年的配送工作中，我注意到的一件有趣的事情是，客户对“他们的”承运商非常忠诚。有些人原则上只选择SDEK，因为他们家附近有方便的接送点。有些人更喜欢 Boxberry，因为他们可以更快地送货到他们所在的地区。有些人喜欢 Business Lines，因为它们能够可靠地运送重物。而商店的任务不是把特定的载体强加给买家，而是给予买家一个选择。选择越多，买家找到适合自己并完成订单的可能性就越大。
但硬币还有另一面。每个额外的运营商都意味着需要获取和配置额外的 API 密钥。对于 SDEK，您需要注册协议并获得 API 的访问权限。对于 Boxberry - 获得一个令牌。对于业务线 - 签订协议并接收 API 密钥。对于俄罗斯邮政 - 在 otpravka.pochta.ru 注册并接收授权令牌。对于 KIT 来说也是一样的。我们无法为您完成这部分 - 这是您和运输公司之间的过程。但我们可以 - 并且确实 - 在插件设置中提供关于在哪里以及如何获取每个密钥的明确说明，并提供指向注册页面的直接链接。
你知道最好的部分是什么吗？每个运营商中的 is_configured() 方法检查 API 密钥是否已配置。如果不是，承运商根本不参与计算。这意味着您可以首先仅连接 SDEK 和 Boxberry，然后，当您同意 Business Lines 和 KIT 时，只需在设置中输入密钥即可添加它们。无需重新配置，无需重复测试。系统将自动选择新的承运商并开始在结帐时显示它们。
KIT 和业务线 - 适合运载严重货物的人
SDEK 和 Boxberry 没有很好地服务于一个细分市场 - 这些是大而重的货物。一罐 20 升机油重约 18 公斤。一个200升的桶已经是200公斤左右了。油托盘 - 500-800 公斤。此类货物需要专门从事拼装货物的承运人，并拥有接收大宗货物的码头。
KIT（工业运输公司）是城际公路货运领域的领导者之一。他们在俄罗斯各地拥有 500 多个码头，可以很好地处理 20 至 20,000 公斤的货物。对于我们销售工业油和润滑油的客户来说，KIT 往往是城际运输的性价比最佳选择。
Business Lines 是该领域的另一个主要参与者，在俄罗斯各地拥有 1000 多个终端和分支机构。他们的 API 允许您计算运送到航站楼和收件人门口的成本，同时考虑附加服务 - 保险、硬质包装、提升到地板。
当我们集成 KIT 和 Business Lines 时，我们面临这样一个事实：它们的 API 结构与 SDEK 或 Boxberry 的 API 结构完全不同。它们有不同的授权模型、不同的请求和响应格式以及不同的终端判断逻辑。但这正是单一接口的价值——所有这些差异都隐藏在特定的运营商类别中。从外部来看，对于交货计算系统，所有承运商看起来都是一样的：我们调用calculate()，获取价格和截止日期。我们调用 get_terminals() 并获取接送点列表。一切都是统一的，一切都是可预测的。
对于销售重型商品的店主来说，KIT 和 Business Lines 存在于已安装 SDEK 和 Boxberry 的同一个插件中不仅仅是方便。这扩大了交付地域并降低了最终买家的成本。因为通过 SDEK 发送 100 公斤的订单，成本可能是一万卢布，而通过 KIT 则为三千卢布。当买家在结帐时看到这两种选项并排时，他会做出明智的选择，并且不会觉得商店试图通过送货赚钱。
我经常听到店主说：“我为什么需要KIT或者Business Lines？我有小货，SDEK和Boxberry就够了。”在大多数情况下这是事实。但我注意到的是：一旦商店开始发展并扩大其品种，迟早会出现 SDEK 和 Boxberry 不是最佳选择的产品。如果此时您已经拥有支持 KIT 和 Business Lines 的插件，则只需获取 API 密钥并将其输入到设置中即可。如果没有，你需要寻找一个新的插件，购买它，配置它，测试它，并希望它不会与现有的插件发生冲突。
缓存和性能：使结账工作正常进行
我已经提到了缓存，但我想更详细地讨论它，因为它对于任何在线商店来说都是一个关键主题。对运营商 API 的每个请求都是一个网络请求，所需时间从 200 毫秒到两秒不等，具体取决于运营商及其服务器的繁忙程度。如果您有五个连接的运营商，并且每个运营商需要计算两个选项（快递公司和提货点），则需要十个网络请求。始终如一 - 结帐时需要等待十到二十秒。同时，这需要两到三秒，但服务器上的负载仍然很大。
我们的做法是将计算结果缓存十分钟（可配置参数cache_ttl）。缓存键由订单参数组成：发货城市、收货城市、重量、申报价值。如果买家刷新页面或者再次去结帐同一组商品，计算结果会立即从缓存中返回。如果他改变了商品数量或者送货地址，则缓存失效，重新进行计算。
十分钟是数据相关性和性能之间的合理折衷。运输公司的运价并不是每分钟都在变化。它们可以每天更换一次、每周一次或每月一次。十分钟的缓存可确保买家收到当前价格，但结帐不会因为对 API 的冗余请求而减慢。
还有一个与性能相关的方面很少有人考虑。当您使用五个单独的交付插件时，每个插件都包含自己的 PHP 类、自己的 WordPress 挂钩、自己的 AJAX 处理程序。即使买家不在结帐页面上，每个请求都会给服务器带来额外的负载。在我们的插件中，所有载体都是轻量级 PHP 类，仅在实际需要时（即计算交付时）才加载和初始化。他们不会在网站的每个页面上添加挂钩，也不会在不需要交付的页面上包含脚本。
这对您的业务意味着什么？
我以一个关于润滑油店老板的故事开始这篇文章，我想回到它。当他从五个独立的插件切换到我们的交付模块后，发生了一些事情。每年订阅费用节省约三万卢布。结帐加载时间已从五秒缩短至一秒半。有关交付的支持电话数量下降了百分之四十。而且 - 也许最重要的是 - 他不再担心 WordPress 更新，因为现在他有一个插件而不是五个，并且一个团队负责其兼容性，而不是五个不同的开发人员。
但我不想给人留下这样的印象：我们的解决方案对每个人来说都是完美的。如果您有一家小商店，每月有 20 个订单，并且唯一的运营商是 SDEK，那么 SDEK 的免费插件可能就足够您使用了。当您拥有多个承运商、多个运输仓库，并且结账速度和客户体验的一致性对您很重要时，我们的交付模块就会充分发挥作用。当您需要与1C集成以同步状态时。当您同时销售轻型商品（SDEK、Boxberry、Russian Post）和重型商品（KIT、Business Lines）时，您希望所有商品都作为单一机制运行。
我最近一直在思考另一个论点。俄罗斯的运输服务市场正在发生变化。新的运营商出现，旧的运营商改变其条件，一些离开某些地区。当您拥有单一运营商接口架构时，适应这些变化是快速且轻松的。需要添加新的运营商吗？创建一个实现 CarrierInterface 的新类。需要禁用运营商吗？我们从设置中删除了它的 API 密钥，并且它只是在结账时停止显示。需要更新与已更改 API 的运营商的集成吗？我们更新一类并保留其余的。这是通过一堆不同的插件无法获得的灵活性。
我争论了很长时间是否要写这篇文章，因为交付这个话题似乎很无聊。这不是人工智能，不是区块链，也不是一些花哨的技术。但你知道吗——交货直接影响金钱。用于结账转化、支持成本、客户忠诚度、业务可扩展性。当您找到一种使交付更容易、更快、更便宜的解决方案时，这在会议上听起来可能不太好，但这正是真正的企业所需要的。
我们继续开发交付模块。这些计划包括扩大承运商列表、与 API 进行更深入的集成以自动创建请求，以及在结帐时直观显示所有提货点的交互式地图。但现在我们所拥有的 - 五个运营商、单一接口、FIAS 地址、结帐矩阵、跟踪和与 1C 的集成 - 满足了俄罗斯绝大多数 WooCommerce 商店的需求。
最后一件事。人们经常告诉我：“All in one 意味着如果插件坏了，一切都会坏。”一个合理的担忧。但说实话 - 如果您有五个独立的插件，其中一个损坏了，那么您的结账部分也会损坏。如果五分之二坏了，你仍然在疯狂地寻找解决方案。不同之处在于，使用一个插件，您就有一个支持团队、一个反馈渠道、一个更新流程。如果出现问题，您知道该向何处求助。您不必找出这五个插件中的哪一个造成了冲突，而是写信给我们，我们将解决问题。这不是一个完美的世界，但却是一个问题解决得更快的世界。
试用 COS WP Woo - 免费 14 天。一个插件（而不是五个）用于交付，另外还有用于您的 WooCommerce 商店的四十多个模块。只需一晚即可连接 SDEK、Boxberry、Business Lines、Russian Post 和 KIT，而不是一周。设置一次，就可以忘记交付的麻烦。