Spike: WKQ as merchant of record — pick Stripe architecture (standalone account vs Connect platform) #507

New issue

Open

opened 2026-04-19 01:44:45 +00:00 by forgejo_admin · 0 comments

forgejo_admin commented

2026-04-19 01:44:45 +00:00

Owner

Type

Spike

Lineage

Standalone — emerged 2026-04-18 during the #497 recovery blast when Lucas observed that Stripe-side artifacts (receipts, statement descriptors, account name on checkout) all carry Pal-E branding rather than Westside Kings & Queens. Pal-E is currently the legal merchant of record.

Repo

forgejo_admin/basketball-api (primary integration point)

Question

Which Stripe architecture should Pal-E adopt so that Westside Kings & Queens is the merchant of record for WKQ transactions — and so that future pal-e tenants can onboard the same way without each one requiring a fresh decision?

Three candidate models to evaluate:

WKQ opens its own standalone Stripe account using WKQ's EIN + bank. Pal-E integrates as an API consumer using WKQ's secret key. No Connect. Scales by duplicating integration per tenant.
Stripe Connect Platform model. Pal-E becomes the platform; WKQ is a Connected Account (Standard / Express / Custom flavor TBD). All customer-facing branding, payouts, and compliance live on the connected account. Platform fee optional.
Status quo with aggressive branding overrides. Stay on Pal-E's single account; customize statement descriptors, receipt templates, and build WKQ-branded surfaces ourselves. Pal-E remains merchant of record.

What to Explore

Legal / compliance implications of each model for a nonprofit (WKQ) under a platform (Pal-E). What does merchant of record actually mean for tax reporting, chargebacks, 1099s?
Onboarding work: what does WKQ have to provide (EIN already in ~/secrets, bank info, W-9, business profile) for each model? Who owns the Stripe dashboard login after onboarding?
Technical impact on basketball-api: per-tenant Stripe key, Stripe-Account header for Connect, webhook routing, test-mode parity. Rough shape, not implementation.
Payout flow: where does the money land today vs where it should land. Platform fee feasibility if using Connect.
How future pal-e tenants (MCD, other clubs, agency clients) would onboard under the chosen model. A decision optimized only for WKQ is the wrong decision.

Success Criteria

Written recommendation picking one model (or a hybrid) with the reasoning captured.
Onboarding checklist for the chosen model: what WKQ provides, what Pal-E configures, in what order.
Technical-impact summary for basketball-api: which code paths change, which stay the same, approximate effort (s/m/l).
Follow-up implementation ticket(s) created with scoped AC once the model is chosen. Or: "no action needed" conclusion with reasoning if status-quo wins.

Time-box

One session. If the question can't be answered in that window, document findings so far and present options to Lucas for a direction call.

project-pal-e-platform
Sibling ticket: WKQ-branded post-purchase landing page
Sibling ticket: WKQ-branded payment receipt email
~/secrets contains WKQ EIN and related corporate docs — input data for whichever model is chosen

### Type Spike ### Lineage Standalone — emerged 2026-04-18 during the #497 recovery blast when Lucas observed that Stripe-side artifacts (receipts, statement descriptors, account name on checkout) all carry Pal-E branding rather than Westside Kings & Queens. Pal-E is currently the legal merchant of record. ### Repo `forgejo_admin/basketball-api` (primary integration point) ### Question Which Stripe architecture should Pal-E adopt so that Westside Kings & Queens is the merchant of record for WKQ transactions — and so that future pal-e tenants can onboard the same way without each one requiring a fresh decision? Three candidate models to evaluate: 1. **WKQ opens its own standalone Stripe account** using WKQ's EIN + bank. Pal-E integrates as an API consumer using WKQ's secret key. No Connect. Scales by duplicating integration per tenant. 2. **Stripe Connect Platform model.** Pal-E becomes the platform; WKQ is a Connected Account (Standard / Express / Custom flavor TBD). All customer-facing branding, payouts, and compliance live on the connected account. Platform fee optional. 3. **Status quo with aggressive branding overrides.** Stay on Pal-E's single account; customize statement descriptors, receipt templates, and build WKQ-branded surfaces ourselves. Pal-E remains merchant of record. ### What to Explore - Legal / compliance implications of each model for a nonprofit (WKQ) under a platform (Pal-E). What does merchant of record actually mean for tax reporting, chargebacks, 1099s? - Onboarding work: what does WKQ have to provide (EIN already in `~/secrets`, bank info, W-9, business profile) for each model? Who owns the Stripe dashboard login after onboarding? - Technical impact on basketball-api: per-tenant Stripe key, `Stripe-Account` header for Connect, webhook routing, test-mode parity. Rough shape, not implementation. - Payout flow: where does the money land today vs where it should land. Platform fee feasibility if using Connect. - How future pal-e tenants (MCD, other clubs, agency clients) would onboard under the chosen model. A decision optimized only for WKQ is the wrong decision. ### Success Criteria - [ ] Written recommendation picking one model (or a hybrid) with the reasoning captured. - [ ] Onboarding checklist for the chosen model: what WKQ provides, what Pal-E configures, in what order. - [ ] Technical-impact summary for basketball-api: which code paths change, which stay the same, approximate effort (s/m/l). - [ ] Follow-up implementation ticket(s) created with scoped AC once the model is chosen. Or: "no action needed" conclusion with reasoning if status-quo wins. ### Time-box One session. If the question can't be answered in that window, document findings so far and present options to Lucas for a direction call. ### Related - `project-pal-e-platform` - Sibling ticket: WKQ-branded post-purchase landing page - Sibling ticket: WKQ-branded payment receipt email - `~/secrets` contains WKQ EIN and related corporate docs — input data for whichever model is chosen