上周，我分析了一个客户的网站 - 一家批发公司、工业过滤器、目录中的大约三千项、WordPress 上的 WooCommerce。该网站已有三年历史，运行良好，但让我丧命的是：二十四个活动插件。 24。这还不包括 mu 插件和那些“以防万一”而停用的插件。这二十四个插件中有两个用于接受付款的独立插件。一个是尤卡萨（YuKassa），第二个是廷科夫（Tinkoff）。每个都有自己的设置、自己的更新、自己的冲突。 YuKassa 插件在六个月前更新，破坏了移动设备上的订购流程 - 结帐根本无法加载。我们花了两天的时间来解决这个问题。 Tinkoff 插件已经有一年多没有更新了——当切换到 PHP 8.2 时，它开始在日志中每天散布一百兆字节的已弃用错误。
听起来很熟悉吗？如果没有的话我会感到惊讶。因为这对于在俄罗斯的 WooCommerce 上建立在线商店的任何人来说都是典型的痛苦。我们需要俄罗斯支付系统 - YuKassa、Tinkoff、SBP。每个插件都有一个单独的插件，具有单独的生命周期、单独的开发人员和单独的兼容性历史记录。如果您还有需要向法人实体开具发票的 B2B 客户，欢迎来到拐杖、WooCommerce 挂钩、重做结帐和不眠之夜的世界。
我想了很长时间为什么会发生这种情况。为什么 2026 年在俄罗斯 WooCommerce 网站上接受付款是一个任务。答案很明显：没有人认为支付是单一系统的一部分。每个支付插件都是一个单独的缩影。它在数据库中有自己的表、自己的钩子、自己的 JavaScript 文件，这些文件在结帐时加载。当这些微观世界开始在同一个 WordPress 中相互碰撞时，火花四溅。风格冲突、脚本重复、处理回调时的竞争条件。我看到一个网站，两个插件尝试同时处理同一个 webhook - 并且订单被标记为已付款两次，这破坏了库存控制。
当我们在 COS WP Woo 中设计支付模块时，想法很简单，而且在我看来是正确的：支付网关应该内置到已经管理商店的工具中。不是作为单独的插件，而是作为单一架构的一部分。一个插件 - 一个配置点 - 一项更新。这听起来很明显，但出于某种原因，这是 WordPress 生态系统的一场革命。
你知道最令人惊讶的是什么吗？当我与店主讨论这个想法时，第一反应几乎总是相同的：“为什么？这对我来说就是这样。”它会一直工作直到损坏为止。直到 WooCommerce 更新到下一个主要版本。直到PHP切换到新版本。直到YuKassa改变API。然后恐慌开始了：插件不兼容，结帐不起作用，客户无法付款，钱没有到账。现在事实证明，该插件的作者是一位来自新西伯利亚的开发人员，他在主要工作的空闲时间更新了代码。他现在没有时间，因为他的主要项目有最后期限。而且你有一家商店。我不会责怪这位开发人员 - 他的工作非常出色，而且通常是免费的。但在直接影响收入的问题上依赖一个人是一种可以而且应该消除的风险。
为什么每个额外的插件不仅仅是“另一个插件”
让我们谈谈当您安装单独的插件来接受付款时实际发生的情况。这不仅仅是文件夹中的文件wp-内容/插件。每次加载页面时，这些都是对数据库的额外查询 - 因为 WordPress 会加载插件的元数据，检查其状态，加载其文本域以进行翻译。这些是结帐期间的额外 HTTP 请求，因为插件会随之提取 CSS 和 JS 文件。这是更新时的另一个失败点 - 任何使用 WooCommerce 一年以上的人都知道，WooCommerce 更新喜欢以令人羡慕的规律性破坏插件。
但这甚至与性能无关。这是一个可控性的问题。当您有两个或三个独立的支付插件时，您将获得两个或三个独立的配置接口。 YuKassa 在一个地方进行配置，Tinkoff 在另一个地方进行配置，发票的手动支付在第三个地方进行配置。每次经理或网站所有者想要更改某些内容时（例如，通过 Tinkoff 启用分期付款或为 B2B 客户添加付款方式），他都需要记住所有内容的位置。如果不是他，而是六个月前安装的承包商，祝你搜索顺利。
我已经遇到过这种情况几十次了。一位客户打电话说：“我们的卡支付在我们的网站上消失了。”您开始弄清楚 - 原来 WooCommerce 已更新，YuKassa 插件与新版本不兼容，并且网关自动停用。但有关此事的通知发送到了一封没有人阅读的电子邮件。客户在结帐时会看到唯一可用的付款方式 - 银行转账，这是通过标准 WooCommerce BACS 网关配置的。然后他们离开了。因为当你想花两千卢布购买过滤器时，谁会用银行转账来购买过滤器呢？
当支付系统插件与其他插件发生冲突时，它会变得更加有趣。我记得有一个项目，YuKassa插件和多语言插件冲突——结帐时切换语言时，回调URL丢失，支付总是失败，报错。或者另一种情况：Tinkoff 插件使用其版本的库来处理 HTTP 请求，这与 WooCommerce 订阅发生冲突。这些事情是无法预测的，而且它们发生在最不合时宜的时刻——通常是在周五晚上，广告开始播放、流量达到高峰的时候。
这就是为什么我认为删除所有可以从 WordPress 中删除的内容并将功能整合到一处是非常重要的。不是出于贪婪 - 他们说，让我们将所有内容都塞进一个插件中，就会有一个整体。不，从工程常识来看。支付网关并不是火箭科学。这些是具有明确记录的协议的 API 集成。 YuKassa 和 Tinkoff 拥有优秀的文档和稳定的 API。没有理由说这应该是一个具有单独生命周期的单独插件。
内置网关可以做什么：YuKassa、Tinkoff 和 B2B 方法
当我说“内置支付网关”时，我的意思是：在 COS WP Woo 内部，完整实现了 YuKassa、Tinkoff 和注册为标准 WooCommerce 支付网关的三种 B2B 支付方式。对于 WooCommerce，它们看起来与其内置网关完全相同 - 银行转账或货到付款。它们在 WooCommerce 设置、结账和订单中可见。但它们是通过单一界面进行管理、一起测试、一起更新的。
让我们弄清楚到底有什么可用以及为什么需要它。
YuKassa 实际上是俄罗斯电子商务在线支付的标准。如果您在 WooCommerce 上有一家在线商店并接受个人付款，则需要 YuKassa。我们的内置网关支持三种主要方式：银行卡支付、快速支付系统和YuMoney - 电子钱包。为什么是这三个？因为它们涵盖了百分之九十五的场景。卡 - 适合那些习惯使用 Visa 或 MasterCard（或者更准确地说是 Mir - 2026 年）支付的人。 SBP适用于那些使用二维码通过移动银行付款的人，这种方法正在迅速普及，特别是对于最高一万五千卢布的付款。 YuMoney是针对那些使用YuMoney钱包的人，而且这样的人也有很多，尤其是25-40岁的受众。
设置实际上需要几分钟时间。输入您的 YuKassa 个人帐户中的商店 ID 和密钥，选择要激活的方法，就这样 - 网关开始工作。没有单独的插件，数据库中没有额外的表，没有额外的 JS 文件用于结帐。付款通知的 Webhook 通过标准 WooCommerce 回调进行处理，付款成功后订单将自动转为“处理中”状态。
这就是乐趣的开始 - 两阶段支付，也称为持有。这是很少有插件能够正确实现的功能，但对于某些企业来说，它至关重要。这个想法很简单：付款时，钱不会从客户的卡中扣除，而是被冻结和持有。商店看到付款已完成并开始组装订单。只有当订单实际准备好发货时，经理才会确认借记并将款项转入商店的帐户。如果订单因故取消，冻结解除，款项自动返还给客户，不退款，无需任何不必要的操作。
为什么需要这个？想象一下：您销售工业设备。客户以四十万卢布的价格订购了一台泵。您检查仓库中的可用性 - 但它不存在，您需要向供应商订购，截止日期是三周。如果不持有，你会立即注销这笔钱，然后担心三个星期，以防客户改变主意并要求退款，但这笔钱已经在流通了。通过持有，钱会被冻结在客户的卡上，您可以从供应商那里平静地订购，并且只有当货物实际到达仓库并准备好装运时才会被扣款。客户也很平静——他看到钱并没有消失，只是被冻结了。这是买家和卖家之间根本不同的信任程度。
在我们的网关中，通过设置中的一个开关即可启用两阶段支付。此后，所有通过 YuKassa 的付款均以保留模式处理。经理可以直接从 WooCommerce 中的订单卡确认或取消付款 - 相应的按钮会出现在那里。无需登录您的 YuKassa 个人帐户，无需在窗口之间切换。一切都在一处。
现在关于 Tinkoff。 Tinkoff Acquiring 是俄罗斯第二受欢迎的支付网关，仅次于 YuKassa，对于某些类型的企业来说，它甚至更可取。首先，Tinkoff的收购条件往往更好——交易费用较低，特别是对于每月营业额超过100万卢布的中型企业。其次，Tinkoff 有一个内置的分期付款计划 - 这对于销售昂贵商品的商店来说是一个杀手级功能。
COS WP Woo 中内置的 Tinkoff 网关的工作原理相同：输入您的 Tinkoff 个人帐户的终端密钥和密码，网关就准备好了。支持标准收单 - 通过卡付款和分期付款 - 当客户可以将付款分几个月无息支付时。商店以廷科夫佣金的形式分期付款，但对于价值十到一万五千卢布的商品来说，它绝对是有回报的——转化率提高了百分之二十到三十，因为从心理上来说，每月支付三千卢布比一次支付一万五千卢布对客户来说更容易。
Tinkoff 还支持两阶段支付，我们的网关实现了这一点。逻辑是一样的：持有、订单卡借记确认、订单取消时自动取消持有。统一性很重要。经理不需要记住确认对于 YuKassa 来说是这样的，但对于 Tinkoff 来说则不同。界面相同，按钮相同，逻辑相同。
然后我们继续讨论 COS WP Woo 与所有其他解决方案的区别 - B2B 支付方式。坦率地说，这就是我最初开始撰写本文的领域。
B2B支付：当“刷卡支付”不起作用时
如果您仅与零售客户合作 - 访问网站、将商品添加到购物车并通过卡支付的个人 - YuKassa 和 Tinkoff 可能足以满足您的需求。但一旦您开始与法人实体合作，您就会发现自己处于一个完全不同的世界。一个没有人用卡支付的世界。如果通过公司的银行账户通过发票付款。从下订单到实际收到货款可能需要一周甚至两周的时间。标准 WooCommerce 网关不仅不方便，而且从根本上来说是不合适的。
我见过一些公司试图解决这个问题。最常见的选择是经理在 1C 或 Excel 中手动生成发票，通过电子邮件将其发送给客户，然后等待。钱到账后，他手动更改 WooCommerce 中的订单状态。如果一天有五单的话还可以接受。如果五十就是地狱。错误是不可避免的：他们忘记更改状态，混淆了订单，发送的发票包含错误的详细信息。
另一种选择是标准 WooCommerce BACS（银行帐户/支票付款）。从技术上讲，这是银行转账。您在设置中指定公司详细信息，客户可以在“感谢您的订单”页面和电子邮件中看到它们。但这是文本信息——没有正常的计数。没有买家详细信息。没有自动生成文档。对于 B2B 来说，这根本就不严重。当采购公司的会计师收到一封包含“将 47,800 卢布转入某某经常账户”的电子邮件时，他至少会感到惊讶。他需要一个普通帐户 - 包含纳税识别号、检查点、法定地址、银行详细信息、印章和签名。可以打印、归档到文件夹中并提交以供检查的文档。
在 COS WP Woo 中，我们实现了三种 B2B 支付方式，每种方式解决了不同的问题。
第一个是通过发票付款，发票网关。这正是大多数 B2B 公司所需要的。结帐时，客户选择“按发票付款”，指明其公司的详细信息 - 或者，如果他已经注册为 B2B 用户，则这些详细信息会自动从他的个人资料中提取。下订单后，系统会自动生成付款发票 - 一份完整的文件，其中包含卖方和买方的详细信息、发票号码、日期、货物清单、金额和银行详细信息。该发票可以直接从您的个人帐户或电子邮件通知中以 PDF 格式下载。如果客户丢失了信件，经理可以重新发送发票。当付款到达时，订单状态会发生变化，并且客户会收到通知。
事情是这样的：它不仅仅是一个文本模板。这是根据订单数据生成的真实文档。卖家的详细信息取自设置 - INN、KPP、OGRN、法定地址、银行详细信息。买家详细信息 - 来自用户个人资料或结账字段。帐号是根据您配置的编号自动生成的。我知道这对于会计来说听起来像是小事，但是当每月生成一百个这样的帐户时，自动化可以节省数十个小时。
第二种方法是采购订单，或付款订单。这是一种更自由的B2B支付形式，在国际实践中很常见，并且越来越多地出现在俄罗斯大型公司中。底线：买方指明其内部采购订单的编号 - 采购订单号或 PO。这是采购公司内部商定的文件，并将根据该文件进行付款。对于卖家来说，这意味着订单已经确认，将进行付款——但不是现在，而是在买家在家处理完文件之后。通常付款期限为十四至三十天。
这种方法在工业公司中尤其受欢迎，因为这些公司的采购要经过多个审批阶段。采购经理创建请求，部门主管批准，财务总监签字，会计部门生成付款。整个过程可能需要两到三周的时间。一直以来，订单在 WooCommerce 中都处于“等待付款”状态并带有关联的 PO 编号。卖家经理看到这个号码就知道付款正在进行中。当钱到账后，他确认了订单。
第三种方法是内部钱包，钱包网关。这是一个完全独立的故事，在我看来，它被低估了。底线：对于每个 B2B 客户，系统中都会创建一个内部余额 - 钱包。客户可以通过银行转账充值任意金额，例如一百万卢布。之后，立即支付订单 - 资金将从您的钱包余额中扣除，无需等待银行转账，也无需为每个订单生成发票。
为什么需要这个？想象一下，一个大型批发客户每月发出二十到三十个订单。每个订单都意味着生成发票、等待付款、检查收据。每月二十个订单，这意味着二十张发票、二十笔付款、二十个银行工作日的等待。使用钱包：一次转账即可支付全部金额，然后客户一键立即支付订单费用。客户在其个人帐户中和经理在管理面板中都可以看到余额。所有交易都会被记录 - 存款、借记、退货。对卖家和买家来说都是透明的。
我与一家销售特种设备备件的公司的老板进行了交谈。他们有 200 名固定 B2B 客户，每个月都会下 5 到 15 个订单。当他们介绍内部钱包系统时，会计师简直流下了眼泪——每个月不是一千二百个账户，而是两百个存款。工作量下降了六倍。与此同时，客户开始更频繁地订购——因为付款是即时的，无需每次都等待批准。
所有三种 B2B 方法都集成到一个 B2B 销售模块 COS WP Woo 中。它们与客户群体、自定义定价、最小订购量和其他 B2B 功能结合使用。这不是一个附加组件 - 它是单个系统的一部分，其中所有内容都相互连接并且所有内容都可以协同工作。
支付安全：人们在第一次事件发生之前通常不会想到什么
既然我们谈论的是支付网关，我们就不能忽视安全这个话题。我现在不是在谈论 PCI DSS 和认证 - 这是 YuKassa 和 Tinkoff 自己的责任，卡数据是在他们这边处理的，WooCommerce 商店永远不会看到客户的卡号。我正在谈论其他事情 - 关于集成本身的安全性。
每个 WordPress 支付插件都是一个潜在的切入点。它有一个回调 URL，支付系统将通知发送到该回调 URL。该 URL 可通过互联网访问 - 否则 YuKassa 如何通知您的网站付款已完成？并且这个URL需要被保护。您需要检查请求签名，需要验证发件人的 IP 地址，需要检查金额和订单号是否与数据库中存储的内容匹配。如果您不这样做，攻击者可以向您的回调 URL 发送虚假请求，并“确认”无人付款的订单付款。货物会流向骗子，但钱不会。
听起来很偏执？理论上——是的。在实践中，我知道至少有三种情况确实发生过这种情况。在一种情况下，支付系统插件验证了请求签名，但未验证金额。攻击者创建了一个十万卢布的订单，然后发送了一个金额为一卢布的虚假回调 - 并且签名是有效的，因为他使用了支付系统的测试帐户。订单已更改为“已付款”状态。经理发货了。损失是十万卢布减去一卢布。
当网关构建到单个系统中时，安全性不是各个插件作者的责任，而是整体架构的一部分。在 COS WP Woo 中，所有回调处理程序都经过单个验证层：签名验证、金额验证、订单合规性验证、IP 地址验证（对于 YuKassa - Yoomoney IP 范围，对于 Tinkoff - 他们的服务器范围）。所有可疑请求都会记录在活动系统中。如果有人试图伪造网络钩子，您将从日志中得知，而不是从愤怒的客户的电话中得知。
很少有人考虑的另一个安全方面是 API 密钥存储。商店 ID 和密钥 YuKassa、终端密钥 Tinkoff - 这些实际上是您当前帐户的密钥。如果有人获得访问权限，他们可以将付款重定向到另一个帐户。这里重要的是插件如何存储这些数据。大多数插件以明文形式存储密钥wp_选项- 标准 WordPress 设置表。这意味着任何其他有权访问数据库的插件（在 WordPress 中，基本上是任何插件）都可以读取您的密钥。在 COS WP Woo 中，密钥被加密存储并隐藏在界面中 - 您只能看到最后四个字符。向设置 API 发出 GET 请求时，密钥永远不会以明文形式返回。这不是偏执——这是基本的卫生。
单点配置 - 以及为什么它比看起来更重要
我花了很多时间向客户解释为什么将支付网关整合到一个地方不是一种营销噱头，而是一种工程必需品。而且每次的论点都是一样的，只是人们需要时间去感受。
这是一个典型的情况。该公司网站上提供三种支付方式：针对个人的 YuKassa、针对分期付款的 Tinkoff 以及针对 B2B 的手动银行转账。三个不同的插件，三种不同的设置。经理想要暂时禁用分期付款计划，因为促销已经结束并且条件发生了变化。他转到 WooCommerce → 设置 → 付款。查看网关列表。找到廷科夫。单击“管理”。转到 Tinkoff 插件设置页面。禁用分期付款计划。节省。准备好？几乎 - 但他忘记了 Tinkoff 插件在 WordPress 主菜单中有一个单独的设置页面，并且那里还有一个分期开关。而且它们并不同步。两小时后，他检查了一下——结帐时再次可以使用分期付款计划。因为插件主菜单中的设置覆盖了 WooCommerce Payments 中的设置。
听起来像个笑话吗？这是一个真实的故事。我还有几十个类似的故事。
在 COS WP Woo 中，所有支付网关都配置在一处 - 一个选项卡上、一个界面中。 YuKassa、Tinkoff、发票付款、采购订单、钱包 - 一切都在附近，在一个屏幕上。您想禁用分期付款吗？一个开关。您想更改发票中的详细信息吗？就在这里，就在那里。您想为 YuKassa 启用两阶段付款吗？一键点击。并且没有任何“备用”设置可以覆盖您的更改。
但这不仅仅是为了经理的方便。统一架构提供的技术优势乍一看并不明显。当所有网关都位于一个插件内时，它们使用通用基础设施：通用记录器、通用错误处理系统、通用 WooCommerce 挂钩。这意味着更新 WooCommerce 时，您需要检查一个插件的兼容性，而不是三个。如果出现问题，请调试一个集成点，而不是三个。
还有一个很少被谈论的方面：结账冲突。 WooCommerce 中的结账页面是最薄弱的环节。每个添加自己的结帐逻辑的插件都会增加冲突的可能性。我见过这样的情况：两个支付插件连接了不同版本的同一个 jQuery 库，并且结帐失败 - “支付”按钮没有响应点击。或者当一个插件的 AJAX 处理程序拦截另一个插件的事件时。或者当一个网关的 CSS 破坏了另一个网关的表单显示时。当所有内容都在一个插件中时，此类问题根本不存在。一组脚本、一组样式、一个 AJAX 处理程序。
最后但并非最不重要的一点：更新。每个单独的插件都是一个单独的更新周期。 YuKassa 每月更新一次。 Tinkoff - 每六个月一次（如果你幸运的话）。一些 WooCommerce 发票 - 当作者记得时。每次更新都是潜在问题的根源。您需要检查与当前版本的 WordPress、当前版本的 WooCommerce、当前版本的 PHP 以及所有其他插件的兼容性。当您拥有一个带有内置网关的插件时 - 一项更新、一项检查、一个“更新”按钮。我们在每次发布之前测试所有网关的兼容性。如果 WooCommerce 更新破坏了某些内容，我们会立即修复所有网关，而不是等待每个插件的作者设计发布补丁。
您知道，多年来与 WooCommerce 合作，我得出了一条简单的规则：网站上的插件越少，网站就越稳定。这并不意味着您需要自己编写所有内容并放弃生态系统。这意味着您需要有意识地选择将哪些功能放入单独的插件中，以及将哪些功能放在主工具中更合理。支付网关绝对是最好内置的功能。因为它们对业务至关重要，与订购流程密切相关，并且对冲突极其敏感。
如果我们以不同的方式看待它会怎样？如果我们不将支付网关视为“另一个功能”，而是将其视为电子商务的基础呢？没有付款就没有销售。没有销售就没有生意。这个基础必须尽可能可靠、尽可能可预测、尽可能可控。当您的基础是来自三个不同开发人员的三个独立插件，具有三种不同的更新计划和三种不同的安全方法时，基础就摇摇欲坠了。当基础是您完全控制的单个系统的一部分时，它就很强大。
我并不是说 YuKassa 或 Tinkoff 的单独插件不好。他们解决了他们的问题，而且很多商店都有足够的。但如果您正在构建严肃的电子商务，尤其是使用 B2B 组件，那么插件的数量就会开始对您不利。每个可以在不丢失功能的情况下删除的插件都是迈向更稳定、更快、更易于管理的网站的一步。
实际运作方式：从设置到首次付款
让我告诉您实际的流程是什么样的 - 从安装到实际接受付款。具体来说，没有抽象。
您在 WooCommerce 网站上安装 COS WP Woo。转到模块设置部分“交付和付款” - 这是插件界面中的选项卡之一。查看所有可用的支付网关。每个都有一个开/关开关和一个设置按钮。
让我们从 YuKassa 开始。单击“配置”。输入两个参数：商店 ID 和密钥。您可以从 YuKassa 个人帐户的“集成”部分获取两者。选择付款方式：银行卡、SBP、YuMoney - 单独或全部。如果您想分两步付款，请打开“暂停”开关。指定未确认的保留在多少天后自动取消 - 通常为 7 天，但您可以自行自定义。节省。就是这样，YuKassa 正在工作。
重要一点：YuKassa 的 webhook URL 是自动生成的。您需要从网关设置中复制它，并将其粘贴到您在 YuKassa 的个人帐户的“HTTP 通知”部分中。一次，在初始设置期间。此后，YuKassa 将自动通知您的网站有关付款的状态 - 成功付款、拒绝、退货。 WooCommerce 中的订单将自动更改其状态。经理无需手动监控付款。
Tinkoff 的配置方式类似。终端密钥和密码 - 来自您的 Tinkoff Acquiring 个人帐户。包括标准收购、分期付款 - 或两者兼而有之。如果是分期付款计划，请注明可用的最低订单金额。为五百卢布的商品提供分期付款是没有意义的 - 这看起来很奇怪，并且由于佣金而无法支付。通常最低门槛是三到五千卢布，但这取决于您的业务和利润。 Webhook URL 也会自动生成。保存 - 你就完成了。
现在是 B2B 方法。通过发票付款 - 此处您需要填写您公司的详细信息：组织名称、INN、KPP、OGRN、法定地址、往来账户、BIC、银行名称、代理账户。如果您有图片形式的总监印章和签名，上传它们，它们将自动添加到 PDF 发票中。设置帐号编号模板 - 例如“SCh-{year}-{number}”，每个帐户将收到格式为“SCH-2026-00001”的唯一编号。打开它，结帐时会出现“按发票付款”方式，可供注册的 B2B 用户使用。
当 B2B 客户下订单并通过发票付款时，系统会自动生成发票的 PDF。它包含一切：卖方和买方的详细信息、包含价格和数量的货物清单、总金额、增值税、转账银行详细信息、印章和签名。该文件通过电子邮件发送给客户，并可在其个人帐户中下载。经理还可以在订单卡中看到它，并可以在必要时重新格式化或重新发送。此阶段没有手动工作、没有 Excel、没有 1C。
采购订单甚至更简单：结账时会出现“采购订单编号”字段，客户输入其 PO 编号并下订单。订单在“等待付款”状态下创建，并带有关联的采购订单。经理可以在订单中看到该号码并进行验证。当付款到达时（通过银行集成手动或自动），状态更改为“处理中”。
钱包 - 客户在结账时可以直接看到他的余额。如果资金足够，可以一键支付。如果还不够，他会看到一条有关缺乏资金的消息以及补充钱包的提议。充值通过银行转账到指定的详细信息（指示付款目的中的钱包号码）或通过相同的 YuKassa/Tinkoff 网关进行 - 如果您设置了此选项。余额、交易历史、充值和借记操作 - 客户在其个人帐户中以及管理面板中的经理都可以看到所有内容。
另外，我想谈谈退货 - 这是一个伤害每个在线商店所有者的话题。客户付了钱，后来又改变主意了，钱需要退还。使用单个插件时，返回是一个单独的任务。您需要到订单卡中，找到交易，了解付款经过了哪个网关，进入这个网关的设置，查看是否支持自动退货，或者是否需要通过支付系统的个人账户手动完成。在 COS WP Woo 中，所有网关的退货工作方式均相同 - 单击订单卡中的“退货”按钮，注明金额（全额或部分退款），然后确认。系统本身确定付款经过哪个网关，并通过 YuKassa 或 Tinkoff API 发送退款请求。对于 B2B 钱包，资金会自动返还到您的余额中。要按发票付款，系统会向经理生成一条通知，告知需要通过银行进行手动退款。一切都是透明的，一切都会被记录，不会丢失任何东西。
我认为需要强调的是：所有这些方法都是并行工作的。结帐时，客户可以准确地看到他可以使用的付款方式。一个人看到 YuKassa 和 Tinkoff。 B2B 客户可以通过发票、采购订单、钱包查看付款，如果愿意，还可以通过 YuKassa 或 Tinkoff 用卡付款。方法的可见性通过 B2B 组进行配置 - 您可以向不同的客户组显示不同的付款方式。大型批发商只需要一张发票和一个钱包。对于小型经销商 - 一个帐户和一张卡。对于零售客户 - 卡、SBP 和分期付款计划。充分的灵活性。
老实说，当我第一次在真实的商店中看到这项工作时 - 在我们的一位客户（一位机油分销商）的收银台上 - 我感到了一种专业的满足感。因为这正是我在项目中一直缺少的东西。当一切——个人在线支付、法人实体的自动发票以及常规批发商的内部钱包——都集中在一处，通过一个界面进行控制并按可预测的方式运行时。无需向经理解释“这个按钮在那个插件中，这个按钮在另一个插件中”。当公司搬到新的法定地址时，无需记住需要更改三个地方中的哪一个详细信息。更新 WooCommerce 后无需惊慌 - “如果付款再次出现问题怎么办？”
我经常听到这样的问题：使用现成的插件不是更容易吗？它们是免费的，由支付系统开发商支持，并且不断更新。是的，乍一看这是合乎逻辑的。但说实话：“免费”YuKassa 插件实际上会花费您时间 - 设置时间、调试冲突时间、出现问题时等待更新的时间。 “由开发人员支持” - 形式上是的，但当您在结账时与 WooCommerce 发生冲突时，请尝试从 YuKassa 插件的技术支持中获得答案。我试过了。标准答案是：“禁用所有其他插件并检查。”谢谢你，这很有帮助。 “不断更新” - 检查变更日志以获取最新更新。最常见的是每两到三个月“修复一次小错误”。如果你的问题不是他们的“小错误”，而是与另一个插件的冲突，那么你就永远在排队了。
好吧，我可能听起来太刺耳了。我想说的是：对于一个只有十种产品且仅通过卡支付的简单商店来说，单独的 YuKassa 插件是绝对正常的选择。安装、配置、运行，然后就忘记了。但一旦你的商店发展壮大——B2B客户出现，你需要分期付款，你需要发票，你需要两阶段付款——你就开始用插件悬挂WordPress，就像挂着玩具的圣诞树一样。在某个时刻，树倒下了。
在我看来，正确的方法是从一开始就考虑支付基础设施。不是通过单独的插件“固定”到商店的东西，而是作为电子商务系统的基本组成部分。连同目录、连同交付、连同 CRM 和分析。单一系统-单一责任-单一控制点。
如果您现在面临选择 - 从单独的插件组装支付基础设施或使用单一解决方案 - 我建议您至少尝试第二种选择。不是因为第一个不好，而是因为根据我的经验，第二个可以节省时间、精力和金钱。尤其是当业务增长并变得更加复杂时。
最后，我给大家讲一个故事。我们的客户之一是一家销售工业润滑油和油品的公司，通过该网站拥有大约五百个 B2B 客户和数千个零售客户。在改用 COS WP Woo 之前，他们有四个与支付相关的插件：YuKassa、Tinkoff、某种用于生成发票的插件（顺便说一下，按年订阅付费）以及另一个用于会计处理法人实体付款的插件。总的来说，这四个插件在结账时加载了八个额外的 JS 文件和三个 CSS 文件。在移动设备上，结账页面加载时间为四秒半。过渡后 - 两点多一点。第一个月购物车放弃率下降了 18%。不是因为结帐变得更加美观，而是因为它变得更快。两秒半的差异——之前离开的客户中几乎有五分之一现在等待页面加载并付款。
我不会假装 COS WP Woo 是解决所有电子商务问题的灵丹妙药。每个人都有足够多的问题，而且每天都会出现新的问题。但特别是在接受付款方面 - 特别是如果您需要俄罗斯支付系统加上 B2B - 单一解决方案客观上比一堆单独的插件更好。这不是我的观点——这是数十个项目的经验和数百小时的调试转化为具体的工程解决方案。
试用 COS WP Woo - 免费 14 天。十分钟内安装、配置支付网关，接受第一笔付款。然后与之前的效果进行比较。我认为差异将会很明显。