Booking & Payment System Technical Review — 2026-04-05

Overview

Technical call between Asymmetric (Kimberly Gehrmann, Isahaque Mahmud, Melissa Cusumano) and La Marie Beauty to clarify implementation details for the new booking and payment system. Primary topics: card-on-file payment flow, Bookly/Square availability syncing, Bookly widget customization limits, and the maintenance implications of custom JavaScript on service pages.

Meeting recording: https://fathom.video/calls/477300762

Attendees:
- Kimberly Gehrmann (external consultant, engineering background)
- Isahaque Mahmud — Asymmetric developer
- Melissa Cusumano — Asymmetric PM
- Roxana Lopez — La Marie Beauty
- Katie Schueller — La Marie Beauty (absent)
- Lisa Frommelt — La Marie Beauty (absent)

Key Decisions

1. Card-on-File Payment Flow Requires Custom PHP

Bookly and WooCommerce cannot natively support the required service payment logic: collecting a card without charging it upfront, storing it for no-show/cancellation penalties, and charging post-service. This must be implemented via custom PHP code using WordPress/WooCommerce hooks.

"For all those type of payment, we need to write some custom PHP code. We can't do this with WooCommerce." — Isahaque Mahmud

Why PHP and not JavaScript: WordPress and WooCommerce are PHP-based platforms. Backend hooks — the integration points for Bookly, WooCommerce, and Square — require PHP. JavaScript handles frontend behavior only.

2. Square APIs Will Handle Card Tokenization

Rather than building a fully custom card-handling solution, the custom PHP code will call Square APIs for tokenization. This decision preserves:
- Square's PCI-compliant security infrastructure
- Existing customer profiles (auto-fill of name, phone, email for returning Square customers)

"I want to reduce the risk of leaked credit card details. And also Square has a profile of a customer… I don't want to lose this level of integration." — Kimberly Gehrmann

Isahaque confirmed the Square API key can be created by the developer without requiring action from the client.

3. Bookly/Square Availability Sync Is Real-Time

Bookly syncs with Square instantly via API — there is no polling delay or batch update window. When a booking is made through Square directly (e.g., via the Square mobile app), availability updates in Bookly immediately, and vice versa.

The near-impossible edge case of two simultaneous bookings for the same slot is handled by Square's backend, which will error out one of the two requests.

"It will sync instantly." — Isahaque Mahmud

4. Bookly Widget Customization Is Constrained

The Bookly widget supports modification of existing elements only:
- ✅ Text, colors, fonts
- ✅ Icons (replace or remove)
- ✅ Layout reordering (e.g., move sidebar elements)
- ✅ Removing duplicate data (e.g., staff name shown twice)
- ❌ Adding new elements (buttons, icons, custom fields)

The widget currently does not match the site's aesthetic (minimalist, luxurious, bespoke button styles). Design review with Lisa Frommelt is required before further CSS work proceeds.

Critical Risk: Service Page JavaScript Creates Developer Bottleneck

The Vampire Facial service page (and likely other service variation pages) uses custom JavaScript to conditionally render content based on button selection — changing images, descriptive text, pricing, and the "Book Now" button destination — all under a single URL.

if (button A selected) → render image A, text A, link to booking A
else if (button B selected) → render image B, text B, link to booking B
...

The problem: This is not a CMS-editable content structure. Any update to service content — adding a new variation, changing an image, updating copy — requires a developer to modify code. Roxana Lopez cannot do this via the WordPress editor.

"This is not, we tell Roxy, 'oh yeah, click these three buttons and you can update this text, no problem.' This is a developer that is modifying code in order to update things." — Kimberly Gehrmann

This was identified as a significant long-term maintenance concern. No solution was decided in this meeting — Kimberly will review the code first to assess complexity before proposing a path forward.

Action Items

Open Questions

• Service page maintenance path: Once Kimberly reviews the JavaScript, what are the options? Possible directions include: (a) keeping developer-managed updates, (b) refactoring to a CMS-editable structure, (c) a hybrid approach. This needs a conversation with Mark before a decision is made.
• Bookly widget design: Does Lisa approve the current widget structure, or are changes needed? This is blocking further CSS work.
• Scope: What service page customization work is in vs. out of scope for Asymmetric? To be clarified before additional development proceeds.

Technical Context

Zapier has been fully removed from the integration stack.

Related

• ^[1]
• ^[2]