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.
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.
Kimberly's deep-dive into Bookly surfaced several built-in features that may resolve previously identified friction points:
Status: Unresolved — Go/No-Go dependency
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.
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.
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.
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.
As of Dec 16, the WooCommerce layer has not been fully mapped against Bookly's internal data model. Open questions include:
These will be addressed in Kimberly's technical report (due Dec 26).
If custom work is scoped beyond what Bookly/WooCommerce can support:
Knowledge transfer is a meaningful advantage for Asymmetric's team given their existing depth on the project.