---
name: mollie-upgrade
description: >
  Activate this skill when a developer wants to upgrade their Mollie SDK to a newer
  version, or migrate an existing integration from a deprecated Mollie API to its
  replacement — most commonly migrating from the Orders API to the Payments API.
  This includes: updating @mollie/api-client, mollie-api-php, mollie-api-python, or
  mollie-api-typescript to a newer major version, resolving breaking changes after an
  upgrade, and moving off the Orders API (orderNumber, order lines, Shipments API,
  order cancellation) onto the Payments API (captures, release-authorization,
  unified refunds).
---

# Mollie Upgrade

This is a distinct workflow from `mollie-payments` — that skill builds new
integrations; this one changes existing, working code. Confirm current behavior
with tests before changing anything, and re-verify after.

## Step 1 — Identify the type of upgrade

> Are you updating your Mollie SDK to a newer version, or moving off the Orders API
> to the Payments API?

These require different playbooks — ask before proceeding.

---

## Step 2A — SDK version upgrade

1. **Detect the current version.**
   ```bash
   # Node.js
   npm list @mollie/api-client
   # TypeScript
   npm list mollie-api-typescript
   # PHP
   composer show mollie/mollie-api-php
   # Python
   pip show mollie-api-python
   ```
2. **Find the latest supported version and read its changelog** before touching
   code — do not upgrade blind. Check for a major version bump specifically; minor/
   patch upgrades rarely have breaking changes, major ones usually do.
3. **Identify breaking changes** relevant to this codebase — grep the existing
   integration for methods/fields the changelog flags as renamed or removed, rather
   than assuming nothing broke.
4. **Apply the version bump and required code changes** together, not separately —
   an upgraded dependency with unmigrated call sites will fail at runtime, not at
   install time, for a dynamically-typed language.
5. **Run the existing test suite.** If there isn't one covering the Mollie
   integration, say so explicitly before declaring the upgrade done — this skill
   should not report success on the basis of "the code compiles."
6. **Verify webhooks and payment flows manually in test mode** — create a test
   payment, complete it, confirm the webhook still fires and fulfilment still
   triggers, before recommending a live-mode deploy.

---

## Step 2B — Migrating from Orders API to Payments API

Mollie no longer recommends the Orders API. Payments API is simpler and gets new
features the Orders API doesn't. This is not a drop-in rename — several concepts
don't map 1:1.

### Field and endpoint changes

| Orders API | Payments API | Note |
|---|---|---|
| `orderNumber` | `description` | No dedicated order-number field |
| `lines[].name` | `lines[].description` | |
| Negative amounts on `physical`/`digital`/`shipping_fee`/`surcharge` lines | Not supported | Redesign any discount-via-negative-line logic |
| `consumerDateOfBirth` | Removed | No replacement field |
| `expiresAt` controlling authorization expiry | Removed | Authorization expiry is no longer configurable this way |

### Authorize-then-capture behavior changed

Orders auto-produced an `authorized` status for Klarna/Billie/Riverty. Payments
capture immediately by default — **you must explicitly set `captureMode: 'manual'`**
to keep a hold-then-capture flow. Without this, funds are taken immediately where
the old integration expected a hold. See `<mollie-payments:references/operations/captures.md>`
for the Payments-API capture flow.

### Fulfilment: Shipments API → Captures API

- The Shipments API doesn't exist for standalone Payments — use the Captures API
  instead.
- Captures only work on `authorized`-state payments, are amount-based (not
  line-based), and are asynchronous (status via webhook, not immediate).
- **You cannot use the Captures API on a payment that is still part of an Order** —
  fully migrate that transaction's flow, not just the capture call.

### Cancellation changed

Orders allowed cancelling individual lines or the whole order to release funds.
Payments only support releasing the **full** remaining authorized amount via the
release-authorization endpoint — there is no partial release. If the existing logic
does partial-line cancellation, it has no direct equivalent; flag this to the
developer rather than silently approximating it.

### Refunds consolidated

Orders had two refund paths (via order lines, or via the underlying payment).
Payments API has one — `<mollie-payments:references/operations/refunds.md>` — which
also works against legacy orders' underlying payments.

### Migration steps, in order

1. **Pre-migration gate: check for orders still in `authorized` status.** Those
   can't use the Captures API directly — resolve them under the old flow first.
   Do this before any of the steps below land in production, otherwise those
   orders end up with the old shipment path gone and the new Captures path unable
   to operate on them yet.
2. Replace *create order* calls with *create payment*, adjusting the field
   differences above.
3. Add `captureMode: 'manual'` anywhere a hold-then-capture flow is required.
4. Replace Shipments-API fulfilment logic with Captures-API calls — but only once a
   given transaction is fully off the Orders flow.
5. Replace order/line cancellation with the release-authorization endpoint; flag any
   partial-cancellation logic that has no direct equivalent.
6. Consolidate refund logic onto the single payment-refund endpoint.
7. **Migrate stored references from Order IDs to Payment IDs.** Use `embed=payments`
   on existing List/Get Order calls to find the underlying payment ID and confirm its
   status matches the order's status before cutting over stored references. Run this
   as a pre-deploy backfill, or ship it atomically with steps 2–6 in the same
   release — not after. Steps 2–6 already make the codebase expect Payment IDs; any
   lookup that runs between that deploy and a separately-completed backfill will fail
   against a database that still holds Order IDs.
8. **Webhook caveat**: payments created without a `webhookUrl` under the old Orders
   flow will reference the Order ID in webhook payloads, not a Payment ID — account
   for this if webhook handlers are being updated in the same pass.

---

## Step 3 — Produce a migration summary

Regardless of which path was taken, end with a short summary covering: what version/
API was migrated from and to, which breaking changes were found and how each was
resolved, what was verified (tests run, manual test-mode checks performed), and
anything flagged as needing a design decision rather than a mechanical fix (e.g.
partial-cancellation logic with no equivalent). Don't mark the migration complete if
verification was skipped — say so explicitly instead.