Order printing rarely appears in a brief. It appears three weeks after launch, when the client says "we keep missing orders because nobody watches the screen". It is a half-day of work that changes how the client experiences the site every single day, which makes it one of the better things an agency can add.
The short answer: treat the printer as infrastructure the client owns, keep your integration to a webhook and an HTTP call, and draw the support boundary at the network. Agencies that instead install a print client on a machine in the client's back office end up owning that machine forever.
Why this is good agency work
High perceived value per hour. The integration is small: a webhook handler or a connector configuration. The daily impact is large and visible. Few features have that ratio.
It reveals the next project. A client who now prints kitchen tickets automatically will ask about delivery-platform orders, then about multi-site reporting. Printing is often the door.
It is recurring, not one-off. Hardware, plan and occasional reconfiguration make it a line item that renews, rather than a project that ends.
The architecture that does not come back to bite you
The decision that determines your support load for the next three years is whether something has to run on the client's premises.
| Approach | What is at the client | Who supports it |
|---|---|---|
| Print client on a back-office PC | An OS, a session, updates | You, forever |
| Cloud printer (4G/Wi-Fi/Ethernet) | A printer | The hardware vendor |
| Existing USB printer + Pi adapter | A dedicated appliance | The hardware vendor |
A print client on the client's computer means that every Windows update, every antivirus policy, every "we replaced the old PC" becomes a ticket for you. A printer that holds its own connection has no session to expire and no desktop to log into. For a client site you visit twice a year, this is the whole game.
The 4G option deserves particular attention: in premises where you do not control the router (a franchise, a shared building, a food court), a printer with its own SIM removes the client's IT from your dependency chain entirely.
Deploying across accounts
One account per client, not one account for all clients. Billing stays with the client, credentials do not leak between accounts, and offboarding is clean. The temptation to centralise everything under the agency's account is strong and creates a problem the day a client leaves.
Keep the printer id in configuration, never in code. Same codebase, different environment variable. This sounds obvious and is routinely violated in agency work, usually in a rush.
Standardise the ticket template once. Build one layout (header with the shop name and logo, order reference, line items, total, cut), and reuse it. See the receipt layout reference.
Use the connector when nothing custom is needed. For a straightforward Shopify or WooCommerce store, the connector is faster to deploy and leaves you less to maintain. Write custom code only where the routing logic actually requires it.
Pricing it
Three models work, in increasing order of maturity:
- Setup fee, client pays the subscription directly. Simplest, and the cleanest support boundary. You bill the integration once.
- Setup plus a monthly maintenance line. You keep the relationship and a small recurring revenue for reconfiguration and monitoring.
- Resale. You own the account and rebill. Higher margin, but you also own the first-line support and the billing relationship: only do this deliberately.
Whichever you choose, exclude the client's network from the contract explicitly. "Printing stopped" is a networking problem far more often than a code problem, and an ambiguous scope means you are debugging someone's router for free.
The three failure modes to pre-empt
Nobody defined what happens when the printer is offline. Decide up front: queue, retry, or alert someone. Then implement the alert. This is the difference between "the printer was out of paper for two hours" and "we lost forty orders and did not know".
Emoji in product names. Thermal printers speak ESC/POS. A product title with an emoji can produce garbage or drop the connection. Transliterate before sending: a one-line fix that prevents a category of support calls.
Double printing on webhook retries. Platforms retry when your endpoint is slow. Respond immediately, print asynchronously, and pass the order id in origin so duplicates are detectable.
Getting started
The technical guides cover the integration per platform: Shopify, WooCommerce, PrestaShop and Zapier, Make or n8n for everything else.
If you deploy this across several clients, the agency partner programme exists for exactly that case.
FAQ
How long does it take an agency to add order printing to a client site?
Half a day for a standard Shopify or WooCommerce store using a connector, and roughly a day if custom routing logic is needed. The integration itself is a webhook handler and one HTTP call.
Should the agency or the client own the printing account?
One account per client is cleaner: billing stays with the client, credentials never leak between accounts, and offboarding is simple. Reselling under the agency's account is viable but means owning first-line support.
How do I avoid inheriting endless support?
Do not install anything on the client's computers. A printer that holds its own connection has no OS, session or updates to maintain. Then exclude the client's network from the contract explicitly.
What should I charge for it?
Common models are a one-off setup fee with the client subscribing directly, setup plus a monthly maintenance line, or full resale. The first has the cleanest support boundary, the last the best margin.
What breaks most often in production?
Emoji in product names, duplicate tickets from webhook retries, and nobody having defined what happens when the printer is offline. All three are cheap to pre-empt and expensive to discover later.