Bump version to 0.17.2

2026-09-15 21:25:25 +03:00
parent e4e008167a
commit 4489475840
2 changed files with 36 additions and 1 deletions
@@ -4,6 +4,41 @@ All notable changes to this project will be documented in this file.

 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).

+## [0.17.2] - 2026-09-15
+
+### Fixed
+- `Modules\Core\Order\Listeners\ApplyResolvedPaymentStatus` never advanced `Order::status` past
+  `awaiting_payment` on a capture — only `paid`/`paid_at` were written, so a fully captured order
+  could sit indefinitely at "awaiting payment" until a staff member manually clicked "Update
+  Status". Now, on `PaymentCaptured` (not `PaymentAuthorized` — an authorization isn't yet
+  captured funds), `status` advances to the next step in the order's flow
+  (`Modules\Core\Order\Services\OrderStatusFlow::nextOptions()`) — but only when it's still
+  exactly `awaiting_payment`, so a duplicate/delayed capture event never regresses an order staff
+  already moved further.
+- The backoffice "Capture" action on the order page (Filament) called vendor Lunar's
+  `Lunar\Models\Transaction::capture()` directly, which resolves `Lunar\Facades\Payments` — an
+  entirely separate, unused driver registry — and never dispatched `Modules\Core\Payment\Events\
+  PaymentCaptured`. This meant a manual capture from the admin panel never ran this app's own
+  payment pipeline at all (including the status-advance fix above). `Modules\Core\Order\Filament\
+  Extensions\OrderActionsExtension` (renamed from `OrderRefundActionsExtension`, since it now
+  fixes both the refund and capture header actions — see below) now routes capture through
+  `Modules\Core\Payment\Support\TransactionDriverAdapter::capture()`, the same app-level path
+  checkout-time captures use.
+- `Modules\Core\Payment\Drivers\StripePaymentDriver` never extracted a card's brand/last four
+  digits from Stripe's response, so `Lunar\Models\Transaction::card_type`/`last_four` were always
+  empty and the admin's "Payment of :amount on card ending :last_four" activity-log line rendered
+  with no digits — reproduced on both checkout-time and manual captures. Added
+  `cardMetaFromIntent()`, reading `payment_method_details` off the PaymentIntent's `latest_charge`
+  (same source `lunarphp/stripe`'s own `StoreCharges` uses), populated into `PaymentResult::$meta`
+  from `resultFromIntent()` and `capture()`. `Modules\Core\Order\Services\TransactionRecorder`
+  now maps `meta['card_type']`/`meta['last_four']` onto the `Transaction` row. Only applies to
+  transactions recorded after this change — existing rows are not backfilled.
+
+### Changed
+- `Modules\Core\Order\Filament\Extensions\OrderRefundActionsExtension` renamed to
+  `OrderActionsExtension` — the class now fixes both the refund and capture header actions on the
+  order page, not just refund, so the old name undersold its scope.
+
 ## [0.17.1] - 2026-09-15

 ### Fixed