Stripe Terminal plugin
The fixed Dashboard renders Plugin settings from returned key_plugin configuration categories. Stripe Terminal category presence, schema, readers, credentials, and payment behavior are external/deployed boundaries.
Historical schema evidence
Preserved project evidence recorded Sandbox mode, production and sandbox publishable key, secret key, webhook secret and reader ID fields, plus Stripe terminal simulated card presentment (sandbox).
Those labels do not establish current installation, values, required state, validation, environment selection, reader registration, webhook delivery, simulation, payment, or refund behavior.
Fixed category and mutation boundary
AllSettings passes returned plugin categories to SettingsMenuOptions; a numeric category opens generic SettingsList. Config edits stage locally and Save persists changed items sequentially; type-5 image configs save immediately. API-core config routes do not establish Terminal schema or device/payment behavior. The separate Developers → Plugins manager owns install/root/iframe actions. None ran.
Keys, webhook secrets, readers/devices, merchant/account IDs, endpoints, payments/transactions, cards/customers, wallet/value, refunds, orders, payloads, and provider responses remain excluded.
Source-only boundary
/all-settingsis level-0 routed; Plugin settings requires returned plugin categories.- The retained screenshot is sanitized historical navigation evidence, not current installation/configuration proof.
- No runtime/GET/HEAD, reader/device, credential/webhook, payment/billing/terminal/refund, config/image write, plugin-manager action, job, provider, order, or outbound call ran.
- Re-entry requires immutable Dashboard/API and Stripe Terminal serving receipts plus a credential-free synthetic category/device/payment fixture with all config reads/writes, provider egress, terminals, payments, orders, and webhooks intercepted.
Related guides: Online payments · Developers · Plugin settings