What it does

mam-woocommerce-ride-share layers a complete ride-booking service onto a MAM app backed by WooCommerce:

• Riders request a trip from the app home screen — an “Order Ride” button opens a Gravity-Forms request form with pickup and destination (GeoDirectory listing or manually entered address, geocoded through Mapbox) and an optional departure time.
• Drivers are matched to the request: the plugin finds Product Vendors “fleets” whose service zip codes cover both ends of the trip, filters to drivers who are on duty, and assigns the nearest one by routing distance.
• The ride is a WooCommerce order (shop_order, status processing while active). All ride state — driver, route, GPS pings, ETA, status checkpoints — lives in order meta, so it shows in the normal WooCommerce order screens.
• A state machine drives the trip: Assigned to Driver → Enroute to Pickup → Arrived at Pickup → Departed Pickup → Arrived at Destination → Trip Completed. The driver advances it with one button; each step records a timestamped GPS checkpoint and pushes a notification to the rider. The driver’s app sends GPS pings throughout, which update the live map, the ETA, and fire an “arriving in 2 minutes” notice.
• Riders and drivers each get a live home screen: the rider sees the driver’s position, ETA, vehicle ID, cost, and a cancel option; the driver sees the customer, pickup/drop-off, pickup time, directions, the customer’s phone, and (with MAM Chat Manager) a chat button.

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

The fare model

Three settings on Mobile App Manager → WooCommerce Settings → Ride Share control charging:

When charging is off, rides are tip-only: the order totals $0 and the rider is prompted to tip the driver through MAM Reviews Manager after the trip.

Note: in earlier releases these settings were saved and read under mismatched option keys, so enabling “Charge for Ride” silently did nothing. As of this version the fare path reads the registered keys — turning on Charge for Ride now actually charges riders. See Recipe: Configure ride fares before enabling it.

Live tracking and PII rules

Ride details are sensitive (the customer’s phone number, both addresses, and the driver’s real-time GPS), so every disclosure is authorization-gated:

• The service-details block (map, addresses, phone, GPS) is only built for the ride’s own rider, its assigned driver, or a user with the manage_woocommerce capability. Anonymous and unrelated users get nothing.
• The driver-location directory (live map of every driver in a fleet with on/off-duty status) is restricted to managers — wc_product_vendors_admin_vendor or manage_woocommerce.
• Ride cancellation is restricted to the ride’s customer (or a manager); ride state/GPS updates to the assigned driver (or a manager).

Each rule has a filter escape hatch (mam_wc_ride_share_user_can_*) for sites with custom role models — see Hooks: ride-share authorization filters.

Driver enrollment

Managers invite drivers from the app with the Invite Driver form (manager-only). The invitee receives a six-digit enrollment code by email; when they register in the app with that code, the new account is attached to the manager’s Product Vendors account (parent_pv_account_id) and given the driver role (wc_product_vendors_manager_vendor, filterable via mam_wc_pv_role_for_new_vendor). Managers can also assign a ride to a specific driver from the driver directory (“Assign” button) — that flow skips zip matching and the credit-card field.

Where it appears in the app

Notifications registered

Configure message templates for these slugs under the MAM notification settings: wc-rc-arriving-in-two-minutes, wc-rc-driver-enroute, wc-rc-driver-arrived-at-pickup, wc-rc-driver-completed-trip, wc-rs-new-trip, wc-rs-cancel-trip, wc-rs-invite-driver, wc-rs-driver-tip.

Dependencies and interop

• MAM Main — all app traffic (booking forms, the driver-update button, GPS pings) rides MAM Main’s single AJAX dispatcher; there are no REST routes or shortcodes.
• WooCommerce + MAM WooCommerce — rides are orders; the Ride Share settings tab lives on the MAM WooCommerce settings page; the checkout/cart path prices the trip product.
• WooCommerce Product Vendors (+ MAM WC Product Vendors) — fleets are vendor terms; drivers are vendor users; the per-vendor hidden “Trip” product carries the fare and the vendor commission.
• Gravity Forms — the ride request and driver invite forms.
• GeoDirectory — pickup/destination by directory listing. Manually entered addresses work without it, so it is needed only when you use listing-based selection.
• Mapbox — geocoding, routing distance, and ETAs require a Mapbox token; see Recipe: Mapbox and geocoding setup for exactly what degrades without one.
• MAM Stripe Manager — supplies the payment-method validity check on the rider home screen and the actual card charge on the checkout path.
• MAM Reviews Manager — post-trip “Review and Tip your Driver”; the tip is split with the driver per the vendor’s Driver Tip Percentage.
• MAM WooCommerce Delivery — the two plugins share the driver contract: the same mam_ride_share_driver_update button subaction, duty meta, and the driver_id / transport_status / eta order-meta keys. Run one of them as the fulfillment owner per app — both registering the driver-update handler on the same hook means whichever responds first wins.

Related articles

• Recipe: Set up a ride-share service
• Recipe: Configure ride fares
• Recipe: Mapbox and geocoding setup
• Recipe: Driver home screen and duty toggle
• Hooks: ride-share authorization filters
• Hook: get_available_drivers_for_lat_lon
• Hook: mam_wc_ride_share_request_form_data
• Hook: mam_ride_share_driver_update and the ride meta contract
• Hook: mam_post_id_for_eta

Metadata