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. This configures cancellation fees and periods; it does not execute a cancellation or refund. The workflow guide separates this installation policy from event pricing and explains current permissions and recovery.

The later pending-admission correction is documented below.

Inputs and operations

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:

{"kind":"usage","isUsed":false}

rules edits 1–100 distinct existing rule IDs, with at least one of dayBoundary or fee per edit:

{"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

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.

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. 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:

{
  "channelCode": "L2NoYW5uZWxzLzk4",
  "pAppCode": "E00003"
}

Prepare a usage change using the observed policy ID:

{
  "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:

{
  "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. 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.

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.