La Marie Beauty — Square API Credit Card Tokenization

Overview

The La Marie Beauty project has a go/no-go blocker: the ability to save a customer's credit card on file at booking time (charged $0) so that staff can later charge a cancellation fee against the stored token. This requires a working Square API credit card tokenization flow routed through WooCommerce, not Bookly directly.

As of the December 16, 2025 project call, this integration is not working. The custom PHP/Square API code written by Eshock (Isahaque Mahmud) has not successfully produced a reusable token.

See also: ^[1] | ^[2]

Why This Is a Go/No-Go Requirement

La Marie Beauty requires a cancellation fee policy enforced at the payment layer. The flow is:

1. Customer books an appointment via Bookly.
2. At checkout (through WooCommerce), a credit card is captured and charged $0.
3. The Square API returns a reusable token representing that card.
4. If the customer cancels within the penalty window, staff charge the cancellation fee against the stored token — without requiring the customer to re-enter card details.

Without this capability, the cancellation fee policy cannot be enforced programmatically. Lisa Frommelt (La Marie Beauty owner) has indicated this is a non-negotiable requirement for launch.

"That's still, that's critical. Like styling, like styling, to Lisa, critical perhaps to Lisa, not critical to we actually make this go live. But if we can't do that, capture a credit card, charge it $0, but have it on file where we could charge them that cancellation fee, that's still a go/no-go."
— Kimberly Gehrmann, Dec 16 2025

Technical Architecture

The integration sits at the intersection of three systems:

Key insight from the Dec 16 call: The tokenization is not a Bookly problem — it is a WooCommerce-to-Square API problem. Bookly hands off to WooCommerce at checkout; WooCommerce must then call the Square API to capture and store the card token. Custom PHP code is required because this is not a native WooCommerce + Square capability out of the box.

Zapier was previously explored as part of the integration chain but is not currently in use and is turned off.

Current Status (as of Dec 16, 2025)

• Status: Blocked / Unknown
• Eshock built a custom PHP integration against the Square API to perform tokenization.
• The integration is not working — tokens are not being successfully captured or stored.
• It is unclear whether Eshock has exhausted all approaches or has remaining ideas to try.
• Chris Ostergaard (previous Asymmetric engineer) also flagged this as not working before his departure. The team has been here before.
• Melissa Cusumano (Asymmetric PM) paused further work on tokenization while other project issues were being sorted.

Required Next Step: Eshock Status Report

Before any go/no-go decision can be made, Kimberly Gehrmann needs a clear summary from Eshock of:

• What approaches have been attempted
• What was tried and ruled out (and why)
• Whether he is currently blocked (no remaining ideas) or has further avenues to explore
• Current state of the code and any error output

A Loom video walkthrough of the WordPress/WooCommerce environment and what was attempted is explicitly acceptable in lieu of a written document.

Action: Kimberly to email Eshock directly (CC Melissa) requesting this summary. Eshock may also email Kimberly directly with the Loom or written summary.

"If he is blocked, I want to know what he's tried so I'm not suggesting things he's already tried."
— Kimberly Gehrmann, Dec 16 2025

Resolution Paths

Path A — Tokenization Is Solvable

If Eshock's summary reveals untried approaches, or Kimberly's engineering review identifies a viable path:
- Kimberly will provide specific technical direction to Eshock.
- Implementation proceeds within the existing Bookly + WooCommerce + Square stack.
- Project moves forward toward launch.

Path B — Tokenization Is Not Solvable in This Stack

If all approaches are exhausted and Square tokenization cannot be made to work through WooCommerce:
- This triggers a no-go on the current Bookly integration for the cancellation fee feature.
- Options include:
- Launch without cancellation fee enforcement (likely unacceptable to Lisa).
- Scope a separate custom build (micro-frontend or standalone component) that handles tokenization outside of WordPress/WooCommerce, then integrates back in.
- Evaluate whether a different payment processor or plugin combination supports native card-on-file behavior.

This decision feeds directly into the scope/budget conversation planned for the ^[3] between Kimberly and Melissa.

Related Decisions & Context

• Bookly is plug-and-play; this is not. Bookly does not natively support card-on-file for cancellation fees. This has always required custom code.
• Square must remain the source of truth. Lisa's longer-term product vision (beyond the website) depends on Square as the canonical data source. Any solution must preserve Square's role — tokenization cannot be moved to a different processor.
• Asymmetric has a custom dev team (led by Dimitri) with experience on larger builds, including India-based developers. If a custom solution is scoped, they are a candidate to bid alongside external dev shops Kimberly has contacts with (~$45/hr India-based teams).
• Knowledge transfer is a real asset. Asymmetric's existing familiarity with the La Marie codebase is a meaningful advantage for any future custom work.

Key People