Developer guide · commerce sections checked 3 October 2026

Can a plugin serve SaaS customers without selling upgrades?

Yes: design for the task an existing customer is already entitled to use. Do not make that task depend on selling a digital subscription, upgrade or credits through the plugin—even by sending the customer to external checkout.

The inspected public-plugin guidelines distinguish existing paid entitlement from permission to sell. They allow included existing-account use and truthful explanations of unavailable features; they prohibit digital sales/upsells, in-plugin subscription-plan display, subscription initiation and upgrade promotion. This is a documented boundary, not this design's review approval. Plugin guidelines · Commerce and monetization, B01–B04. Checked 3 Oct 2026.

Replace the upgrade flow, not the customer task

Hypothetical design review / NOT RUN. A fictional read-only project-status SaaS has separate current-status and 90-day-history features. In this invented case the account may read the project, current status is included, and history is not. No account or API supplied these conditions. This is not Meeting Evidence or a shipped integration.

Request: “Show Atlas's 90-day status history.”

Before → boundary → replacementProposed copy, not an observed host response. No transaction link is implemented.

Before
“History requires Pro. Upgrade now or buy history credits: [external transaction destination — not provided].”
Rejected design: the denial starts a paid digital upsell.
Boundary
Missing entitlement is not a purchase prompt. Sending the user off-host does not repair the prohibited digital category.
Documented constraint: B03/B04, Commerce and monetization.
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 copy recommendation. Offer the alternative only if genuinely included and authorized; do not silently substitute it or withhold included work.

Our proposed server-led sequence

Verify identity and required scopes.
If the provider connection is missing or expired, stop with an authentication explanation—not a plan diagnosis. Do not request credentials in chat.
Authorize the requested project.
If access is denied, stop without revealing project data or another account's entitlement. Payment is not a permission remedy.
Check the actual feature entitlement.
If unknown, say it could not be verified; do not invent “upgrade required.” If absent, explain truthfully without a paid action.
Deliver the included read—or offer an included alternative.
Use actual source/time context after authorized retrieval. Offer a different included task only with consent; no invented result or deliberate degradation.

Credential/scope verification and server-side permission enforcement are documented obligations. The exact identity → resource → feature sequence and the fallback are our design synthesis; UI or model copy is not enforcement. Authentication · Implementing token verification, Security & Privacy · Authentication & authorization / Data handling, B12/B13. Checked 3 Oct 2026.

Six proposed cases: copy, boundary, next decision

Open the case matching your design. All six are hypothetical design review / NOT RUN—not observed tests, a compliance score, a model-success rate or official submission cases. B-IDs are our source-map references, not OpenAI rule numbers.

C1 · Existing paid customer; feature included · NOT RUN

Proposed copy, after actual authorized retrieval: “Here is the requested current-status summary: [actual source-backed result and timestamp]. No project changes were made.” Bracketed text is a template, not retrieved data.
Documentary boundary · B02/B12/B13: Included service use still requires valid credentials, scopes and resource permission. Commerce and monetization; Authentication; Security & Privacy.
Next decision: Deliver the actual included read. Gather reliability evidence later with lawful access; no host result is established here.

C2 · Authentication expired or project access denied · NOT RUN

Proposed copy: Authentication: “I can't verify this provider connection. Please authenticate the intended existing account.” Resource: “I can't access the requested project with this connection. Verify the intended account and project permissions.”
Documentary boundary · B12/B13: An access failure is not a paid entitlement diagnosis. Do not reveal another account's project data or plan. Authentication · token verification; Security & Privacy · authorization.
Next decision: Stop and recover legitimate connection/permission access—not a purchase. Do not request credentials in chat.

C3 · Feature, tier or existing allowance absent · NOT RUN

Proposed copy: “The requested history feature is unavailable with this account's current entitlement.” If the verified reason is exhausted allowance: “This account has no remaining allowance for that feature.”
Documentary boundary · B03/B04: Explain the real reason without displaying/promoting plans or initiating upgrade, subscription, credits or checkout. A permitted informational destination is distinct from a transaction. Commerce and monetization · entitlement explanations.
Next decision: Use linkless denial by default. Offer only genuinely included, authorized work; an optional link needs the destination review below.

C4 · New digital sale through external checkout · NOT RUN

Proposed replacement copy: “This plugin does not sell subscriptions or credits.” No buy/subscribe destination is provided.
Documentary boundary · B03/B04/B08: Off-host routing alone does not change the prohibited digital category. Physical-goods checkout documentation is not SaaS eligibility. Commerce and monetization; Checkout API · Overview.
Next decision: Remove the transaction route. Reconsider whether the already-entitled customer task has standalone utility without the sale.

C5 · ChatGPT surcharge or artificial degradation · NOT RUN

Proposed copy, after real access/entitlement checks: “I can provide the included current-status summary here without a ChatGPT-only surcharge.”
Documentary boundary · B05: No ChatGPT-penalizing fees or worse equivalent external-service feature in ChatGPT. A genuine missing entitlement is different from withholding included work to force a visit/upgrade. Commerce and monetization · equivalent-feature/fee paragraph.
Next decision: Remove the artificial fee/restriction. If a real limitation prevents reliable delivery, state it and reconsider launch rather than invent a paid fix.

