Research report · 3 October 2026
Can a plugin serve SaaS customers without selling upgrades?
Existing paid entitlement is not permission to sell an upgrade. Authentication/resource authorization is not feature entitlement. A useful included-customer task can be the launch thesis; a plugin-dependent digital sales funnel needs redesign.
The documented boundary and our recommendation
The public-plugin guidelines allow an existing paid-account user to access included features. They prohibit digital subscription/content/token/credit sales and indirect upsells, in-plugin subscription-plan display, new subscriptions and upgrade promotion. Truthful unavailable-entitlement explanations are different from purchase initiation: a linked information page must not be a transaction destination or explicitly begin upgrade, subscription or purchase. Commerce and monetization, B01–B04.
The inspected text also disallows ChatGPT-penalizing fees and worse equivalent external-service features in ChatGPT. It requires legitimate standalone utility, not advertising, and restricts subscription/price/trial/discount/promotion language in listing subtitles/descriptions. Commerce and monetization / Advertising / Plugin name, description, and prompts, B05/B06/B14.
Our recommendation: serve the already-entitled task, redesign the digital sales flow, or obtain narrow clarification for unresolved reliance. An independently sold SaaS with a useful customer integration is a hypothesis—not evidence of revenue, retention, demand or permission to use the plugin as its sales funnel.
One worked replacement, six unperformed cases
Hypothetical design review / NOT RUN. One fictional read-only project-status SaaS has current status and 90-day history. Assume the account can read the requested project, current status is included and history is not. No account/API established those assumptions; this is not a shipped product or Meeting Evidence release.
- Before
“History requires Pro. Upgrade now or buy history credits: [external transaction destination — not provided].”
Rejected design; no link implemented.
- Boundary
The denial becomes a digital purchase/upsell. External checkout does not change that category boundary.
Commerce and monetization, B03/B04.
- Replacement
“90-day status history is not included in this account's current entitlement. I can summarize the current project status instead, if you want.”
Our linkless recommendation; offer that fallback only if truly included and resource-authorized.
Our proposed sequence is provider identity/scopes → requested-project permission → actual feature entitlement → included read or neutral denial. Missing/expired credentials and denied project access are access failures, not upgrade opportunities. Unknown entitlement stays unknown. Server token/scope/permission enforcement is documented; exact ordering and fallback are our synthesis, not an official implementation recipe. Authentication · token verification, Security & Privacy · authorization / Data handling, B12/B13.
- C1 · existing paid customer; feature included · NOT RUN
- Deliver the actual authorized read, with real source/time context. Included use does not waive permissions. B02/B12/B13.
- C2 · expired identity or denied project access · NOT RUN
- Stop and explain legitimate connection/permission recovery; no plan diagnosis or cross-account disclosure. B12/B13.
- C3 · feature/tier/allowance absent · NOT RUN
- Truthful linkless denial; only genuinely included alternatives or conditional information, no plan promotion/purchase. B03/B04.
- C4 · external new digital sale · NOT RUN
- Remove the transaction route and reconsider included-customer utility; physical-goods checkout is not SaaS permission. B03/B04/B08.
- C5 · channel surcharge/artificial degradation · NOT RUN
- Remove the penalty or manufactured restriction; state real limitations rather than invent a paid remedy. B05.
- C6 · API treated as SaaS permission · NOT RUN
- Do not build SaaS checkout on an inferred exception. Category, integration enabling and implementation interface are separate. B07–B11.
Copy templates, each documentary boundary and next decision make the cases usable before building. Six hypothetical cases are not a compliance score, observed tests, model-success rate or official submission cases.
No live destination was audited. For a proposed entitlement-information link, inspect content, behavior, redirects and relevant user state—not “Learn more” wording. Our recommendation is to omit an unverified link. The inspected text establishes neither a universal ban on prices on all information pages nor an informational-label loophole for starting a transaction. Entitlement-link conditions, B04.
A small physical-goods caveat: conflicting / unresolved
Guidelines' Checkout wording requires own-domain external checkout, notes limited beta Instant Checkout and bans other embedded third-party checkout. Checkout API/UI guidance separately describes non-redirect merchant-saved-method purchases for eligible physical goods, without collecting new credentials. The ChatGPT payment sheet remains private beta; UI guidance identifies enabled integrations. Guidelines · Checkout, Checkout API · saved methods / private beta, UI · Offer checkout in your UI, B07–B11.
No source precedence, universal saved-method availability, digital exception or enabling for this SaaS/pool is established. This is newly inspected detail and a source-scope tension, not evidence of a dated policy change.
The integration-specific reliance question—not yet asked
May this physical-goods integration use merchant-saved methods without private-beta payment-sheet access despite the general checkout restriction? What approval/enabling and documented scope or exception apply?
No support contact or response was obtained. This does not reopen the digital-sales boundary.
How could the business hypothesis fail?
Can the included task be useful without an upgrade sale? Does a provider UI or ordinary prompt already suffice? Who owns authorization, entitlement truth and support? Would wrong-project data, stale/unsupported summaries, confusing denial or inability to connect make the utility unacceptable? These are proposed questions for lawful observations, not forecasts or measured value. Purpose and originality / Quality and reliability, B15, supports the utility expectation; these questions are ours.
Source comparison and truthful time basis
Five canonical official pages were independently opened and consequential sections inspected. Observed clock brackets around tool calls span 3 October 2026, 12:57:28–12:58:37 UTC—not individual HTTP fetch timestamps. Durable locators are the headings below; the pages establish no publication/change date. B-IDs are this study's editorial references, not official policy numbers.
- B01–B07/B14/B15 · Plugin guidelines
- Introduction / How to use these guidelines; Commerce and monetization and entitlement links; Checkout; Advertising; Plugin name, description, and prompts; Purpose and originality / Quality and reliability. Existing SaaS restrictions reconfirm the saved 29 September Business/S11 claims. Precise parity/listing detail newly inspected. Checkout wording remains conflicting / unresolved with the implementation pages.
- B08–B10 · Checkout API reference
- Overview / Recommended Monetization Approach / External Checkout / Checkout with saved payment methods / Checkout with the ChatGPT payment sheet (private beta). Newly inspected physical-goods implementation detail; no universal eligibility inferred.
- B11 · Add UI to your MCP server
- Offer checkout in your UI / Use external checkout by default / Use saved payment methods / Use the ChatGPT payment sheet. Newly inspected; conditional enabling does not establish a SaaS exception. Guideline/API/UI scope tension unresolved.
- B12 · Authentication
- Custom auth with OAuth 2.1 → Components / Implementing token verification, plus authenticated-profile declaration caveat. Narrow server-enforcement claim newly inspected; not an OAuth implementation study.
- B13 · Security & Privacy
- Data handling / Prompt injection and write actions / Authentication & authorization. Narrow server enforcement/minimization reconfirmed; no security test.
Changed with evidence: none. Newly inspected is not newly released. The new evidence JSON timestamps record observed saved-ledger review time, not exact web-fetch time. Today's Guidelines retrieval does not refresh the paired annotation conflict.
Completion boundary and retained evidence
The bounded study and edited decision aid are prepared. No lawful account, host, provider API, checkout/payment, protected portal, support contact, destination/redirect audit, package/kit/widget, media or demand work was performed. Real task evidence and integration-specific clarification need separate authorization. Local candidate preflight and Runtime browser repeat, database, approvals, delivery and publication are separate gates—not study findings or claimed passes.
Original Meeting Evidence 0.1.0 source/downloads, historical kits/logs/reports, 1 October's 33 checker assertions and ten actual-host NOT RUN specifications, and 2 October's 49 recorder assertions are retained at their original evidence scopes. No engineering rerun occurred. Endpoint conflict stays 2 October; paired annotation conflict stays 1 October. Catalogue, provider prices, migration, chronology, workspace sync, payout and placement retain saved September dates.
Developer-first is owner strategic preference, not measured demand. Analytics is disconnected, not evidence of zero readership. The supplied 2 October guide release is published; this candidate is not a subsequent publication receipt.
Use the Business decision aid · Return to the dated research archive