publ betaReference (MCP guide)
Open publ console

settlement_handoff — Prepare a human settlement action

# settlement_handoff — Prepare a human settlement action

Prepare an original-console handoff for register-account, remove-account or request-settlement. Connect as OWNER or a delegate with MANAGE_SETTLEMENT for the selected channel. Hosted source admission requires its exact channelCode; the account resource does not expose this method.

Strict input fields are channelCode, optional currency (KRW/USD) and required action. Channel-code and currency-selection rules match [settlement_get](publ_settlement_get.md). action is a string enum, not an object. request-settlement must omit currency, including the base currency; this runtime rule is not fully represented by JSON Schema. Account actions use base or observed active alternate currency. No bank number, document, amount, requestId, dryRun, revision or task ID is accepted.

```json
{"channelCode":"selected-channel-code","action":"register-account"}
```

```json
{"channelCode":"selected-channel-code","currency":"USD","action":"remove-account"}
```

```json
{"channelCode":"selected-channel-code","action":"request-settlement"}
```

The tool observes and repeats selected context, plan, business readiness and applicable manual visibility. A gated response is SETTLEMENT_PREREQUISITE, with the same fail-closed rules as the reader. Successful preparation returns action_required / SETTLEMENT_HUMAN_ACTION, the requested action and exact console link, verification.confirmed:false, prerequisitesObserved:true, financialActionPerformed:false and writesPerformed:false.

Register/remove account opens account-info; request-settlement opens the source request screen. It does not read or upload bank account data, perform availability POST, submit registration/removal/settlement, reserve funds or create a job. A person must review the source screen's current prerequisites and decide whether to submit. A handoff does not prove permission, current account existence or financial completion. Demo omits real console URLs.

For request-settlement only, a prerequisite read or repeated prerequisite check can fail with UPSTREAM_HTTP_404, UPSTREAM_HTTP_5xx, UPSTREAM_UNREACHABLE or SETTLEMENT_RESPONSE_UNVERIFIED and still yield guidance after a fresh MANAGE_SETTLEMENT channel/actor/permission/credential context comparison. The result is action_required / SETTLEMENT_CONSOLE_REQUIRED, with the exact /channels/{channelCode}/settlement/request destination, action, prerequisiteError.code, eligibility:not-observed, writesPerformed:false and verification.confirmed:false / prerequisitesObserved:false / channelAccessObserved:true / financialActionPerformed:false. It omits the unverified selection, currencies and prerequisite observations. No balance or account absence is inferred. nextStep calls settlement_get with view.kind availability for a later current observation; the handoff itself performs no availability POST.

Register-account and remove-account do not receive this fallback because currency selection must be observed. Supplying currency on request-settlement still rejects before reads. Authentication, permission, channel/currency mismatch, changed context, and errors outside the allowlist remain failures. Known plan, business-document and hidden-visibility gates keep SETTLEMENT_PREREQUISITE; unavailable data does not turn those known gates into eligibility.

After the person completes an action, reread the applicable settlement_get view and report only observed state. task_status/task_resume cannot continue these actions; never fabricate a settlement task or repeat a payment to test completion. Authentication errors remain action_required where required by the common contract; no error becomes account absence or a zero balance.

## Inputs

| Field | Required here | Contract |
| --- | --- | --- |
| `currency` | No | `KRW`, `USD` |
| `action` | Yes | `register-account`, `remove-account`, `request-settlement` |