YuKassa and Tinkoff for WooCommerce: payment without unnecessary plugins

Last week I analyzed the site of one client - a wholesale company, industrial filters, about three thousand items in the catalog, WooCommerce on WordPress. The site is three years old, works fine, but here’s what killed me: twenty-four active plugins. Twenty four. And this is not counting mu-plugins and those that are deactivated “just in case”. Among these twenty-four are two separate plugins for accepting payments. One for YuKassa, the second for Tinkoff. Each with its own settings, its own updates, its own conflicts. The YuKassa plugin was updated six months ago and broke the ordering process on mobile devices - the checkout simply did not load. Two days of downtime while we sorted it out. The Tinkoff plugin was not updated at all for more than a year - and when switching to PHP 8.2, it began to sprinkle deprecated errors in the log for a hundred megabytes per day.

Sound familiar? I'd be surprised if not. Because this is a typical pain for anyone who builds an online store on WooCommerce in Russia. We need Russian payment systems - YuKassa, Tinkoff, SBP. And for each there is a separate plugin with a separate life cycle, separate developers and a separate compatibility history. And if you also have B2B clients who need to issue invoices to a legal entity, welcome to the world of crutches, WooCommerce hooks, redone checkout and sleepless nights.

I thought for a long time why this happens. Why in 2026 accepting payments on a Russian WooCommerce site is a quest. And the answer was obvious: no one thinks about payments as part of a single system. Each payment plugin is a separate microcosm. It has its own tables in the database, its own hooks, its own JavaScript files, which are loaded at checkout. And when these microcosms start colliding with each other within the same WordPress, sparks fly. Style conflicts, duplication of scripts, race conditions when processing callbacks. I saw a site where two plugins tried to process the same webhook at the same time - and the order was marked as paid twice, which broke inventory control.

When we designed the payment module in COS WP Woo, the idea was simple and, it seems to me, correct: payment gateways should be built into the tool that already manages the store. Not as separate plugins, but as part of a single architecture. One plugin - one configuration point - one update. It sounds obvious, but for some reason this is a revolution in the WordPress ecosystem.

And you know what's most surprising? When I discuss this idea with store owners, the first reaction is almost always the same: “Why? That’s how it works for me.” It works until it breaks. Until WooCommerce is updated to the next major version. Until PHP switches to a new version. Until YuKassa changes the API. And then panic begins: the plugin is not compatible, checkout does not work, clients cannot pay, money does not arrive. And at this moment it turns out that the author of the plugin is a developer from Novosibirsk, who updates the code in his free time from his main work. And he has no time now, because he has a deadline on his main project. And you have a store. I don't blame this developer - he does great work, often for free. But depending on one person on an issue that directly affects revenue is a risk that can and should be removed.

Why every extra plugin is not just “another plugin”

Let's talk about what actually happens when you install a separate plugin to accept payments. It's not just files in a folderwp-content/plugins. These are additional queries to the database every time the page is loaded - because WordPress loads the plugin's metadata, checks its status, loads its text domain for translations. These are additional HTTP requests during checkout, because the plugin pulls its CSS and JS files with it. This is an additional point of failure when updating - and anyone who has worked with WooCommerce for more than a year knows that WooCommerce updates like to break plugins with enviable regularity.

But it's not even about performance. It's a matter of controllability. When you have two or three separate payment plugins, you get two or three separate configuration interfaces. YuKassa is configured in one place, Tinkoff in another, manual payment of an invoice in a third. And every time a manager or site owner wants to change something - for example, enable payment in installments through Tinkoff or add a payment method for B2B clients - he needs to remember where everything is. And if it wasn’t him, but a contractor who set it up six months ago, good luck in your search.

I've encountered this dozens of times. A client calls: “Our card payment has disappeared on our website.” You start to figure it out - it turns out that WooCommerce was updated, the YuKassa plugin is not compatible with the new version, and the gateway was automatically deactivated. But the notification about this went to an email that no one reads. And clients at checkout see the only available payment method - bank transfer, which is configured through the standard WooCommerce BACS gateway. And they leave. Because who in their right mind would make a bank transfer when you want to buy a filter for two thousand rubles.

