La Marie Beauty — Bookly & WooCommerce Integration

Overview

This article documents the technical investigation into Bookly's capabilities and its integration with WooCommerce for the ^[1] booking system. The core challenge is a mismatch between Bookly's plug-and-play design and the client's custom vision, compounded by a critical unresolved blocker in the Square API credit card tokenization flow.

The findings below are drawn from a Dec 16, 2025 project reset call between Kimberly Gehrmann (client-side technical lead) and Melissa Cusumano (Asymmetric project lead), with developer Eshock (Isahaque Mahmud) as a key background stakeholder.

Architecture Overview

The intended booking stack is:

Bookly (booking UI/logic)
  └── WooCommerce (payment/checkout layer)
        └── Square API (payment processing + card-on-file)

Square is intentionally kept as the source of truth for payments and staff/service data, in order to support Lisa Frommelt's longer-term product vision beyond the website. This means Bookly should not become the authoritative data store.

Bookly Capabilities Identified

Kimberly's deep-dive into Bookly surfaced several built-in features that may resolve previously identified friction points:

Compound Services

Bookly supports compound services, which may address the need for service variants (e.g., different durations or add-ons for a single treatment type).
It is unclear whether this was previously investigated by Eshock.

Custom Service-Specific Forms

Bookly allows creation of custom forms scoped to individual services.
This directly addresses the "Flash Services" page problem — where every possible service was displayed to clients in an overwhelming list.
With service-specific forms, a category like microneedling can have its own dedicated form, reusing styling without exposing the full service catalog.

Add-On Ecosystem

Bookly has a significant library of purchasable add-ons.
A full audit of which add-ons are currently installed in the WordPress staging environment is still needed.

Critical Blocker: Credit Card Tokenization

Status: Unresolved — Go/No-Go dependency

Requirement

La Marie Beauty requires the ability to save a credit card on file at the time of booking in order to charge cancellation fees after the fact. This is a hard go/no-go requirement for launching the booking system.

Technical Approach

The implementation path runs through WooCommerce, not Bookly directly:

Bookly booking → WooCommerce checkout → Square API
                                          └── $0 auth charge
                                          └── Card token stored
                                          └── Token charged later for cancellation fee

A custom PHP integration with the Square API was built by Eshock to perform the $0 authorization and token capture. This integration is not currently working.

History

Chris Ostergaard (former Asymmetric developer) previously flagged this as non-functional before departing.
The team pivoted to routing through WooCommerce as a potential solution path.
A Zapier zap was briefly involved and was found to have been inadvertently re-enabled; it has since been turned off. Zapier is not currently in use.
As of Dec 16, 2025, Eshock's status on this blocker is unknown — it is unclear whether he has remaining approaches to try or is fully blocked.

Required Action

Eshock must provide a summary of:
- All tokenization approaches attempted
- Specific failures encountered
- Whether he considers himself blocked or has remaining paths to explore

A Loom video walkthrough of the WordPress/WooCommerce environment is an acceptable format. Kimberly will email Eshock directly (CC Melissa) to request this.

Scope Tension: Plug-and-Play vs. Custom Vision

Bookly is designed as a generic, plug-and-play booking solution. The client's vision requires significant customization — including custom booking flows, service-specific UX, and deep Square integration — that pushes against Bookly's design boundaries.

Two paths are under consideration for the Dec 30 scope decision:

Path	Description
Launch with Bookly defaults	Ship the site using Bookly's out-of-the-box features; scope a separate SOW for custom work afterward
Custom build	Abandon Bookly in favor of a fully custom booking solution

The go/no-go on credit card tokenization is the primary input to this decision. If tokenization cannot be resolved within the Bookly/WooCommerce stack, the case for a custom build strengthens significantly.

WooCommerce Integration Gaps

As of Dec 16, the WooCommerce layer has not been fully mapped against Bookly's internal data model. Open questions include:

How does Bookly's staff availability sync with WooCommerce?
Does staff scheduling require Zapier, or can it be handled natively within Bookly's WordPress plugin?
Which Bookly add-ons are currently purchased and active?
What is the exact failure mode of the Square API token capture through WooCommerce?

These will be addressed in Kimberly's technical report (due Dec 26).

Potential Development Resources

If custom work is scoped beyond what Bookly/WooCommerce can support:

Kimberly's contacts: India-based dev teams at approximately $45/hr; Eastern European contacts also available.
Asymmetric internal: Dimitri leads a small custom dev team within Asymmetric with existing project context. Rates unknown. Would need to bid competitively.

Knowledge transfer is a meaningful advantage for Asymmetric's team given their existing depth on the project.

^[2]
^[3]
^[4]