Larry OG Uber Bridge

Project status and relationship

This is the Larry OG Uber Bridge, a custom plugin for the Larry OG WooCommerce storefront. It is separate from the experimental QuikBooze Uber Direct Bridge. The supplied administration notice states that the Uber Direct integration is no longer maintained or supported, offers no new features or support, and that existing deliveries may still run. This case study records previously developed work; it is not an offer of a current integration service or a claim that the external services are available today.

The bridge sat alongside other independent Larry OG extensions, including CLOVER APPS and QB AI Content Generator. Those tools have separate responsibilities: CLOVER APPS handles reviewed catalog-administration workflows, while QB AI Content Generator supports product-content work. The bridge described here handles delivery quotes, dispatch conditions, fallback delivery methods, and delivery-status events.

Integration boundary

WooCommerce owns the cart, checkout order, shipping selection, and order record. The bridge adds a server-side delivery method and stores quote and delivery metadata against the order. Clover is used here as a payment-confirmation signal; this is separate from the vendor’s Clover payment extension. Uber Direct is the delivery provider boundary. Google services support address autocomplete and driving-distance calculation.

The plugin source includes API request and response handling, settings, checkout hooks, shipping-rate calculation, dispatch guards, and a REST webhook route. The project pack also contains redacted screens showing selected configuration. Source presence and saved settings are not proof that current live Clover payments, Uber quotes, dispatches, maps services, or webhook deliveries succeed.

Payment-confirmed dispatch

The bridge removes the vendor plugin’s default thank-you-page dispatch callback so delivery creation does not happen through that earlier path. Its own automatic dispatch logic checks the WooCommerce order’s paid state and, when the configured requirement is enabled, the expected successful Clover payment status and a payment identifier. Manual dispatch remains a separate order-administration path.

This guard is designed to prevent a delivery request from being sent before payment is confirmed and to avoid duplicates. The source contains lock and existing-delivery checks as well as the payment gate. The screenshots show that the option was enabled in the captured configuration; they do not prove a current payment-to-dispatch transaction.

Checkout quotes and delivery pricing

The plugin requests an Uber quote server-side using the checkout destination and configured store pickup information, then exposes a WooCommerce shipping rate. The source includes paths for classic checkout and WooCommerce Checkout Blocks-related address and order handling. Quote refresh behavior is tied to the shipping package and destination so changed checkout addresses can trigger a fresh calculation.

Customer-facing pricing can combine the returned delivery quote with a configured handling amount and optional tip or service amount. The case-study images conceal actual store price settings. This section describes supported configuration and source flow, not a verified current quote or charge.

Separate local-delivery fallback routes

When Uber cannot quote or accept a destination, the plugin distinguishes two store-arranged alternatives:

• Manual/local delivery: A shorter-range fallback with its own distance limit and customer-facing price/message; the store arranges the delivery rather than sending it through automatic Uber dispatch.
• Extended local delivery: A separate farther-range option with its own maximum range, minimum customer price, and additional per-mile fee beyond the manual range. The checkout message explains that store staff will coordinate delivery.

A further distance-band table supports fallback pricing when Uber rejects an address for radius. A live Uber quote takes precedence when it is available. These alternatives do not represent additional Uber dispatches.

Address handling and distance strategy

The implementation can build a structured Uber address payload from checkout address parts. The settings interface includes a pickup-address override, Google address autocomplete, country and location-bias controls, and Google Maps/Distance Matrix configuration. Private address and credential values are redacted from the portfolio images.

The source defines selectable distance strategies: Google driving distance first with Haversine fallback, Google-only, Haversine-only, or use of distance returned by Uber errors. Haversine calculation requires pickup and drop-off coordinates; it is not an address-geocoding substitute. A configurable safety multiplier and distance-based fallback fees are part of the implementation.

Delivery hours and scheduling

The bridge can use a configured store timezone and earliest/latest dispatch times, including a delivery window that crosses midnight. When delivery-hour enforcement is enabled, the checkout path can withhold delivery methods outside that window and show a closed-delivery message. These values are store configuration and are concealed in the screenshots.

Webhooks and order status

A dedicated WordPress REST route accepts Uber delivery events. The handler verifies the HMAC signature and can reject unsigned sandbox events when that setting is disabled. Delivery-status and courier-update events are mapped to WooCommerce order metadata. The code compares status progression to avoid an older event overwriting a later or terminal state, and includes an administration workflow to refresh delivery status. For applicable automatic deliveries, a delivered event can complete the WooCommerce order; manual and local fallback orders are not treated as Uber-completed deliveries.

The included screenshot demonstrates the configuration surface and event names, not a newly executed webhook. No current webhook request or status update was performed for this portfolio entry.

Implementation decisions and limits

The integration keeps several responsibilities separate: payment confirmation gates dispatch; quoting happens during shipping calculation; local fallback methods remain store-managed; distance calculation has explicit strategies; and delivery status arrives through a signature-checked event boundary. These boundaries make the different failure and fulfillment paths visible to both checkout and store operators.

The owner reports that the workflows were tested during development. This portfolio pass inspected the local plugin source and the owner-supplied administration captures; it did not repeat checkout, provider API, Clover payment, Uber dispatch, Google Maps, or webhook tests. The portfolio should therefore be read as documentation of the implemented and previously tested project, not as a current service guarantee.

The supplied screenshots show genuine WordPress administration screens. They have been additionally redacted for this portfolio: pickup address and location, webhook URL, signing/API credentials, schedule values, configured price values, store identifiers, and unrelated administration notices are hidden or cropped. No customer order data is included.