Wekoodo × Flute · August 4, 2026 · Version 7.0

FluteCommerce V1

Platform & Scope Brief

Prepared for: The Executive, Product & Engineering Teams at Flute
Prepared by: Andrew Angell & Richard Freedkin — Managing Members, Wekoodo, LLC

Purpose: align on the FluteCommerce product vision, v1 scope, delivery approach, and Flute dependencies. Commercial terms and the investment business case are handled in a separate confidential document for the appropriate stakeholders.

Navigate with ← → or scroll

01 · The decision for this discussion

Does this represent the v1 platform Flute wants to move forward with, subject to commercial agreement?

FluteCommerce is a white-label, multi-tenant hosted ecommerce platform — in the Shopify/BigCommerce category — built around Flute payments and native dual pricing.

For Flute: a new merchant-acquisition and retention channel that brings more volume onto Flute's online rails.
For merchants: a professionally hosted storefront that removes infrastructure burden and makes compliant dual pricing part of the platform — not a separate integration project.

02 · The opportunity

Three merchant pain points, addressed at once

The infrastructure burden

Hosting, premium plugins, security patching, and developer retainers just to keep a store operating. FluteCommerce replaces that fragmented stack with one managed platform.

The processing-fee burden

Merchants commonly give up 2.5–3.5% of a card sale to payment costs. Compliant dual pricing, native to the storefront, can offset most of that burden — no plugin, no separate implementation project.

The compliance trap

Bolted-on fee-recovery plugins can get the price of record, receipt treatment, or disclosure flow wrong. FluteCommerce builds the compliant model into the platform and verifies it on every build.

02 · The opportunity

Four audiences for one value proposition

Flute's existing merchants

~26,000 active accounts where FluteCommerce can deepen retention and bring more volume onto Flute's online rails.

Established platform migrators

Catalog migration wizards for WooCommerce and Magento ship in v1; CSV import covers sellers coming from other platforms.

Merchants not yet on dual pricing

Compliant fee recovery becomes a guided configuration instead of a custom development project.

Net-new sellers

Marketplace-only, social-only, or offline-first merchants that need a professional online storefront.

03 · The v1 platform experience

One codebase, three experiences — entirely under Flute's brand

Merchant storefront

Fast, CDN-cached stores on a Flute subdomain or custom domain with automated SSL
One professional theme, Flute-controlled branding
Catalog, variants, inventory, collections, and search
Cart and checkout with card, ACH, and offline paths
Live USPS, UPS, and FedEx rates; built-in tax with optional TaxJar
Coupons, reviews, customer accounts, SEO, and a public AI-agent product feed

Merchant admin

Guided self-service onboarding from signup to live storefront
Catalog, inventory, order, refund, content, and customer management
Flute catalog sync plus Woo, Magento, and CSV migration wizards
Commerce reporting: sales trends, payment-method mix, tax, coupons, product performance
Custom-domain setup and a built-in agentic help desk under Flute's brand

Flute operator console

Store directory and platform-wide search
Store impersonation with a complete audit trail
Suspend and reactivate controls
White-label branding and platform settings
Platform metrics: signups, active stores, GMV, payment-method mix

03 · The v1 platform experience

Reporting: a defined floor, with clear system boundaries

V1 commerce-reporting floor FluteCommerce

Sales over time with date ranges and prior-period comparison
Payment-method mix across card, ACH, and offline
Tax collected, coupon usage, top products
Inventory status and low-stock visibility
Google Analytics 4 tag support
A dual-pricing value metric — name and formula agreed with Flute

Processor-native reporting Stays in Flute

Settlements, funding, processing fees
Disputes and chargebacks
The authoritative transaction ledger

Remains in Flute's existing dashboard unless the joint reporting workshop identifies a reason to surface a summary or deep link in FluteCommerce.

Some reports need both systems: FluteCommerce knows the order, product, tax, discount, and selected payment method; Flute owns the processing and settlement data. The joint workshop settles metric definitions and system-of-record boundaries.

