one question · one answer
How to bring WooCommerce and Telegram orders together
Pick the direction first: either Telegram writes into WooCommerce, or both write into a third place. Making WooCommerce the system of record is cheaper and works if Telegram is a small side channel — a bot posts the order into Woo through the REST API and everything stays in one admin. Once Telegram is a real share of revenue, that breaks down, because Woo has no idea what a chat conversation is; then you want a third place that both feed, and Woo becomes one source among several.
Whichever direction you choose, deduplicate on a stable key from day one. The failure everybody hits is the same order arriving twice — once by webhook, once by the retry — and quietly doubling the day's revenue.
Option one — Telegram writes into WooCommerce
A bot takes the order in chat and creates it through the WooCommerce REST API. One admin, one order list, reports that already work, and no new subscription. This is the right answer more often than vendors admit.
It stops working when the chat carries anything Woo cannot hold: a conversation, a negotiated price, a regular who orders "the usual". You end up storing meaning in order notes, and order notes are a text field nobody can report on.
Option two — an automation platform in the middle
Zapier or Make can wire Woo and a Telegram bot to a sheet or a CRM in an afternoon, and for a low volume of orders it is genuinely fine.
Two things to know before you build your business on it. Per-task pricing turns unfriendly at delivery volumes — every order is several tasks. And when a step fails at 9 p.m. on a Saturday, it fails silently: the order is simply not there, and you find out from the customer. Automation platforms are excellent glue and poor infrastructure.
Option three — a third place that takes both
Both channels feed one system, and that system is the record. Woo arrives by webhook; Telegram arrives through the bot. Reports, customer history and money are computed once, across both.
The cost is a subscription and a real decision — you now have a system of record that is not your shop admin, and everyone has to accept that. The gain is that "how many orders did we take yesterday" has exactly one answer.
The part everybody gets wrong
Deduplication. WooCommerce sends a webhook; the webhook occasionally does not arrive, so any sane integration also polls; and now the same order can enter twice. If your dedup key is the timestamp or the customer name, you will lose orders or double them, and both are worse than having no integration at all.
Use the source's own order id, keep it on the record, and hash the canonical row. Then check the count against the Woo admin for a week before you trust anything.
Where Ovirno fits, and where it doesn't
Ovirno is option three, with the dedup already done: WooCommerce comes in by webhook in seconds and is re-pulled every five minutes as a safety net, repeat rows are deduplicated by a hash of the canonical row, and every record keeps a reference to where it came from. The Telegram bot both answers questions and posts new-order cards per location. Sheets, CSV, Excel, bank statements and your own webhook come in the same way.
Where it does not fit: it is not a WooCommerce plugin and it does not write back into Woo. Orders flow into Ovirno, not out of it. If what you want is for the Telegram order to appear inside your WooCommerce admin, option one is your answer and you should not buy ours.
If this sounds like your situation, the way to find out is not a demo of somebody else's data: send one export of your sales and thirty minutes later you are looking at your own business, with observations computed from your own numbers. Ask for that, or write on Telegram — the person who answers is the one who builds the thing.
Asked before every one of these
Does Ovirno write orders back into WooCommerce?
No. Data flows from WooCommerce into Ovirno. If you need Telegram orders to appear inside the Woo admin, a bot writing through the Woo REST API is the right approach instead.
How fast do WooCommerce orders appear?
In seconds by webhook, with a pull every five minutes as a fallback in case the webhook did not make it.
What stops the same order being counted twice?
Deduplication by hash of the canonical row, plus the source's own order id kept on the record. That is what makes the webhook-plus-polling combination safe.