It gets even more fun when a payment system plugin conflicts with something else. I remember a project where the YuKassa plugin conflicted with the multilingual plugin - when switching languages ​​at checkout, the callback URL was lost, and the payment always failed with an error. Or another case: the Tinkoff plugin used its version of the library for working with HTTP requests, which conflicted with WooCommerce Subscriptions. These things are impossible to predict, and they happen at the most inopportune moments - usually on a Friday evening, when advertising is on and traffic is at its peak.

This is why I think it is fundamentally important to remove everything that can be removed from WordPress and consolidate the functionality in one place. Not out of greed - they say, let's cram everything into one plugin and there will be a monolith. No. From engineering common sense. Payment gateways are not rocket science. These are API integrations with clearly documented protocols. YuKassa and Tinkoff have excellent documentation and stable APIs. There is no reason why this should be a separate plugin with a separate life.

What built-in gateways can do: YuKassa, Tinkoff and B2B methods

When I say “built-in payment gateways”, this is what I mean: inside COS WP Woo there is a full implementation of YuKassa, Tinkoff and three B2B payment methods that register as standard WooCommerce Payment Gateways. For WooCommerce, they look exactly the same as its built-in gateways - bank transfer or cash on delivery. They are visible in WooCommerce settings, checkout, and orders. But they are managed from a single interface, tested together, updated together.

Let's figure out what exactly is available and why it is needed.

YuKassa is, in fact, a standard for online payment in Russian e-commerce. If you have an online store on WooCommerce and accept payments from individuals, you need YuKassa. Our built-in gateway supports three main methods: payment by bank cards, the Fast Payment System and YuMoney - an electronic wallet. Why these three? Because they cover ninety-five percent of the scenarios. Cards - for those who are used to paying with Visa or MasterCard (well, or Mir, to be more precise - the year is 2026). SBP is for those who pay through a mobile bank using a QR code, and this method is rapidly gaining popularity, especially for payments up to fifteen thousand rubles. YuMoney is for those who use the YuMoney wallet, and there are also plenty of such people, especially among the audience of 25-40 years old.

Setup takes literally a couple of minutes. Enter your Shop ID and secret key from your YuKassa personal account, choose which methods to activate, and that’s it - the gateway works. No separate plugins, no additional tables in the database, no extra JS files for checkout. Webhook for payment notifications is processed through the standard WooCommerce callback, and the order is automatically transferred to the “Processing” status upon successful payment.

And this is where the fun begins - two-stage payment, also known as holding. This is a feature that few plugins implement properly, and for certain businesses it is critically important. The idea is simple: when paying, the money is not debited from the client’s card, but is blocked and held. The store sees that the payment has gone through and begins assembling the order. And only when the order is actually ready to be shipped does the manager confirm the debit and the money is transferred to the store’s account. If the order is canceled for some reason, the hold is removed, the money is returned to the client automatically, without refund, without unnecessary operations.

Why is this needed? Imagine: you sell industrial equipment. The client orders a pump for four hundred thousand rubles. You check the availability in the warehouse - but it’s not there, you need to order from the supplier, the deadline is three weeks. Without holding, you would write off the money immediately, and then worry for three weeks in case the client changes his mind and demands a refund, but the money is already in circulation. With holding, the money is blocked on the client’s card, you calmly order from the supplier, and are debited only when the goods actually arrive at the warehouse and are ready for shipment. The client is also calm - he sees that the money has not gone away, but has only been frozen. This is a fundamentally different level of trust between buyer and seller.

In our gateway, two-stage payment is enabled with one switch in the settings. After this, all payments through YuKassa are processed in holding mode. The manager can confirm or cancel the payment directly from the order card in WooCommerce - the corresponding buttons appear there. No need to log into your YuKassa personal account, no need to switch between windows. Everything in one place.

