In production at Ramen Nagomi and Padi Los Angeles.

The free version of RestoPick handles the everyday case. Pickup date, pickup time, weekly schedule, closed dates. If a restaurant has one menu and stable hours, it’s enough.

Pro is what happened when real restaurants started using it.

Almost every feature in Pro exists because someone running a kitchen sent me a message that started with “is it possible to…” or “we keep having to manually…”. I’d look at what they were doing, look at where the free plugin stopped, and decide whether the gap was big enough to be its own feature. Sometimes it was. This post is the catalogue of those gaps.

Menu Hours

The most-requested one.

Some menus are time-bound — a breakfast menu only available 6–10 am, weekend brunch only on Saturday and Sunday, dinner specials only after 5 pm. The free plugin’s hours apply to the whole restaurant, so a customer can drop pancakes in their cart at 8 pm and the checkout will happily accept a 9 pm pickup. That bug surfaced about a week into the first restaurant going live.

In Pro, every product or category can declare its own pickup window. The checkout time dropdown narrows live based on what’s in the cart, and if multiple products with different windows are in the same cart, the dropdown shows the intersection.

The bit I like: when the cart contains nothing time-bound, the narrowing script never even loads. Customers whose order isn’t affected pay nothing for the feature.

Recurring Closed Days

The free plugin stores closed dates as a flat list. That works for “Christmas Day” and “the day the renovation finishes”. It doesn’t work for “every Monday for the next two years” — nobody wants to hand-type 104 Mondays.

Pro adds three rule types — weekly, monthly nth-weekday (“every first Sunday”), and yearly — and expands them on demand into the same list the free plugin already uses:

add_filter( 'restopick_pickup_closed_dates', array( $this, 'inject_dates' ), 10, 3 );

Rules expand only within the window the calendar is actually asking about, so runtime cost stays proportional to “how far forward does the checkout look”, not “how many rules has the owner configured”. The free side doesn’t know or care that the dates came from a rule. Clean handoff.

Tips at checkout

Restaurants where servers and runners rely on tips wanted a tipping flow that wasn’t another plugin to install and configure. So there’s a Tip section with configurable preset percentages plus a custom amount.

The tip is written as a WooCommerce fee — which means every report, every email, and every payment gateway that already understands WC fees handles it correctly without me writing a parallel system. When orders are paid through the companion Square gateway, tips are recognised by fee name (“Tip” / “Gratuity”) and routed through Square’s Payment.tip_money so they show up in the right place for accounting.

The shortcode

The free plugin renders pickup fields inside the WooCommerce checkout. Most of the time that’s exactly where they belong.

A few restaurants wanted the pickup time picked before the customer commits to a cart — on a landing page, in a popup, on a custom layout. Pre-committing to a slot tends to lower checkout abandonment (you’ve already invested in the choice) and lets the menu reflect what’s available for that slot.

Pro adds [restopick_form], which renders the same fields with the same validation, sharing session storage with the WC checkout. A date picked in a popup carries through to checkout without re-entry.

Auto-print kitchen tickets

This was the feature that solved an actual daily pain point.

Some kitchens work off printed dockets, full stop. When a pickup order came in through WooCommerce, someone in the office had to open the admin, find the order, click the printer icon, and walk the docket to the kitchen. Sometimes orders were missed. Sometimes the same order got printed twice because two people both saw it.

Pro can send a plain-text ticket to a thermal printer the moment an order transitions to processing or completed — via PrintNode (the cloud-print service that works with most ESC/POS printers) or a generic webhook to whatever bridge the restaurant has.

The runtime is built around two things I cared about:

1. It must not print twice. A status transition from processing to completed looks like two events to WordPress; both shouldn’t print. An order-meta flag pinned the moment one successful print happens is the entire mechanism.
2. It must retry without burying failures. A jammed printer or a flaky network shouldn’t silently swallow a ticket. Exponential backoff retries via WP cron — 1 minute, 5 minutes, 15 minutes — with an admin email when retries are exhausted and a per-order log surfaced in the admin. Every attempt is visible.

For restaurants whose workflow is “tickets come out of the kitchen printer, period”, this is the feature that removed a manual touchpoint. The owner stops being the printer.

Square Connection

Pro hosts a Square Connection sub-page that owns one thing: your Square credentials. Application ID, Access Token, Location ID — both sandbox and production sets, with a mode toggle on top and a Test Connection button that pings /v2/locations and confirms the configured location’s currency matches WooCommerce. A 30-second sanity check before you push real orders.

This page exists because Pro doesn’t actually take payments. The companion RestoPick Square Payment gateway does — and it needs credentials at checkout time. Centralising them in Pro means the gateway plugin doesn’t ask for the same Application ID / Access Token / Location ID a second time. One source of truth, one place to rotate keys, one place to flip sandbox / production.

Switching mode from sandbox to production (or back) triggers a confirmation dialog before save. The consequence is “future orders use the new mode’s credentials” — and that’s not the kind of thing you want to fat-finger.

The mode also gets stamped onto every order’s meta at payment time. So a refund issued six months later resolves to the right Square account by reading that stamp, not whatever mode the admin currently has selected. An order placed in sandbox stays refundable against sandbox credentials even after the admin has flipped to production.

One thing Pro used to do and doesn’t anymore: earlier versions shipped a separate Square POS Sync sub-page that pushed WooCommerce orders paid via non-Square gateways (Stripe, PayPal, COD) into Square POS as a post-checkout dispatch. I removed it in 1.5.0. The use case turned out to be rare in practice — operators who actually want orders to appear on the kitchen iPad universally take Square payments at checkout, which the companion gateway handles cleanly without the extra sync step. One less moving part, fewer failure modes to babysit.

REST API

A tiny endpoint to flip pickup on or off remotely, authenticated with a Bearer token:

POST /wp-json/restopick/v1/pickup/disable
Authorization: Bearer <token>

Useful in two scenarios: a POS or kiosk integration needs to disable online pickup the moment the kitchen hits capacity, or staff need to pause pickup from the floor without logging into WordPress. Every request is logged with timestamp and originating IP, surfaced in the admin sub-page next to the token-management UI.

License management

Standard issue. Enter a key, the plugin validates, rechecks every 24 hours. The recheck is async on purpose so a slow license server can never block an admin or front-end request. An inactive license disables the Pro features but leaves the free plugin running normally — the site doesn’t break, it falls back.

What I noticed writing it

Most of Pro is “the boring obvious thing, done carefully”. Idempotent operations. Async retries. Filters and hooks so the free side stays clean. Every paid feature is a yes/no toggle, and the ones you don’t enable stay completely out of the way.

If two of the scenarios above describe your restaurant, Pro probably pays for itself in a month of saved admin work. If none of them do, the free version is already what you need.