All WorkCase Study · Fractional Engagement
Type
Fractional lead — completed
Brief
WordPress → Shopify replatform
Grew into
Gift cards · Loyalty · Theme
Client
Specialty retailer — under NDA
Services
ReplatformingCustom ThemePayments IntegrationLoyalty
Stack
Shopify · Liquid / OS 2.0 · Next.js on Vercel · Postgres on Neon · Shopify app proxy (HMAC) · legacy SOAP gift-card processor
The Challenge
Shopify’s checkout doesn’t accept third-party gift cards, and the store’s plan has no checkout customization at all.
The brief was a WordPress replatform. Once the new store was live, scope grew the way retail scope grows: the brand’s in-store services had to work on the web too. Customers held physical gift cards issued by a legacy SOAP processor and expected to spend them online. The loyalty program shoppers used at the register had to reach their pockets.
Two platform constraints boxed the gift-card design in completely. Checkout won’t take a third-party card as a payment method, and without Plus there is no checkout customization — nothing can be collected, validated, or charged inside checkout. The only surface the integration controls is the cart, which forces the defining decision: collect the funds when the card is applied, and mint a synthetic Shopify gift card for the same amount, a currency checkout does accept.
3
Parallel workstreams, each with its own vendor and release cadence
7
States in the redemption lifecycle, transitions idempotent
0
Automated reversals — processor policy makes credits manual
1
Vendor certification, argued with the working integration
The Approach
Apply-time collection buys a working integration and a reconciliation problem. The state machine is the answer to the second.
01
Collect at the cart, settle later
The shopper enters card number and PIN in the cart drawer; the integration checks the balance against the processor’s SOAP API, charges immediately, and mints a synthetic Shopify gift card. The path runs drawer → HMAC-signed Shopify app proxy → Next.js on Vercel → Postgres, so the storefront never talks to the integration unauthenticated.
02
Name every way the money can be wrong
Funds leave the card before an order exists, so abandonment, under-settlement, refunds and cancellations all involve money already taken. Seven explicit states — through to `credit_due`, funds owed back and awaiting a manual merchant credit — make each of those a named condition rather than a support ticket.
03
Make the race conditions structural
A reservation row is claimed with a conditional UPDATE that succeeds for exactly one caller, so one physical card holds one live reservation and two browser tabs applying the same card race safely — the loser sees the card as in use, and no balance is charged twice.
04
Hand over runbooks, not a report
The integration registers its own webhooks and runs its own cron sweeps, so daily operation depends on nobody watching a dashboard. Certification answers and the manual-credit runbook exist so the merchant team operates every system without the developer in the loop.
The Outcome
Engagement complete
The brand ended the engagement owning a replatformed store, a certified gift-card integration, and a loyalty program — plus the runbooks to run them.
What generalizes here is not any single system. It is three workstreams with different vendors, risk profiles and failure modes, sequenced by one person: production deploys gated on the test suites, a vendor certification run over email with the working integration as the argument and a written Q&A trail as the record, and documentation written so the merchant team never needs the developer back.
That is what fractional leadership looks like when the deliverable is a running store, not a report.