03 · The v1 platform experience

Catalog and inventory: a clear source-of-truth split

Flute-owned fields Flute

Name, description, SKU, category, base unit price, and unit type for linked simple products. FluteCommerce continuously reads and refreshes these.

FluteCommerce-owned fields FluteCommerce

Images, variants, options, SEO, related products, inventory, and sale prices. Store-only products are also supported.

V1 floor: ongoing read synchronization from Flute — webhooks when available, scheduled polling as the fallback.
Joint decision: whether FluteCommerce can write to the Flute catalog depends on Flute's write API. Cross-channel inventory requires the Flute catalog to expose the necessary inventory fields and events.
The catalog workshop defines write direction, conflict handling, freshness, reconciliation, and the merchant experience when a field must be managed in Flute.

04 · Native dual pricing

Dual pricing is native, not bolted on

Card price $51.55 Price of record wherever a single price appears · illustrative figures

Cash price $50.00 Shown side by side on every pre-purchase surface

Pre-purchase: category, product, cart, and checkout all show cash and card prices side by side.
Post-sale: receipts and order history show only the price the customer actually paid — never both prices, never a separate fee line.
Marketing: merchant-run marketing carries the same side-by-side treatment, supported by onboarding guidance, compliant ad-copy templates, and documentation.
Settings: enrollment, rate, and program state stay in the merchant's Flute dashboard as the system of record. FluteCommerce reads them, never edits them.
Verification: a dedicated compliance test suite checks the pricing and receipt rules on every build.
Third-party marketplaces (Amazon, Walmart) remain outside the program — they don't support dual pricing and prohibit routing buyers off-platform.

04 · Flute payments

Payments run through Flute end to end

Card: Flute Elements/Checkout — card data never touches FluteCommerce servers.
PCI: the design supports SAQ-A eligibility, subject to the final Flute Checkout implementation and acquirer or QSA validation.
ACH: settles at the cash price; v1 includes adding ACH support to the Flute PHP SDK and integrating it into FluteCommerce.
Offline: offline payment methods support pay-in-person merchants.
Penny-exact: price calculations are reconciled against Flute's calculate_amount endpoint in the sandbox.
Catalog: each store synchronizes with the merchant's existing Flute catalog.

05 · Delivery scope

Seven phases, each ending in a working, browsable increment

Phase	Working increment delivered
1 · Foundation	Multi-tenant core, dual-pricing engine and compliance suite, payment interface, identity and 2FA, admin shells
2 · Catalog & Storefront	Products, variants, inventory, media, and the themed storefront with compliant dual-price display
3 · Money Paths	Cart, checkout for card/ACH/offline, orders, refunds, and penny-exact sandbox reconciliation
4 · Shipping, Tax & Discounts	Shipping zones, live carrier rates, built-in tax plus TaxJar, coupons, and sale prices
5 · Content & Discovery	Pages and branding, reviews, customer accounts, SEO and redirects, and AI-agent product feed
6 · Onboarding & Migration	Self-service signup, Flute catalog sync, Woo/Magento/CSV migration wizards, custom domains, operator console
7 · Launch Readiness	Notifications, reporting, agentic help desk, security hardening, observability, compliance acceptance run

05 · Delivery scope

A deliberate scope fence keeps the launch dependable

V1 scope fence

Market: United States · Currency: USD
One store per merchant; one professional theme
No merchant billing module in v1
Migration wizards focus on moving catalog data into FluteCommerce
Flute's decision — how the platform is offered: Wekoodo recommends no separate platform fee, because the strategic value comes from processing volume and retention. If Flute later charges for access, it can bill on its own rails or add platform billing as separately scoped work.

V2+ menu — priced and scheduled when Flute is ready

Broader migration coverage and additional platform wizards
Cash-discount and surcharge presentation models
Digital wallets, when supported by the Flute API
Restaurant-specific capabilities
Multi-store merchants
Theme editor and additional themes
Agent-executed checkout

