# Monetization settings and human financial actions
`monetization_get` begins the core "수익창출" area with a single read workflow. It combines selected-channel identity/plan/base currency, monetization activation, and a second channel read. It returns human console routes for the next financial operation.
A subsequent [membership read workflow](memberships.md) adds membership cards, benefits and subscription-product list/editor observations.
Source evidence: `ChMonetizationContainer.tsx`; `MonetizationSettings.tsx`; `ChannelCurrency.tsx`; `PaymentGateway.tsx`; `useTruthTableForChannelPlan.tsx`; `inChannelStore/monetizationStatus` saga/reducer/selectors; `repositories/api/inChannelStore.ts`; `ProfitableClient.getPaymentMethods`, `getProfitableConfig`; channel and monetization routes.
## Current consolidated delivery and remaining scope
The former 106-tool count is historical, not a current inventory or a completion measure. See the [monetization guide](../guides/monetization.md) for the current read/configure/human-action choices.
| Financial purpose | Implemented interface | Current boundary |
| --- | --- | --- |
| Activation, plan and base currency | monetization_get overview | Observes stored status; no activation writer, provider approval or checkout claim |
| Settings, gateway, plan, membership creation, sales, orders, refunds | monetization_get.consoleAction | One exact human console destination; target financial records are not read |
| Membership/card/benefits and subscription products | memberships_get; membership_create; membership_update | Observed choices and supported metadata/access composition; creating a membership does not create a sale product |
| Membership product creation | membership_product_create | Source-supported offer, creation price and terms; no purchase, charge or implicit activation |
| Existing membership product configuration | membership_product_apply | Alias/purchase methods, selling state and eligible extension terms; existing base price/title/type/period remain locked |
| Membership/product/coupon destinations | memberships_get detail consoleAction | Verified mid/product target; coupon type checked; one exact creation/edit/list/coupon screen |
| Existing WEB Point products | channel_point_product_apply | Display name/bonus and visibility with productsRevision; base price/quantity preserved; no creation/deletion |
| Point setup/policy/products/provisions/withdrawal destinations | channel_points_handoff | Human navigation; optional for supported configuration, required for financial submission; selected identity checks remain |
| Monthly/operation records, account metadata, balance and availability | settlement_get | Source plan/business/visibility/currency gates; masked account number; read-only availability POST, never a transfer |
| Settlement request and account registration/removal | settlement_handoff | Human only; request screen is distinct from point withdrawal; account routes require observed currency selection |
| Refund video/download history tabs | refunds_get view:history | Derive buyer/invoice scope, repeat bounded reads and provide the exact tab; no complete-history or refund-eligibility claim |
| Installed-pApp internal commerce/content management | Pending separate workflows | No fabricated records or new API coverage from a link |
Select `consoleAction` on monetization_get: activate-monetization,
manage-monetization, payment-gateway, change-plan, memberships, create-membership,
channel-points, sales, orders or refunds. The default remains a fresh overview.
Activation opens plan only for observed inactive FREE_TRIAL, otherwise settings.
Delegates require MANAGE_MONETIZATION plus MANAGE_SALES_OVERVIEW for sales or
MANAGE_ORDER for orders/refunds. These additional gates match PnLPrediction and
Orders source containers. The hidden experimental currency tab is not advertised.
Each selected action returns action_required and one destination. humanActions
contain callable tool/arguments recipes, so the agent can ask for another screen
without losing it to the single-address finalizer. Point withdrawal recipes call
channel_points_handoff; settlement requests call settlement_handoff. Selected
membership detail consoleAction offers edit-membership, manage-products,
create-product, edit-product and manage-coupons. Product actions require an
observed subscriptionProductId; coupon management requires a COUPON_ type.
When activation or unselected point prerequisites are unavailable, the relevant
human handoff rechecks current channel authorization and unchanged actor/context
before returning its exact screen with an error code and unknown eligibility.
Only bounded 404/5xx/unreachable/malformed or bounded point-response-size errors
qualify. An ordinary get still fails instead of inventing state. Selected
products/tickets, authentication, permission and context/identity/currency errors
never use this fallback. Settlement request has an equivalent bounded fallback
and no availability POST; account registration/removal remain strict because the
route needs observed currency selection. No partially read finance data is
returned in fallback output.
ChMonetizationContainer, ChMonetization/routers, channel/channel routers, Orders/Container and PnLPrediction/PnLPredictionContainer. Existing REA evidence does not approve this candidate.
## Overview screen composition and request contract
| Step | Source request | Bridge meaning |
| --- | --- | --- |
| Selected channel | GET `/seller/api/v1/channels/:channelCode` | Resolve ID, site title, currency and current plan with the selected channel bearer, no channel/consumer header |
| Monetization status | GET `/seller/api/v1/channel-management/in-channel-store/key` | Same channel bearer and `x-publ-channel-id`; unwrap `data.key` and return only `Boolean(key)` |
| Stable channel check | Repeat channel GET | Require the same ID, code, title, currency and plan before publishing the composed result |
Every overview request requires HTTP 200 and the source data envelope. Null or an empty key means inactive; a missing/malformed key is an error, not inactive. A nonempty key matches the source Boolean conversion and is never returned, logged or journaled. The overview uses the general API origin; it needs no DNS, channel-environment, payment-service origin or resource-upload settings. The explicit provider view has the separate contract below.
The source container permits OWNER or DELEGATEE with MANAGE_MONETIZATION and rejects CREATOR. The bridge checks that rule using the selected channel credential before the first request and around subsequent responses; an account bearer is never a fallback. A changed connection, seller identity or token blocks the result. Local claim parsing is a parity guard, not JWT signature/expiry validation; publ remains the authorization authority. Channel code, ID and returned state must agree. The bridge uses the existing connection lock and does not create a task or mutate credentials.
Known plan eligibility comes from the exact source plan table. FREE_TRIAL is false; the other twelve listed source plans are true, including ENTERPRISE_TRIAL and PARTNER_TRIAL. The separate dialog helper's unused check is not the executed activation guard. Missing or new plan names return null, not an inferred entitlement.
The source currency view reads the channel base currency, but its tab is commented out and the component contains temporary local multi-currency/dual-payment switches and a sample amount. The bridge reports only the stored base currency and explicitly marks those other capabilities unverified. It never emits the sample as a rate, amount or supported account setting.
## Human actions and unfinished finance scope
The source can activate monetization with a POST after its plan check. Payments, invoices, service-plan/billing changes, refunds, withdrawals and settlement requests remain human operations. Source-supported product pricing and sales-condition configuration use the dedicated writers above; they are not payment execution.
PaymentGateway gets providers from ProfitableClient: POST `/profitable/authorize` with ISSUER/channelId against the merchant origin, followed by GET `/api/v1/checkout/payment-methods/individual` against the separate publ-pay origin, including its configured API key. This is not a field embedded in channel detail. The default overview performs neither and retains paymentProviders.status:not-read. Explicit view:payment-gateway implements the composed read, with private configuration, bounded transport, selected-channel checks and secret omission. See [the provider contract and scenarios](payment-gateway.md). No payment token, API key, provider client key or identity document is accepted as MCP input or exposed in results.
Central route helpers cover these source paths; the current callable choices and dedicated workflows are specified above. The experimental currency route is retained only as historical source metadata, not an advertised action. Each link uses the central console configuration, never an API host or caller URL. The tool neither opens the link nor sends inquiries. Other console permissions can still apply. A link does not count the target screen's APIs as implemented and does not prove access or completion. Demo returns no actual console links.
Installed-pApp internal sales/catalog operations remain separately scoped. Detailed page editing remains excluded by the earlier user scope.
`verification.confirmed:true` means the stored channel fields and activation indicator were freshly observed and checked within this read. These sequential calls are not an atomic snapshot or a causal proof of a prior human change. After a person acts, reread; no task status/resume applies. No financial action is submitted in any state, including errors.
## Hosted admission and account integration
The hosted selected-channel scope admits the new read only for its exact channelCode. It does not admit account tools or a new monetization task type. The prior five owner account tools are added to the account allowlist, with account-profile/seller-contact recovery types admitted only there. No favicon upload is exposed by the hosting console. These guards are code integration, not a production tenant-isolation or real authorization PASS; the trusted hosted auth/state adapter remains separate work.
## Plan reconciliation
For the historical agent-operations plan: Implemented, statically checked, independently executed and live verified are distinct states.