C6 · Checkout API mistaken for SaaS permission · NOT RUN

Proposed internal design note: “This checkout reference does not establish permission or enabling for our SaaS payments.” No customer payment flow is designed.
Documentary boundary · B07–B11: Physical-goods eligibility, saved methods, new credentials, private-beta payment sheet and explicitly enabled integrations are different conditions. Guideline/API/UI scope remains unresolved. Guidelines · Checkout; Checkout API; UI · Offer checkout.
Next decision: No SaaS checkout implementation earned. A physical-goods builder needs the integration-specific clarification below, not an inferred digital exception.

What makes an information link different?

The guidelines permit entitlement information but disallow checkout/transaction destinations and pages explicitly initiating upgrade, subscription or purchase. Judge actual content, behavior and redirects for the relevant user state, not a label such as “Learn more.” Commerce and monetization · allowed/disallowed entitlement links, B04. Checked 3 Oct 2026.

No live destination was audited. Our conservative recommendation is to omit an unverified link; the denial above needs none. Stop linking if behavior is unknown, redirects reach a transaction, or the page explicitly starts the prohibited process. Ambiguity needs clarification, not an “approved” badge. The inspected text establishes neither a universal ban on prices appearing on all informational pages nor a loophole created by an informational label.

Small checkout qualification: conflicting / unresolved scope

The guidelines' Checkout section requires own-domain external checkout, notes select-partner beta Instant Checkout, and bans other embedded third-party checkout. API/UI guidance separately describes non-redirect merchant-saved-method purchases for eligible physical goods, with no new payment credentials collected. The ChatGPT payment sheet is private beta; UI guidance names enabled integrations. Guidelines · Checkout, Checkout API · saved methods / private beta, UI · Offer checkout in your UI, B07–B11. Checked 3 Oct 2026.

This is a source-scope tension, not a dated policy change. No source precedence, universal saved-method access, digital-sales exception or enabling for this SaaS/pool is established. UI's conditional reference to explicitly enabled other categories does not supply that evidence.

The targeted reliance question for a physical-goods builder

May this particular integration use merchant-saved methods without private-beta payment-sheet access despite the general checkout restriction? What approval/enabling and documented exception or scope apply?

Unasked: no support contact or answer was obtained. This question does not reopen the SaaS digital-sales boundary.

Two opportunity hypotheses—not sales promises

Our inference · no demand or revenue measurement

Existing SaaS: one authorized customer task

An independently sold external service might have a useful included-customer integration. That is a business hypothesis, not permission for the plugin to become its acquisition/upgrade funnel or a finding about the outside service's legal/contractual position.

Can the already-entitled task be useful without a plugin upgrade sale? If not, reject this launch thesis.
Does the provider UI or an ordinary prompt already suffice? Identify a specific added result the customer can inspect.
Who owns server authorization, entitlement truth and customer support when access is unavailable?
Would wrong-project data, stale/unsupported summaries, confusing denials or inability to connect make it unacceptable? Specify a lawful observation that could falsify utility.

These are proposed falsification questions, not interviews, forecasts, conversion results or measured value. Purpose and originality / Quality and reliability supplies the documented utility/reliability expectation (B15); the questions are ours.

Specialist or team: a maintained repeatable process

A narrow skill/package might reduce repeated setup where a tested procedure matters. It assumes genuine utility beyond ordinary prompting, host/tool compatibility, accountable maintenance and an appropriate channel. Regression cases make changes inspectable; they do not prove better outcomes.

Falsify it if the procedure adds no observable value, introduces unacceptable failures or requires access unavailable to intended users. Compare bounded outputs, retain failures and seek intended-user feedback before asserting value. This retained hypothesis has no measured time savings or demand finding.

Do not make an ad-only plugin or turn listing subtitles/descriptions into subscriptions, pricing, trial, discount or promotion advertisements. Advertising / Plugin name, description, and prompts, B06/B14. Checked 3 Oct 2026.

Keep the unrefreshed dependencies dated

Distribution, payout, placement and provider bills · retained 29 September

No universal plugin-sale payout or GPT Store-style revenue program was verified in the saved study. Public review/distribution and discretionary enhanced placement do not guarantee recommendation; workspace roles/connection policy can limit access; hosts shape invocation; the provider enforces service resources and limits. A listing grants none of them.

Saved commerce/discovery rules, Review and distribution, Workspace management, MCP server. Saved observations checked 29 Sep 2026; payout/placement were not surveyed again today.

Provider subscriptions/credits and host model/API usage remain separate bills. The four architecture records retain September provider-price observations—not current checkout quotes or evidence of free agent usage.

Five official pages were inspected on 3 October within observed clock brackets 12:57:28–12:58:37 UTC, not exact per-request HTTP timestamps. Existing SaaS constraints were reconfirmed; saved-method scope/parity/auth detail was newly inspected. No changed rule/date was established. No account, provider API, host, payment, destination or public review test ran. Read the dated method and evidence limits.

Separate identity, resource access and entitlement · Plan distribution and maintenance