#Using RetryNow() in Laravel Mollie Cashier v2

1 messages · Page 1 of 1 (latest)

dire pelican
#

Hi,

My subscription cancels immediately when there is a chargeback, which is by design. Users can then press "retry" to retry the payment.
I am using retryNow() in Laravel Mollie Cashier v2 and it correctly generates a new payment for the requested, code as such:

    public function retryPayment(string $orderId): Redirector|RedirectResponse|Application
    {
        $order = Order::find($orderId);

        if (!$order) {
            $this->dispatch('banner_message', [
                'type' => 'error',
                'message' => __('Order not found.'),
            ]);

            return redirect()->route('orders.index');
        }

        $order->retryNow();

        $this->dispatch('banner_message', [
            'type' => 'success',
            'message' => __('Payment retry initiated.'),
        ]);

        return redirect()->route('orders.show', $orderId);
    }```

Upon succeeding this payment my subscription automatically gets put back on active, as preferred - but the new order_item that is created for its next payment has a process_at of now(). Seeing as Laravel Mollie Cashier v2 is optimistic this is now what happens:

Month starts, user gets payment (march)
User does chargeback the next day
User tries again in the same day and gets a new payment (march)
User succeeds and month starts
cashier command checks order_items
cashier charges user again

So now the user is charged twice in the same month and the next order_item is set for in two months (june). 

The next payment should not be now() but be the next month, correct? How can I fix this. 

I am using v2.12.1
image.png
#

Here is an example of the database. First it created the first two order_items, 202 was paid last month, 201 was paid this month but charged back. A new payment was then made to succeed 201 and a new order_item (204) was created for next payment. However 204 is the same date as 201, meaning that cashier:run straight up generates a payment for that one as well. Upon paying 204, 205 got created for two months in advance.

So the cycle works and the process_at AFTER the initial payment is correct, however the initial payment after a chargeback generates an order_item for the wrong month (seems to be now())

dire pelican
#

Oh I might have found it already, but may need a second opinion. Upon my tests I forgot to alter "ends_at" in subscription, which was set to this date and I found that in handlePaymentPaid it runs $item = $subscription->scheduleNewOrderItemAt($subscription->ends_at);

So it seems like it was just a local issue by spoofing a next payment. Upon changing "ends_at" to the next month, it correctly sets the new order_item.

Is it correct for me to assume that that function is actually called in this situation?

fervent anchor
#

cc @spiral spruce

spiral spruce
#

👍 Looks to me like it was an issue with the spoofing, as handlePaymentPaid indeed will get called