Now about Tinkoff. Tinkoff Acquiring is the second most popular payment gateway in Russia after YuKassa, and for certain types of businesses it is even preferable. Firstly, Tinkoff’s acquiring conditions are often better - the transaction fee is lower, especially for medium-sized businesses with a turnover of over a million rubles per month. Secondly, Tinkoff has a built-in installment plan - and this is a killer feature for stores that sell expensive goods.

The built-in Tinkoff gateway in COS WP Woo works on the same principle: enter the Terminal Key and password from your Tinkoff personal account, and the gateway is ready. Standard acquiring is supported - payment by card, and installments - when the client can split the payment over several months without interest. The store pays in installments in the form of a commission from Tinkoff, but for goods costing ten to fifteen thousand rubles, it absolutely pays off - conversion increases by twenty to thirty percent, because it is psychologically easier for the client to pay three thousand a month than to pay fifteen thousand at once.

Tinkoff also supports two-stage payment, and our gateway implements this. The logic is the same: holding, confirmation of debit from the order card, automatic cancellation of the hold when the order is cancelled. Uniformity is important. The manager does not need to remember that confirmation works this way for YuKassa, but differently for Tinkoff. The interface is the same, the buttons are the same, the logic is the same.

But then we move on to what distinguishes COS WP Woo from all other solutions - B2B payment methods. And this, frankly, is the area for which I started writing this article in the first place.

B2B payment: when "payment by card" does not work

If you work only with retail clients - individuals who visit the site, add goods to the cart and pay by card - YuKassa and Tinkoff may be enough for you. But once you start working with legal entities, you find yourself in a completely different world. A world where no one pays by card. Where payment is made by invoice, through the company's bank account. Where from placing an order to the actual receipt of money can take a week, or even two. And where standard WooCommerce gateways are not just inconvenient - they are fundamentally unsuitable.

I've seen companies try to solve this problem. The most common option is that the manager generates an invoice manually in 1C or Excel, sends it to the client by email, and waits. When the money arrives, he manually changes the order status in WooCommerce. If there are five orders a day, it’s tolerable. If fifty is hell. And mistakes are inevitable: they forgot to change the status, they mixed up the order, the invoice was sent with the wrong details.

Another option is the standard WooCommerce BACS (Bank Account/Check Payments). Technically this is a bank transfer. You specify the company details in the settings, the client sees them on the “Thank you for your order” page and in the email. But this is text information - no normal counting. No buyer details. No automatic document generation. For B2B this is simply not serious. When an accountant of the purchasing company receives an email with the text “Transfer 47,800 rubles to such and such’s current account,” he will be at least surprised. He needs a normal account - with a tax identification number, checkpoint, legal address, bank details, seal and signature. A document that can be printed, filed in a folder and presented for inspection.

In COS WP Woo, we have implemented three payment methods for B2B, and each solves a different problem.

The first is payment by invoice, Invoice Gateway. This is exactly what most B2B companies need. At checkout, the client selects “Payment by invoice”, indicates the details of his company - or they are pulled up automatically from his profile if he is already registered as a B2B user. After placing an order, the system automatically generates an invoice for payment - a full-fledged document with the details of the seller and buyer, invoice number, date, list of goods, amount and bank details. This invoice can be downloaded in PDF format directly from your personal account or from an email notification. The manager can resend the invoice if the client has lost the letter. When payment arrives, the order status changes and the client receives a notification.

Here's the thing: it's not just a text template. This is a real document that is generated based on order data. The seller’s details are taken from the settings - INN, KPP, OGRN, legal address, bank details. Buyer details - from the user profile or from the checkout fields. The account number is generated automatically taking into account the numbering that you have configured. I know that this sounds like a trifle for accounting, but when there are a hundred such accounts generated per month, automation saves tens of hours.

The second method is Purchase Order, or order for payment. This is a freer form of B2B payment, which is common in international practice and is increasingly found in large Russian companies. The bottom line: the buyer indicates the number of his internal purchase order - Purchase Order number, or PO. This is a document that has been agreed upon within the purchasing company, and according to which payment will be made. For the seller, this means that the order has been confirmed, payment will be made - but not now, but after the buyer processes the documents at home. Typically the payment period is from fourteen to thirty days.

