Payment gateway provider read

The subsequent sales overview adds one tool/workflow and shares the bounded issuer transport; provider behavior remains separately reviewed. Existing overview and human console calls retain their prior behavior. The view is mutually exclusive with consoleAction. A financial submission is still a human console operation.

Compared sources: ChMonetization/pages/PaymentGateway.tsx, channel provider and channels saga, profitable-js/src/client.js (authorize, getPaymentMethods, _request), profitable.dto.ts and getProfitableConfig.ts. The source's visible provider state is based on a nonempty provider array, not successful checkout. TOSS remains a source enum even though its screen branding is commented out. The bridge preserves records without inventing additional supported providers, branding, inquiries, prices or activation states.

Composed request contract

Both payment-service requests carry the configured apiKey query field because that is the source wrapper contract. They never carry a channel/consumer header, account bearer, cookie or caller-provided URL. Redirects are rejected; there is no automatic retry. Issuer lifetime is not inferred or verified; per-call means the bridge retains the credential only during this observation. Token authorization accepts successful JSON HTTP200/201; the method read requires HTTP200. A data envelope and no application error are required.

Responses are bounded to 2 MiB, 100 provider rows and 1000 methods per row. The projection retains provider code, method pgcode, TEST/LIVE, currency, isRecurring and ISO activation/deprecation timestamps (nullable deprecation). Client keys, unknown fields, issuer tokens and API keys are omitted. No token is cached between calls, persisted to credentials or written to a task journal. No financial amount, invoice, purchase, provider enrollment or transfer is sent.

An observed empty list returns hasProviderRecords:false. An error or missing configuration never becomes an empty list or inactive monetization. Deprecated rows remain observations; the bridge does not infer that a method is usable. Sequential reads are not atomic. Confirmation is restricted to validated fields, not provider approval, legal eligibility, live/recurring checkout or settlement. The one console address is the centrally configured channel payment-gateway path; no external form or mail is opened or sent by the bridge.

Private operator configuration

Stdio and the packaged hosted adapter support PUBL_PAY_API_ORIGIN together with exactly one of PUBL_PAY_API_KEY or PUBL_PAY_API_KEY_FILE (absolute file path). Use an environment-specific deployment secret reference; do not put key values in source, settings JSON, MCP inputs, prompts, PRs or public documentation. PUBL_PAY_API_ORIGIN corresponds to the source REACT_APP_PUBL_PAY_API_HOST, and the private key corresponds to REACT_APP_PUBL_PAY_API_KEY. The merchant/core origin remains PUBL_API_ORIGIN. There is no guessed pay origin or inherited key from another environment. Operator origins require HTTPS (local loopback HTTP is accepted for isolated fixtures), with no path, userinfo, query or fragment.

Omitting both settings leaves other workflows available and makes only the explicit provider/sales/order/refund read fail with PAY_SERVICE_UNCONFIGURED. Partial/invalid configuration fails startup. Configured values are internal runtime fields; MCP output exposes only the existing environment/core-origin connection metadata. The operator must suppress query secrets in outbound proxy/access logs. The bridge emits no request URLs or upstream error bodies into MCP errors. Human setup/inquiry remains available through consoleAction:payment-gateway without calling the separate service.