# ticket_refund_settings_get — read and prepare cancellation settings
Read the installed E00003 default cancellation policy or prepare an exact change for [ticket_refund_settings_apply](ticket_refund_settings_apply.md). This configures cancellation fees and periods; it does not execute a cancellation or refund. The [workflow guide](../guides/ticket-pricing.md#installation-default-cancellation-settings) separates this installation policy from event pricing and explains current permissions and recovery.
The later pending-admission correction is documented below.
## Inputs and operations
| Field | Required here | Contract |
| --- | --- | --- |
| `channelCode` | Yes | string; min length 1; max length 512; The exact channelCode selected through channel discovery. Do not supply a URL, channel numeric ID, account ID or credentials. |
| `pAppCode` | Yes | `E00003` |
| `refundPolicyId` | No | string; min length 1; max length 160; pattern `^[A-Za-z0-9_-]+$`; Exact resource identifier returned by this operation, never a title, unrelated row ID or URL. |
| `operation` | No | one of: `usage`, `rules` (by `kind`) |
| `operation.isUsed` | Yes | When `operation.kind` is `usage`: boolean |
| `operation.edits` | Yes | When `operation.kind` is `rules`: array; min items 1; max items 100 |
| `operation.edits[].refundPolicyItemId` | Yes | When `operation.kind` is `rules`: string; min length 1; max length 160; pattern `^[A-Za-z0-9_-]+$`; Exact resource identifier returned by this operation, never a title, unrelated row ID or URL. |
| `operation.edits[].dayBoundary` | No | When `operation.kind` is `rules`: integer; minimum 0; maximum 14 |
| `operation.edits[].fee` | No | When `operation.kind` is `rules`: one of: `none`, `fixed`, `percentage` (by `kind`) |
| `operation.edits[].fee.amount` | Yes | When `operation.kind` is `rules` and `operation.edits[].fee.kind` is `fixed`: string; pattern `^(0\|[1-9]\d{0,9})(\.\d{1,2})?$` |
| `operation.edits[].fee.percent` | Yes | When `operation.kind` is `rules` and `operation.edits[].fee.kind` is `percentage`: string; pattern `^(0\|[1-9]\d{0,9})(\.\d{1,2})?$` |
Business IDs contain 1–160 ASCII letters, digits, underscores or hyphens. Use returned policy/rule IDs, not numeric row IDs, names or URLs. Objects are strict, and null is not omission. There are no eventId, bookingId, currency, installation, consumer, credential, URL or raw-request overrides.
The following two examples are operation fragments, not complete tool arguments. `usage` sets the policy's `isUsed` flag without editing its rows:
```json
{"kind":"usage","isUsed":false}
```
`rules` edits 1–100 distinct existing rule IDs, with at least one of `dayBoundary` or `fee` per edit:
```json
{"kind":"rules","edits":[{"refundPolicyItemId":"observed-rule-id","dayBoundary":6,"fee":{"kind":"percentage","percent":"12.34"}}]}
```
Rule edits require an enabled default policy. The purchase-time row is read-only. Omit a row or field to preserve it, except the necessary next-row boundary adjustment. There are no row creation, deletion, reorder or per-row isUsed controls.
## Period and fee rules
| Existing row type | `dayBoundary` | Result |
| --- | --- | --- |
| `TYPE_DAY_FROM_PURCHASE` | Not editable | Its period, fee and other fields are preserved. |
| First `TYPE_DAY_BEFORE_EVENT`, with `daysBeforeEventMin:9999` | Integer 1–14 | Set this row's maximum to boundary and the next row's maximum to boundary minus one. The 9999 sentinel stays intact. |
| Later `TYPE_DAY_BEFORE_EVENT` | Integer 1–14 | Set this row's minimum to boundary and the next row's maximum to boundary minus one. |
| `TYPE_DAY_EVENT_IMMINENT` | Integer 0 or 1 | Change this last row's minimum. No next-row change is made. |
Edits are applied in observed row order, independent of the order of the edits array. The final rules must retain exactly one first purchase-time row, at least one before-event row beginning with the sentinel, and exactly one last imminent row. Explicit, ordered, nonoverlapping valid event-day ranges are required; an individually allowed boundary can still fail because it conflicts with neighboring rows. Inspect the prepared full-row request before saving.
| `fee.kind` | Input | Stored meaning |
| --- | --- | --- |
| `none` | No other fee fields | NONE, with amount and percentage set to zero. |
| `fixed` | Positive decimal-text `amount` | FIXED cancellation fee in the channel currency; unused percentage becomes zero. |
| `percentage` | Decimal-text `percent` from 0 to 100 | PERCENTAGE cancellation fee; 12.34 becomes ratio 0.1234, and unused amount becomes zero. |
Amounts and percentages allow at most ten integer digits and two fractional digits, with no sign, grouping, exponent or unnecessary leading zeros. Runtime limits are stricter than that string shape. A percentage of zero is permitted and remains PERCENTAGE; it is not the NONE selection. Fixed zero is invalid.
KRW uses the same exact-channel minimum exceptions listed in the [tier-price rules](ticket_pricing_apply.md#price-rules). USD fixed fees always start at 1.00, including channels whose tier-price minimum is 0.30; the tier-price USD minimum must not be reused. No fee value is an instruction for how much money to refund.
## Complete read and preparation examples
Discover the installation default without preparing a mutation:
```json
{
"channelCode": "L2NoYW5uZWxzLzk4",
"pAppCode": "E00003"
}
```
Prepare a usage change using the observed policy ID:
```json
{
"channelCode": "L2NoYW5uZWxzLzk4",
"pAppCode": "E00003",
"refundPolicyId": "refund-policy-example",
"operation": {"kind": "usage", "isUsed": false}
}
```
Prepare a percentage fee on an observed editable row while preserving its period:
```json
{
"channelCode": "L2NoYW5uZWxzLzk4",
"pAppCode": "E00003",
"refundPolicyId": "refund-policy-example",
"operation": {
"kind": "rules",
"edits": [
{"refundPolicyItemId": "refund-rule-example", "fee": {"kind": "percentage", "percent": "12.34"}}
]
}
}
```
These are illustrative targets, not observed records or authorization. The usage and rules examples are independent alternatives; rules cannot be prepared after disabling the policy until a separately prepared enable operation completes. Replace every target with current authorized observations.
## Observations and result
The getter reads `GET /seller/api/v3/refund-policy` twice and requires matching business snapshots. The policy contains 1–100 rows in strictly increasing sortNumber order with unique numeric IDs, business IDs and sort values. Policy/row consumers and row parent IDs must agree with the installation; any returned policy currency must match the current channel. Unknown returned fields are retained, and generated insertedAt/updatedAt timestamps are excluded from business comparison. This is not an atomic snapshot.
Success returns `code:TICKET_REFUND_SETTINGS`, `refundPolicy`, `revision`, `verificationScope` and `writesPerformed:false`. Preparation additionally returns `request`, which is null for an already-equal operation. Null does not mean a save occurred. Copy `refundPolicy.refundPolicyId`, the preparation revision and the unchanged complete operation into apply. A discovery-only revision cannot authorize a mutation; changing any setting requires new preparation. The getter creates no job even though the shared result carries task type `commerce-ticket-refund-settings`.
Discovery/usage resolves the exact installation settings screen; rules resolves its cancellation-rule editor. See [the destination contract](ticket_refund_settings_apply.md#console-destination). A current link does not verify a write or customer outcome.
Malformed or inconsistent policies, disabled rule editing, read-only row selection, invalid periods and changing discovery snapshots fail with `TICKET_REFUND_SETTINGS_UNVERIFIED` or input validation errors. Invalid fixed prices can return `TICKET_REFUND_FEE_INVALID` or the underlying KRW `TICKET_PRICE_INVALID`. Resolve current permissions and context rather than substituting another policy/app. No booking, event-specific policy copy, cancellation, customer charge, refund or actual restoration is executed or verified by this read.
## Preparation and pending policy work
They correct admission to the existing cancellation-settings workflow without changing its inputs, transport or task type.
Rules and usage share one protected policy resource. A rule save replaces the full observed row set, so selecting a different refundPolicyItemId does not create an independent resource. Protection follows the verified environment/consumer/refundPolicyId in the existing task-store namespace, not a requestId, rule ID or credential version.
Get and dryRun remain observation/planning. They neither acquire a mutation claim nor resolve, release or enroll earlier pending work. A fresh revision or request:null can therefore still produce TICKET_REFUND_SETTINGS_PENDING on real apply. Matching visible values, inverse usage and selecting another rule cannot settle the original uncertain operation. See [whole-policy admission and recovery](ticket_refund_settings_apply.md#shared-policy-admission-and-recovery).
Only original-task observation followed by durable completion can settle a registered pending effect. A missing guard entry does not prove there is no older unregistered sent journal. Pre-upgrade journals need separate rollout inspection or original-task recovery; this getter performs no automatic inventory or migration. Other grants/namespaces and manual or external changes are outside this protection. This remains configuration preparation, not cancellation, refund execution or a financial verification.