This method is especially in demand in industrial companies, where purchases go through several approval stages. The purchasing manager creates a request, the head of the department approves, the financial director signs, and the accounting department generates the payment. This entire process may take two to three weeks. And all this time, the order hangs in WooCommerce in the status “Waiting for payment” with an associated PO number. The seller's manager sees this number and knows that payment is in progress. And when the money arrives, he confirms the order.

The third method is the internal wallet, Wallet Gateway. This is a completely separate story, and, in my opinion, it is underestimated. The bottom line: for each B2B client, an internal balance is created in the system - a wallet. The client can top it up by bank transfer for any amount - for example, a million rubles. And after that, pay for orders instantly - money is debited from your wallet balance, without waiting for a bank transfer, without generating an invoice for each order.

Why is this needed? Imagine a large wholesale client who makes twenty to thirty orders a month. Each order means generating an invoice, waiting for payment, and checking receipt. With twenty orders per month, that means twenty invoices, twenty payments, twenty banking days of waiting. And with a wallet: one transfer for the total amount, and then the client pays for orders instantly, in one click. The balance is seen by both the client in his personal account and the manager in the admin panel. All transactions are logged - deposits, debits, returns. Transparent for both the seller and the buyer.

I spoke with the owner of a company that sells spare parts for special equipment. They have two hundred regular B2B clients, and each makes between five and fifteen orders per month. When they introduced the internal wallet system, the accountant literally shed tears - instead of one thousand two hundred accounts per month, there were two hundred deposits. The workload dropped sixfold. And at the same time, clients began to order more often - because payment is instant, there is no need to wait for approval every time.

All three B2B methods are integrated into a single B2B sales module COS WP Woo. They work in conjunction with customer groups, custom pricing, minimum order quantities, and other B2B features. This is not an add-on on the side - it is part of a single system where everything is connected and everything works together.

Payment security: what people usually don’t think about before the first incident

Since we're talking about payment gateways, we can't ignore the topic of security. And I’m not talking about PCI DSS and certification now - this is the responsibility of YuKassa and Tinkoff themselves, card data is processed on their side, and the WooCommerce store never sees the client’s card number. I'm talking about something else - about the security of the integration itself.

Every WordPress payment plugin is a potential entry point. It has a callback URL to which the payment system sends notifications. This URL is accessible from the Internet - otherwise how will YuKassa inform your site that the payment has gone through? And this URL needs to be protected. You need to check the request signature, you need to validate the sender's IP address, you need to check that the amount and order number match what is stored in the database. If you don’t do this, an attacker can send a fake request to your callback URL and “confirm” payment for an order that no one paid for. The goods will go to the scammer, but the money will not.

Sound paranoid? In theory - yes. In practice, I know of at least three cases when this is exactly what happened. In one case, the payment system plugin verified the request signature, but did not verify the amount. The attacker created an order for one hundred thousand rubles, and then sent a fake callback with the amount of one ruble - and the signature was valid because he used his test account of the payment system. The order has changed to “paid” status. The manager shipped the goods. The loss is one hundred thousand rubles minus one ruble.

When gateways are built into a single system, security is not the responsibility of the individual plugin author, but part of the overall architecture. In COS WP Woo, all callback handlers go through a single validation layer: signature verification, amount verification, order compliance verification, IP address verification (for YuKassa - the Yoomoney IP range, for Tinkoff - their server range). All suspicious requests are logged in the activity system. If someone is trying to fake a webhook, you will know about it from the log, and not from a call from an angry client.

