# `PhoenixKit.Migrations.Postgres.V162`
[🔗](https://github.com/BeamLabEU/phoenix_kit/blob/v2.13.11/lib/phoenix_kit/migrations/postgres/v162.ex#L1)

V162: First-class payment-option linkage on billing orders.

An order records HOW it is to be paid via `payment_method`, a small closed
vocabulary (`bank`, `stripe`, `paypal`, …). What the customer actually
chose at checkout is a `phoenix_kit_payment_options` row — an
operator-configured method with its own name, instructions, provider and
billing-profile requirement. The two are not the same thing: several
options can share one `payment_method` ("Bank transfer (EU)" and "Bank
transfer (UK)" are both `bank`), and an option can be renamed or
deactivated after the order is placed.

Without a link, the choice was simply lost at conversion: nothing on the
order said which option the customer picked, so an operator processing a
bank transfer could not tell which instructions the customer had been
shown, and payment reconciliation had to guess.

`ON DELETE SET NULL` rather than restrict: deactivating and deleting a
payment option is an ordinary operator action, and it must not be blocked
by — or destroy — historical orders. The order keeps `payment_method` and
its metadata snapshot regardless, so a deleted option degrades to "we know
it was a bank transfer" rather than to nothing.

# `down`

# `up`

---

*Consult [api-reference.md](api-reference.md) for complete listing*