Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
0a6958eb9e | ||
|
|
d189a7559a |
@@ -4,6 +4,21 @@ 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.26.4] - 2026-09-28
|
||||
|
||||
### Fixed
|
||||
- Bank transfer orders were never marked placed. `BankTransferPaymentDriver::pay()` had
|
||||
dead code after an early `return` and never dispatched `PaymentDeferred`, so nothing
|
||||
ever set `Order::placed_at` or fired `OrderPlaced` — no order confirmation email, no
|
||||
stock decrement, the order missing from the customer's order history, and checkout
|
||||
erroring out instead of showing the confirmation page. `pay()` now dispatches
|
||||
`PaymentDeferred` the same way `CashOnDeliveryPaymentDriver::pay()` does.
|
||||
- `MarkOrderPlacedOnDeferredPayment` now skips
|
||||
`OrderPaymentResolutionService::resolveDeferredPayment()` for a bank transfer order
|
||||
(`OrderStatusFlow::isBankTransfer()`), so it correctly stays at `awaiting_payment` /
|
||||
unpaid until staff mark it paid, instead of being advanced past that status the moment
|
||||
checkout completes.
|
||||
|
||||
## [0.26.3] - 2026-09-28
|
||||
|
||||
### Added
|
||||
|
||||
+1
-1
@@ -2,7 +2,7 @@
|
||||
"name": "boboko/core",
|
||||
"description": "Core module — authentication and shared panel behaviour",
|
||||
"type": "library",
|
||||
"version": "0.26.3",
|
||||
"version": "0.26.4",
|
||||
"autoload": {
|
||||
"psr-4": {
|
||||
"Modules\\Core\\": "src/"
|
||||
|
||||
+1
-1
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "@boboko/core",
|
||||
"version": "0.26.3",
|
||||
"version": "0.26.4",
|
||||
"private": true,
|
||||
"type": "module",
|
||||
"description": "Portable Stimulus controllers and styles for boboko-core's cart + checkout module. Installed as a real npm dependency (file:../boboko-core in dev, a tagged git install in prod) so a consuming app's `npm install` resolves this package's own dependencies (leaflet, @hotwired/stimulus) transitively, the same way `composer update boboko/*` does for PHP. See CONTRIBUTE.md's \"JS/CSS: a real npm package\" section.",
|
||||
|
||||
@@ -6,6 +6,7 @@ use Illuminate\Support\Facades\Event;
|
||||
use Lunar\Models\Order;
|
||||
use Modules\Core\Checkout\Events\OrderPlaced;
|
||||
use Modules\Core\Order\Services\OrderPaymentResolutionService;
|
||||
use Modules\Core\Order\Services\OrderStatusFlow;
|
||||
use Modules\Core\Payment\Events\PaymentDeferred;
|
||||
|
||||
/**
|
||||
@@ -36,11 +37,18 @@ use Modules\Core\Payment\Events\PaymentDeferred;
|
||||
* visibility and stock decrement, but nothing ever moved `status` off its
|
||||
* initial value, since resolveCaptureOrAuthorization() only does that for
|
||||
* an actual capture. Caught and fixed after the fact.
|
||||
*
|
||||
* The status advance is skipped for a bank transfer order
|
||||
* (OrderStatusFlow::isBankTransfer()) — unlike COD, it genuinely has
|
||||
* something to await at 'awaiting_payment': the wire itself. Only
|
||||
* OrderFulfillmentService::markPaid() ever advances it past that point
|
||||
* (see BankTransferPaymentDriver's own docblock).
|
||||
*/
|
||||
class MarkOrderPlacedOnDeferredPayment
|
||||
{
|
||||
public function __construct(
|
||||
private readonly OrderPaymentResolutionService $resolution,
|
||||
private readonly OrderStatusFlow $flow,
|
||||
) {}
|
||||
|
||||
public function handle(PaymentDeferred $event): void
|
||||
@@ -53,7 +61,9 @@ class MarkOrderPlacedOnDeferredPayment
|
||||
|
||||
$order = Order::findOrFail($orderId);
|
||||
|
||||
$this->resolution->resolveDeferredPayment($order, self::class);
|
||||
if (! $this->flow->isBankTransfer($order)) {
|
||||
$this->resolution->resolveDeferredPayment($order, self::class);
|
||||
}
|
||||
|
||||
if (! blank($order->placed_at)) {
|
||||
return;
|
||||
|
||||
@@ -9,6 +9,7 @@ use Modules\Core\Payment\Contracts\SupportsPay;
|
||||
use Modules\Core\Payment\Contracts\SupportsRefunds;
|
||||
use Modules\Core\Payment\DTOs\PaymentResult;
|
||||
use Modules\Core\Payment\Enums\PaymentResultStatus;
|
||||
use Modules\Core\Payment\Events\PaymentDeferred;
|
||||
use Modules\Core\Payment\Events\PaymentRefunded;
|
||||
|
||||
/**
|
||||
@@ -27,20 +28,24 @@ use Modules\Core\Payment\Events\PaymentRefunded;
|
||||
* payment requires the money to arrive BEFORE the order can be
|
||||
* considered paid (unlike cash-on-delivery, where payment happens on
|
||||
* delivery — see CashOnDeliveryPaymentDriver's own docblock for that
|
||||
* driver's mirror-image reasoning). So pay() returns Pending, dispatching
|
||||
* no event at all — no PaymentCaptured (nothing has been paid yet), and
|
||||
* deliberately NOT PaymentDeferred either (unlike COD, whose
|
||||
* MarkOrderPlacedOnDeferredPayment listener immediately advances the
|
||||
* order past 'awaiting_payment' since a COD order has nothing to await at
|
||||
* checkout). A bank transfer order genuinely DOES have something to
|
||||
* await: it stays at 'awaiting_payment' with Order::paid false until
|
||||
* staff confirm the wire arrived via OrderFulfillmentService::markPaid(),
|
||||
* which — unlike its COD path — also advances the order's status, since
|
||||
* nothing else ever will (see that method's own docblock).
|
||||
* CheckoutController::placeOrder() already treats a Pending result with
|
||||
* no continuation as a fully placed order (see its own docblock), so the
|
||||
* order is still created and visible to the shopper immediately; only its
|
||||
* payment/status is what's left outstanding.
|
||||
* driver's mirror-image reasoning). So pay() returns Pending and DOES
|
||||
* dispatch PaymentDeferred, same as COD — without it, nothing ever sets
|
||||
* Order::placed_at or fires OrderPlaced, leaving the order invisible in
|
||||
* customer order history, un-decremented in stock, and the checkout
|
||||
* confirmation page unable to find it (see PaymentDeferred's and
|
||||
* CashOnDeliveryPaymentDriver's own docblocks for that failure mode).
|
||||
* Unlike COD, though, a bank transfer order genuinely DOES have something
|
||||
* to await: MarkOrderPlacedOnDeferredPayment skips
|
||||
* OrderPaymentResolutionService::resolveDeferredPayment() for a bank
|
||||
* transfer order (via OrderStatusFlow::isBankTransfer()), so it stays at
|
||||
* 'awaiting_payment' with Order::paid false until staff confirm the wire
|
||||
* arrived via OrderFulfillmentService::markPaid(), which — unlike its COD
|
||||
* path — also advances the order's status, since nothing else ever will
|
||||
* (see that method's own docblock). CheckoutController::placeOrder()
|
||||
* already treats a Pending result with no continuation as a fully placed
|
||||
* order (see its own docblock), so the order is still created and visible
|
||||
* to the shopper immediately; only its payment/status is what's left
|
||||
* outstanding.
|
||||
*
|
||||
* $reference is generated here for the same reason as OfflinePaymentDriver's
|
||||
* pay(): there is no gateway to hand one back. refund()'s 'notes' (in
|
||||
@@ -63,11 +68,15 @@ class BankTransferPaymentDriver implements Configurable, SupportsPay, SupportsRe
|
||||
|
||||
public function pay(string $type, Price $amount, array $data = [], array $context = []): PaymentResult
|
||||
{
|
||||
return new PaymentResult(
|
||||
$result = new PaymentResult(
|
||||
status: PaymentResultStatus::Pending,
|
||||
reference: 'bank-transfer-'.Str::uuid(),
|
||||
amount: $amount,
|
||||
);
|
||||
|
||||
PaymentDeferred::dispatch($type, $result, $context);
|
||||
|
||||
return $result;
|
||||
}
|
||||
|
||||
public function refund(string $reference, Price $amount, array $context = []): PaymentResult
|
||||
|
||||
Reference in New Issue
Block a user