What it does

mam-woocommerce-delivery turns the mobile app into a working surface for delivery drivers of a WooCommerce store. It adds:

• A driver user role and an on/off-duty (punch in/out) flow. A user with the driver role gets a dedicated home screen in the app. When the driver has no active trip, the home screen shows a Go on Duty / Go off Duty button; punching in marks the driver as available so vendors see “(Available)” next to their name when assigning orders.
• An available-orders board with an atomic claim flow. Orders that are waiting for a driver appear in the WC Delivery Available Orders list. Until a driver claims an order, browsing drivers see a non-PII summary (order number, date, item count, pickup location title) — customer name, address, phone, email, and GPS coordinates are only shown to the order’s vendor staff or a store manager. Claiming is atomic: a per-order lock guarantees that when two drivers tap “claim” at the same moment, exactly one wins and the other is rejected.
• A transport-status ladder that routes every order from acceptance to completion, with a separate ladder for delivery and pickup orders (see below). Each tap of the status button on an order advances it one rung.
• Customer notifications per status. Every stage that matters to the customer fires a notification through MAM’s notification manager (mam_notification_send_message) — driver assigned, order en route, delivered, ready for pickup, picked up. The notification texts are configured in the MAM notifications screen against this plugin’s slugs.
• Delivery-area / zip-code validation. The app’s checkout can ask “do you deliver here?” The answer comes from a polygon drawn on a map, a zip-code allow-list, or the vendor’s Product Vendors service radius — selectable per site.
• Pickup/delivery selectors at web checkout. Location, date, and time dropdowns on the WooCommerce checkout page, fed by per-location weekly time slots.
• DoorDash hand-off. Instead of assigning an in-house driver, a vendor can dispatch the order to DoorDash; the mam-doordash-delivery plugin picks up the request and pushes status updates back into the same transport ladder.
• Cron-driven reminders. Two scheduled tasks notify administrators when no driver has accepted an order, and notify the vendor when an order is due to start soon.

The plugin is HPOS-compatible: it declares WooCommerce custom_order_tables compatibility and performs all order reads/writes through the WooCommerce CRUD and wc_get_orders() APIs, so it works identically on legacy post storage and High-Performance Order Storage.

The transport-status ladders

Each order carries a transport_status order meta. The ladder it walks depends on the order’s location_type meta (delivery or pickup). Tapping the action button at a stage fires that stage’s customer notification and advances the order to the next stage; completing the final stage marks the WooCommerce order Completed.

Delivery routing:

Pickup routing:

Advancement happens through the mam_check_in app action (or mam_wc_pv_complete_order_check_in from the Product Vendors order screens). Third-party services advance orders server-side via the mam_wc_delivery_set_delivery_status action. Authorization is enforced at every advance: only the assigned driver, the order’s vendor staff, or a store manager may move an order (see Hooks: transport authorization).

Where it appears in the app

Settings

All settings live on Mobile App Manager → WooCommerce Settings → Delivery tab:

The web checkout selectors are additionally gated by the mam_show_wc_delivery_on_web option (no admin UI in this plugin; set via option or a sibling plugin).

Setup paths

1. Install and activate mam-main (1.9.1+) and WooCommerce; the plugin returns early without either. The entitlement filter mam_plugin_entitlement must return a non-blocked record for mam-woocommerce-delivery.
2. (Recommended) Activate WooCommerce Product Vendors and mam-woocommerce-product-vendors — vendor ownership, the vendor order screens, and driver assignment selectors all use the Product Vendors data.
3. Create driver accounts and give them the driver role (registered automatically). The role is also added to mam_wc_pv_staff_roles so vendors can manage drivers.
4. Configure the Delivery settings tab and the notification texts (Mobile App Manager → Notifications; all slugs are pre-registered).
5. Add the WC Delivery Available Orders and WC Delivery Open Orders content to the app where drivers should see them; drivers automatically get the driver home screen.
6. (Optional) Configure delivery areas — see Recipe: Configure delivery areas.
7. (Optional) Activate mam-doordash-delivery for the DoorDash hand-off.

Key concepts to know

• driver role — a subscriber-capability role registered on init; the app keys the entire driver experience off it.
• transport_status order meta — the single source of truth for where an order is in its ladder; transport_status_<stage> metas record the timestamp of each advance.
• pv-location CPT (Store Location) — per-vendor locations with address, geocoded lat/lon, truck/driver slots, and weekly delivery time slots; feeds the checkout date/time selectors.
• Punch state — tsl_activity_user_is_punched_in user meta (1 = on duty, 2 = off duty) plus tsl_activity_user_active_date (site-local date); toggled by the duty button.
• Atomic claim — claiming writes assigned_to_driver under a per-order lock so double-claims are impossible.

Related articles

• Recipe: Set up delivery drivers
• Recipe: Configure delivery areas
• Recipe: Transport statuses and customer notifications
• Recipe: Pickup and delivery options at checkout
• Hooks: transport authorization (mam_wc_delivery_user_can_manage_transport)
• Hooks: mam_check_in and order advancement
• Hooks: delivery-area checks (wc_delivery_in_delivery_area_type)
• Hooks: driver dispatch and cron (mam_wc_delivery_request_driver)
• Hook: mam_ride_share_driver_update
• Hooks: white-label overrides (mam_wc_delivery_store_post_parent)

Metadata