Migration map.

monetization_get — Read activation, payment providers or select a human action

Use this for the selected channel's activation overview, an explicit payment-provider observation or a human destination. OWNER or DELEGATEE with MANAGE_MONETIZATION is required. A delegate selecting consoleAction sales also needs MANAGE_SALES_OVERVIEW; orders/refunds actions need MANAGE_ORDER. These selected-destination checks precede activation observation. Source channel scope requires the same channelCode; account scope excludes this operation.

Strict input accepts required channelCode (1–512 characters, excluding dot/double-dot, slash, backslash, ASCII controls and DEL), optional view (overview by default, or payment-gateway), and optional consoleAction from the table below. The payment-gateway view cannot be combined with any consoleAction; this Zod refinement is not represented by the exported JSON Schema shape. No account ID, payment credential, raw URL, activation flag, financial amount, requestId, mutation revision or task identifier is accepted. Select the code through channels_list and channel_context_get.

{"channelCode":"selected-channel-code"}

With view omitted or overview and no consoleAction, the tool retains the fresh MONETIZATION overview: channel, activation.active, source-plan eligibility, stored base currency, paymentProviders.status:not-read and humanActions. It observes activation and matching channel state; confirmed means those stored observations, not an atomic snapshot or financial eligibility. Null/empty stored keys mean inactive; missing/malformed responses remain errors, and the internal key is never returned. Known FREE_TRIAL is ineligible under the source plan table; unknown plans remain unknown.

Select one console screen

Paths below are relative to /channels/{channelCode}/ on the centrally configured business console.

{"channelCode":"selected-channel-code","consoleAction":"payment-gateway"}

{"channelCode":"selected-channel-code","consoleAction":"orders"}

A selected action returns action_required / MONETIZATION_CONSOLE_REQUIRED, action, one matching destination when available, writesPerformed:false and eligibility:not-verified. verification has confirmed:false, channelAccessObserved:true, activationObserved, financialRecordsRead:false, financialActionCompleted:false and checkoutVerified:false. When activation was read, activation and plan observations accompany the guidance. The tool rechecks channel/operator/permission/credential context before returning it. The source console can still apply further prerequisites or redirect to its current currency screen.

If an explicit action's activation observation fails with UPSTREAM_HTTP_404, UPSTREAM_HTTP_5xx, UPSTREAM_UNREACHABLE or MONETIZATION_RESPONSE_UNVERIFIED, repeated access/context validation can still return that destination. activationObserved is false, prerequisiteError.code is preserved, and activation/plan observations are omitted. No inactive state, zero amount or eligibility is inferred. The same failure without consoleAction remains an error. Authentication, authorization, throttling (429) and changed context are not converted into this fallback.

The overview's humanActions expose tool/arguments recipes, which survive the single-address wrapper. Follow the relevant recipe to select its destination; do not expect nested console URLs. Point withdrawal uses channel_points_handoff with action.kind request-withdrawal, settlement uses settlement_handoff with action request-settlement, and product inspection uses memberships_get. The hidden experimental currency screen is not an advertised action.

Read payment providers

{"channelCode":"selected-channel-code","view":"payment-gateway"}

This view requires the same selected-channel monetization permission and private operator PAY settings. It reads channel context, obtains an ISSUER credential through the core authorization POST, reads methods from the separate PAY service, and rechecks context. It does not read activation. Default overview and consoleAction do not send either payment-service request. The overview's paymentProviders.nextStep points to this explicit read.

success / PAYMENT_PROVIDERS returns channel, paymentProviders.status:observed, providers and hasProviderRecords, plus the selected channel's payment-gateway destination. Provider codes are TOSS, PL_DOMESTIC or PL_GLOBAL; each method contains pgcode, TEST/LIVE deploymentType, currency, isRecurring, activatedAt and nullable deprecatedAt. Order and deprecated records are preserved; client keys and unknown fields are omitted.

writesPerformed:false means no business write; an authorization POST still occurs. authorization has purpose:scoped-payment-read and tokenPersistence:none. verification.confirmed:true covers validated observations only, with method:channel_payment_methods_context_read, atomicSnapshot:false, paymentProvidersRead:true, financialActionCompleted:false, visitorCheckoutVerified:false and settlementEligibilityVerified:false. No task, token persistence, payment or enrollment is created.

Missing configuration, authentication/permission failure, changed context and malformed/bounded-response errors fail without partial or invented providers. This view does not use the overview's console fallback. Connection serialization may return CONNECTION_BUSY instead of making a concurrent authorization request. After resolving the reported prerequisite, make a new explicit read; task resume does not recover this observation. Payment-provider guide specifies the request sequence, exact projection, error categories and operator configuration.

Reading and completion limits

This tool does not itself read sales statistics or order/refund records and does not submit financial actions. Use the separately permissioned sales_overview_get, orders_get or refunds_get, as suggested by readActions when authorized. Provider authorization/listing requires the explicit payment-gateway view; a payment-gateway consoleAction only supplies human guidance. Multi-currency switches, dual-payment settings and sample rates are not verified account settings. Membership, point and settlement observations have separate readers and source prerequisites. A destination is guidance, not evidence that its records were read or that activation, purchase, refund or settlement occurred.

For sales/orders/refunds handoffs, nextStep selects the corresponding authorized financial reader. Other handoffs retain the activation reread and point to readActions. Neither recipe proves that a financial action occurred. A person completes the requested action in the original console; no browser, task or financial writer is created.

Permission-scoped financial read recipes

Overview, payment-provider success and successful human handoffs include readActions. Each entry has purpose, tool, permission, scope, arguments:{channelCode}, prerequisites and financialActionCompleted:false. OWNER receives all three recipes; delegates receive only those matching their current permissions after this tool's own MANAGE_MONETIZATION requirement. A delegate with monetization permission alone may receive an empty list.

The recipes do not run a second tool, obtain another token, preflight PAY configuration or prove records exist. Each eventual read checks its own target, permission, configuration and authorization. No raw service URL or credential is included. The dedicated financial tools do not inherit this reader's monetization-permission requirement.

For consoleAction sales/orders/refunds, nextStep is that action's reader recipe. For other actions, nextStep remains monetization_get with an activation-only scope and a reference to readActions. Existing confirmation, fallback allowlists, single destination and zero-business-write behavior are unchanged. Input/output discovery schemas are unchanged; these are output semantics within the existing envelope.

Inputs