Checking for Already purchased product fails if the receiving wallet is different.

[yondifon]

Describe the bug Using $customer->paid($product)) fails when product was purchased with money transferred to another wallet.

To Reproduce Steps to reproduce the behavior: 1.

$cart = app(Cart::class)
    ->withItem($product, receiving: $receiving)
;

$user->payCart($cart);

$user->paid($product); // returns null 

Expected behavior The method is supposed to return true but it still return false. It fails when it should pass (as it should though, The underlying code needs to provide a $receiving wallet

Server:

• php version: 8.3
• database: mysql 8.0
• wallet version 10.1
• cache lock: redis
• cache wallets: redis

[rez1dent3]

Hello, @yondifon. The method has long been deprecated and this is written in phpdoc.

/**
 * Checks acquired product your wallet.
 *
 * @deprecated The method is slow and will be removed in the future
 * @see PurchaseServiceInterface
 */

The method was deprecated when the receiving purchases functionality was added.

Now you need to do this.

$transfers = app(PurchaseServiceInterface::class)->already($user, $cart->getBasketDto());

Confirmation of purchases is the amount of transfers equal to the number of items in the basket.

[rez1dent3]

In general, the current implementation is a crutch that I was strongly asked to add to the package. It does not normally take into account the return and check of the purchase of goods when transferring $receiving, since the architecture was originally different.

A separate table for orders has been requested for a long time. Most likely, this will not be earlier than v12.0. We need to come up with a new structure so as not to break the current code, which is used by many projects.

[yondifon]

alright. make sense.

thanks for the clarification. (need some extra hands any time, just let me know)

[mokhosh]

@rez1dent3 you say we should do this:

$transfers = app(PurchaseServiceInterface::class)->already($user, $cart->getBasketDto());

but in the original paid method this is what's being done, and it says it's slow and that's why it's deprecated, right?

Am I missing something here?

[rez1dent3]

@mokhosh Hello. The difference is that the current paid method does not accept the $receiving wallet under the contract:

https://github.com/bavix/laravel-wallet/blob/4fd4f9ba593f1604cd7e6608c0fdbf7c4ac38e0a/src/Traits/CartPay.php#L542-L544

This was my first thought, then I went to double-check the code and discovered that for it to work properly, a new table was needed, which needed to be developed and added within the 12.x version.

Now, unfortunately, when setting the wallet for item, some of the functionality will not work, yes, because there is not enough data.

If you have a separate table with purchased goods, then you can override PurchaseServiceInterface and implement your logic there. Or wait for laravel-wallet 12.0, which will have this functionality out of the box. The release will be after the release of laravel 12.

[mokhosh]

Makes sense. Thanks.