--- title: La Marie Beauty — Square API Credit Card Tokenization type: article created: '2026-04-05' updated: '2026-04-05' source_docs: - raw/2025-12-16-la-marie-beauty-project-call-109148440.md tags: - square - woocommerce - bookly - credit-card-tokenization - technical-blocker - la-marie-beauty - integrations layer: 2 client_source: null industry_context: null transferable: true --- # 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: [[clients/la-marie-beauty/_index]] | [[meetings/2025-12-16-la-marie-beauty-project-call]] --- ## 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: | Layer | Role | |---|---| | **Bookly** | Appointment scheduling plugin (WordPress) | | **WooCommerce** | Payment processing layer; Bookly routes checkout through WooCommerce | | **Square API** | Payment processor; tokenization must be handled via Square's API | **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 [[meetings/2025-12-30-la-marie-beauty-one-on-one]] 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 | Person | Role | |---|---| | Isahaque Mahmud (Eshock) | Asymmetric developer; built the custom PHP tokenization code | | Kimberly Gehrmann | La Marie Beauty fractional CTO / technical PM | | Melissa Cusumano | Asymmetric project lead | | Lisa Frommelt | La Marie Beauty owner; requirement originator | | Chris Ostergaard | Former Asymmetric engineer; previously flagged tokenization as broken |