Bookly-Square Tokenization Integration

Overview

The LMB project uses WooCommerce on WordPress to handle both product purchases and service bookings. Product purchases flow through WooCommerce → Square with no issues. The blocked integration involves service bookings: WooCommerce can capture a credit card authorization token, but that token fails to pass through to Bookly for service-booking completion.

This is a known blocker as of late December 2025 and is the subject of an active go/no-go decision. See ^[1] for broader project context.

The Technical Problem

What Works

• WooCommerce's native Square payment gateway can capture credit card authorizations for product orders.
• The WooCommerce → Square pipeline for product purchases is functional and live.

What Fails

• When a customer books a service through Bookly (integrated via WooCommerce), the credit card token captured by WooCommerce is not relayed to Bookly.
• There is a communication gap between the WooCommerce payment layer and the Bookly booking layer — the token exists in WooCommerce's context but does not transfer to Bookly's booking record.

The Setting in Question

In WooCommerce → Settings → Payments → Square → Manage, there is an Authorization mode that captures card tokens for paid orders. Enabling this works for product flows but does not propagate to Bookly service bookings.

Current Remediation Attempt

Developer Ishak has been writing custom PHP to bridge the communication gap — essentially forcing the WooCommerce-captured token to be passed to Bookly programmatically. As of the December 30, 2025 sync:

• The PHP workaround is in progress on the staging site (not live).
• Ishak has identified two locations in the codebase where the Bookly token is being injected.
• He is consulting a colleague for a fresh perspective before declaring the approach viable or failed.

Code Artifacts to Review

Ishak was asked to provide the following for a code audit by Kimberly Gehrmann:

Delivery method: Google Doc (code) + Loom/screen recording (settings), sent directly to Kimberly with Melissa CC'd.

Go/No-Go Decision Framework

Because the client (Lisa) has explicitly rejected stopgap or "janky" solutions, this integration is treated as a binary decision:

• Go: Ishak's PHP approach (potentially informed by colleague review + Kimberly's code audit) successfully passes the token to Bookly. Integration proceeds.
• No-Go: The approach fails. Bookly is abandoned as the service booking layer.

The go/no-go outcome gates all downstream Bookly work. The holding pattern of iterative attempts is being time-boxed to force a definitive answer.

Contingency Plan (No-Go Path)

If the tokenization bridge cannot be made to work, the fallback is not to introduce a new interim solution. Instead:

1. The existing, high-quality service variant pages built on staging are pushed to production as-is.
2. "Book Now" buttons on those pages link directly to the specific Square booking page for each service (not the generic Square homepage, which is the current live-site bug).
3. This preserves Asymmetric's design work and maintains the existing Square booking flow that already holds 5+ years of client data.

Live Site Bug (Related)

Currently, "Book Now" buttons on the live LMB site link to the generic Square homepage rather than the specific service's Square booking page. This is a simple URL swap and should be fixed regardless of the go/no-go outcome.

Why Bookly Is High-Risk

• Square holds 5+ years of client history, including spending records in the tens of thousands of dollars per client. Migrating booking data to Bookly risks data loss or degraded client experience.
• Preliminary research indicates Bookly lacks the customization depth required to match the design vision established in Miro and validated by Lisa's Loom recording.
• The WooCommerce + WordPress environment has inherent plugin interoperability limits that may make the token-passing problem fundamentally unsolvable without significant custom engineering.

Related

• ^[1]
• ^[2]
• ^[3]