06 · What we need from Flute

Every dependency has a fallback — none blocks agreement

Dependency	Needed by	If late
ACH endpoints on the Flute API (SDK-side ACH work is included in v1)	Phase 3	Checkout ships with card and offline; ACH follows when endpoints are available
Sandbox credentials and `calculate_amount` access	Phase 3	The reconciliation session moves with access
Infrastructure decision (Wekoodo recommends Laravel Cloud)	Phase 1	Build proceeds on staging defaults
Webhooks for program-setting and transaction changes	Optional	Scheduled polling is the fallback
Reporting ownership and data-source decisions	Phase 7	FluteCommerce ships its native reporting floor; processor-native reports remain in Flute
Catalog write and inventory API capabilities	Phase 6	Read sync remains the v1 floor; unsupported writeback or cross-channel inventory is deferred

Dual-pricing settings remaining in the Flute dashboard is a design boundary, not a dependency.

07 · Joint platform-definition workshops

Cross-system decisions are made together, not assumed

Focused working sessions with Flute's product, API, reporting, and operations stakeholders resolve the decisions Wekoodo cannot responsibly set alone:

ZCP calculation authority — configuration ownership and penny-exact acceptance vectors
Reporting ownership — metric definitions, authoritative data sources, dashboard placement
Catalog synchronization — inventory ownership, write direction, conflict handling
Integration boundaries — webhooks, polling, event schemas, reconciliation

Each decision becomes a documented responsibility assignment, interface requirement, and acceptance criterion. Workshops refine the stated v1 scope; capabilities outside it remain separately evaluated changes.

08 · Timeline and working model

14–16 weeks

from SOW signature to launch-ready — the committed delivery window. The plan targets the low end, with phases landing roughly every 1.5–2.5 weeks.

Working software at every phase boundary. Reviews center on live functionality, not status reports.
Test-driven development throughout, with elevated attention on two suites: dual-pricing compliance and cross-tenant isolation — proving one store can never access another's data.
Focused joint workshops and two attended verification sessions: sandbox verification opening Phase 3, and custom-domain/DNS validation during Phase 6.
Five-business-day acceptance reviews keep the sequential phases moving.

The window assumes timely access to Flute systems, stakeholder decisions, and phase reviews. Material dependency delays or approved scope changes may adjust the schedule, with final timing confirmed in the SOW.

09–10 · Support model & why Wekoodo

Three layers of support, one experienced team

1 · Built-in help desk

An embedded assistant under Flute's brand answers merchant platform questions from documentation produced alongside the build.

2 · Flute first line

Unresolved questions escalate to Flute's merchant support team with the conversation context attached.

3 · Wekoodo second line

Platform-engineering escalations go to the team maintaining the application, API compatibility, and compliance-driven changes.

Wekoodo built Flute's PHP SDK and has delivered production integration across Flute's transaction, settlement, and webhook surfaces — reducing integration discovery from day one.
Dual-pricing compliance is a specific engineering domain for Wekoodo. The test suite enforces the card-price-of-record, single-storewide-rate, and one-total-receipt rules that determine whether an implementation is a genuine dual-pricing program.

Responsibilities, service levels, and the commercial structure for ongoing maintenance are defined in the separate confidential commercial package.

11 · Initial alignment

Three questions to confirm today

1. Does the overall FluteCommerce product direction match Flute's vision?
2. Is the proposed v1 scope and scope fence the right starting point?
3. Is there enough alignment to proceed to the commercial and SOW discussion?

Proposed next step: walk through the working prototype, capture initial scope feedback, and confirm whether Flute wants to proceed to commercial alignment and SOW development.

Detailed reporting, catalog, inventory, and API decisions are resolved collaboratively through the included platform-definition workshops.
Prepared by Wekoodo, LLC · drew@huckangell.com · Platform and scope discussion brief; not a commercial offer.