Another aspect of security that few people think about is API key storage. Shop ID and secret key YuKassa, Terminal Key Tinkoff - these are, in fact, the keys to your current account. If someone gains access to them, they can redirect payments to another account. And here it is important how the plugin stores this data. Most plugins store keys in clear text inwp_options- Standard WordPress settings table. This means that any other plugin with access to the database (and in WordPress, that's basically any plugin) can read your keys. In COS WP Woo, secret keys are stored encrypted and hidden in the interface - you only see the last four characters. When making a GET request to the settings API, the keys are never returned in clear text. This is not paranoia - this is basic hygiene.

Single point of configuration - and why it's more important than it seems

I've spent a lot of time explaining to clients why consolidating payment gateways into one place is not a marketing gimmick, but an engineering necessity. And every time the arguments are the same, but people need time to feel it.

Here is a typical situation. The company has three payment methods on its website: YuKassa for individuals, Tinkoff for installments and manual bank transfer for B2B. Three different plugins, three different settings. The manager wants to temporarily disable the installment plan because the promotion has ended and the conditions have changed. He goes to WooCommerce → Settings → Payments. Sees a list of gateways. Finds Tinkoff. Clicks "Manage". Goes to the Tinkoff plugin settings page. Disables installment plans. Saves. Ready? Almost - but he forgot that the Tinkoff plugin has a separate settings page in the main WordPress menu, and there is also an installment switch there. And they are not in sync. Two hours later he checks - installment plans are again available at checkout. Because the setting from the main menu of the plugin overwrote the setting from WooCommerce Payments.

Sound like a joke? This is a true story. And I have dozens of similar stories.

In COS WP Woo, all payment gateways are configured in one place - on one tab, in one interface. YuKassa, Tinkoff, invoice payment, Purchase Order, wallet - everything is nearby, on one screen. Do you want to disable installments? One switch. Do you want to change the details in your invoice? Right here, right there. Do you want to enable two-stage payment for YuKassa? One click. And there are no "alternate" settings that can overwrite your changes.

But it's not just about convenience for the manager. A unified architecture provides technical advantages that are not obvious at first glance. When all gateways live inside one plugin, they use a common infrastructure: a common logger, a common error handling system, common WooCommerce hooks. This means that when updating WooCommerce, you need to check the compatibility of one plugin, not three. And if something goes wrong, debug one integration point, not three.

There is another aspect that is rarely talked about: checkout conflicts. The checkout page in WooCommerce is the weakest point. Each plugin that adds its own checkout logic increases the likelihood of a conflict. I have seen situations where two payment plugins connected the same jQuery library of different versions, and the checkout broke - the “Pay” button did not respond to the click. Or when the AJAX handlers of one plugin intercepted the events of another. Or when the CSS of one gateway broke the display of the form of another. When everything is inside one plugin, such problems simply do not exist. One set of scripts, one set of styles, one AJAX handler.

Last but not least: updates. Each individual plugin is a separate update cycle. YuKassa is updated once a month. Tinkoff - once every six months (if you're lucky). Some WooCommerce Invoice - when the author remembers. And every update is a potential source of problems. You need to check compatibility with the current version of WordPress, with the current version of WooCommerce, with the current version of PHP, with all other plugins. When you have one plugin with built-in gateways - one update, one check, one “Update” button. We test the compatibility of all gateways before each release. And if a WooCommerce update breaks something, we fix all the gateways at once, rather than waiting for the author of each individual plugin to deign to release a patch.

You know, over the years of working with WooCommerce, I have come to a simple rule: the fewer plugins on the site, the more stable the site. This does not mean that you need to write everything yourself and abandon the ecosystem. This means that you need to consciously choose which functions to put into separate plugins, and which ones are more reasonable to have inside the main tool. Payment gateways are definitely a functionality that is better to have built-in. Because they are business critical, closely tied to the ordering process, and extremely sensitive to conflicts.

What if we look at it differently? What if we perceive payment gateways not as “another feature”, but as the basic foundation of e-commerce? Without payment there are no sales. Without sales there is no business. And this foundation must be as reliable as possible, as predictable as possible, as controllable as possible. When your foundation is three separate plugins from three different developers with three different update schedules and three different approaches to security, the foundation is shaky. When the foundation is part of a single system that you control entirely, it is strong.

I'm not saying that separate plugins for YuKassa or Tinkoff are bad. They solve their problem, and many stores have enough of them. But if you are building serious e-commerce, especially with a B2B component, the number of plugins begins to play against you. And every plugin that can be removed without losing functionality is a step towards a more stable, faster, more manageable site.

How it works in practice: from setup to first payment

Let me tell you what the process looks like in practice - from installation to actually accepting payments. Without abstractions, specifically.

You install COS WP Woo on your WooCommerce site. Go to the module settings section “Delivery and payment” - this is one of the tabs in the plugin interface. See all available payment gateways. Each with an On/Off switch and a setting button.

Let's start with YuKassa. Click “Configure”. Enter two parameters: Shop ID and secret key. You take both from your YuKassa personal account - the “Integration” section. Choose payment methods: bank cards, SBP, YuMoney - individually or all together. If you want two-stage payment, turn on the “Holding” switch. Specify after how many days an unconfirmed hold is automatically canceled - usually seven days, but you can customize it for yourself. Save. That's it, YuKassa is working.

Important point: the webhook URL for YuKassa is generated automatically. You need to copy it from the gateway settings and paste it into your personal account at YuKassa, in the “HTTP notifications” section. Once, during initial setup. After this, YuKassa will automatically notify your site about the status of payments - successful payment, refusal, return. An order in WooCommerce will automatically change its status. The manager does not need to monitor payments manually.

Tinkoff is configured in a similar way. Terminal Key and password - from your Tinkoff Acquiring personal account. Include standard acquiring, installments - or both. If installment plan, indicate the minimum order amount at which it is available. There is no point in offering installments for goods for five hundred rubles - it looks strange and does not pay off due to the commission. Usually the minimum threshold is three to five thousand rubles, but it depends on your business and margins. Webhook URL is also generated automatically. Save - you're done.

Now B2B methods. Payment by invoice - here you need to fill in the details of your company: name of organization, INN, KPP, OGRN, legal address, current account, BIC, bank name, correspondent account. If you have the director's seal and signature in the form of images, upload them, they will be added to the PDF invoice automatically. Set up an account numbering template - for example, “SCh-{year}-{number}”, and each account will receive a unique number in the format “SCH-2026-00001”. Turn it on, and the “Payment by invoice” method appears on the checkout, available for registered B2B users.

When a B2B customer places an order with payment by invoice, the system automatically generates a PDF of the invoice. It contains everything: details of the seller and buyer, a list of goods with prices and quantities, total amount, VAT, bank details for transfer, stamp and signature. This document is sent to the client by email and is available for downloading in his personal account. The manager also sees it in the order card and can reformat or resend it if necessary. No manual work, no Excel, no 1C at this stage.

Purchase Order is even simpler: the “Purchase Order Number” field appears at checkout, the client enters his PO number, and places an order. The order is created in the status “Waiting for payment” with an associated PO. The manager sees this number in the order and can verify it. When the payment arrives - manually or automatically through banking integration - the status changes to “Processing”.

Wallet - here the client sees his balance directly at checkout. If there are enough funds, you can pay in one click. If it is not enough, he sees a message about a lack of funds and an offer to replenish the wallet. Replenishment occurs through a bank transfer to the specified details (indicating the wallet number in the payment purpose) or through the same YuKassa/Tinkoff gateway - if you set up this option. Balance, transaction history, replenishment and debit operations - everything is visible to both the client in his personal account and the manager in the admin panel.

Separately, I would like to say about returns - this is a topic that hurts every online store owner. The client paid, then changed his mind, the money needs to be returned. When working with individual plugins, returning is a separate quest. You need to go to the order card, find the transaction, understand which gateway the payment went through, go to the settings of this gateway, check whether it supports automatic returns or whether it needs to be done manually through your personal account of the payment system. In COS WP Woo, returns work the same way for all gateways - click the “Return” button in the order card, indicate the amount (full or partial refund), and confirm. The system itself determines which gateway the payment went through and sends a request for a refund via the YuKassa or Tinkoff API. For a B2B wallet, money is returned to your balance automatically. To pay by invoice, a notification is generated to the manager about the need for a manual refund through the bank. Everything is transparent, everything is logged, nothing is lost.

And here's what I think is important to emphasize: all these methods work in parallel. At checkout, the client sees exactly those payment methods that are available to him. An individual sees YuKassa and Tinkoff. A B2B client sees payment by invoice, Purchase Order, wallet - and, if he wants, can also pay by card through YuKassa or Tinkoff. Visibility of methods is configured through B2B groups - you can show different payment methods to different groups of customers. Large wholesalers only need an invoice and a wallet. For small dealers - an account and a card. For retail customers - card, SBP and installment plan. Full flexibility.

Honestly, when I first saw this work in a real store - at the checkout of one of our clients, a motor oil distributor - I felt something like professional satisfaction. Because this is exactly the thing that I always lacked in projects. When everything - online payment for individuals, automatic invoices for legal entities, and internal wallets for regular wholesalers - lives in one place, is controlled from one interface and works predictably. There is no need to explain to the manager that “this button is in that plugin, and this one is in another.” There is no need to remember in which of the three places you need to change the details when the company moves to a new legal address. There is no need to panic after updating WooCommerce - “what if something breaks in payments again?”

I often hear the question: isn’t it easier to use ready-made plugins? They are free, supported by payment system developers, and constantly updated. And yes, at first glance this is logical. But let's be honest: the “free” YuKassa plugin actually costs you time - time to set up, time to debug conflicts, time to wait for updates when something breaks. “Supported by developers” - formally yes, but try to get an answer from the technical support of the YuKassa plugin when you have a conflict with WooCommerce at checkout. I tried it. The standard answer is: “Disable all other plugins and check.” Thank you, it helped a lot. "Constantly updated" - check the changelog for the latest updates. Most often this is “fixed minor errors” once every two to three months. And if your problem is not their “minor errors”, but a conflict with another plugin, you are in line for eternity.

Okay, I probably sound too harsh. Let me say this: for a simple store for ten products with payment only by card, the separate YuKassa plugin is an absolutely normal choice. Install, configure, it works, forget. But as soon as your store grows - B2B clients appear, you need installments, you need invoices, you need two-stage payment - you start hanging WordPress with plugins like a Christmas tree with toys. And at some point the tree falls.

It seems to me that the right approach is to think about the payment infrastructure from the very beginning. Not as something that is “screwed” to the store with separate plugins, but as a fundamental part of the e-commerce system. Together with the catalogue, together with delivery, together with CRM and analytics. Single system - single responsibility - single point of control.

And if you are now faced with a choice - to assemble a payment infrastructure from separate plugins or use a single solution - I would advise you to at least try the second option. Not because the first one is bad, but because the second one, in my experience, saves time, nerves and money. Especially when the business grows and becomes more complex.

Finally, I’ll tell you one story. One of our clients is a company that sells industrial lubricants and oils, about five hundred B2B clients and several thousand retail customers through the website. Before switching to COS WP Woo, they had four payment-related plugins: YuKassa, Tinkoff, some kind of plugin for generating invoices (paid, by the way, with an annual subscription) and another one for accounting for payments from legal entities. In total, these four plugins loaded eight additional JS files and three CSS at checkout. The checkout page load time is four and a half seconds on mobile. After the transition - a little over two. Cart abandonment rates dropped eighteen percent in the first month. Not because checkout has become more beautiful - because it has become faster. Two and a half seconds difference - and almost every fifth client who previously left now waits for the page to load and pays.

I won't pretend that COS WP Woo is a magic pill for all e-commerce problems. There are enough problems for everyone, and new ones will appear every day. But specifically when it comes to accepting payments - especially if you need Russian payment systems plus B2B - a single solution is objectively better than a zoo of separate plugins. This is not my opinion - this is the experience of dozens of projects and hundreds of hours of debugging that turned into concrete engineering solutions.

Try COS WP Woo - 14 days free. Install, configure payment gateways in ten minutes, accept the first payment. And then compare with how it worked before. I think the difference will be obvious.