[Discussion] Design of gateway-specific interfaces

[jalallinux]

Hello @AmirrezaNasiri ✌🏻

Describe the bug
Two method are not existing for zarinpal driver, and only work on idpay.

To Reproduce
Steps to reproduce the behavior:

1. Set default gateway to zarinpal in config/toman.php
2. Create Toman request:

 Toman::amount(10000)
            ->orderId('123')
            ->mobile('a valid mobile number')
            ->email('a valid email')
            ->callback('a valid site route')
            ->description('description of this payment')
            ->name('JalalLinuX')
            ->request();

3. See exception:

Method Evryn\\LaravelToman\\PendingRequest::orderId does not exist.

4. Now comment ->orderId('123')

 Toman::amount(10000)
            // ->orderId('123')
            ->mobile('a valid mobile number')
            ->email('a valid email')
            ->callback('a valid site route')
            ->description('description of this payment')
            ->name('JalalLinuX')
            ->request();

5. See exception:

Method Evryn\\LaravelToman\\PendingRequest::name does not exist.

Expected behavior
This package a multi pay driver package and it should have the same usage. but orderId, name method only work for idpay driver.

Screenshots

Exact Versions:

• Laravel: 8.54
• PHP: 7.4
• Package: 2.0.1

[AmirrezaNasiri]

Hi @jalallinux :)

Thank you for submitting this issue. The topic at hand is indeed worthy of discussion. While developing the package API, I grappled with how best to structure it.

I opted to adhere to driver-specific requirements for both requests and callbacks, while also generalizing certain shared components. This approach allows developers to clearly discern the unique requirements and expectations of each driver. For example, it can help prevent issues like assuming the presence of $request->orderId() in callback requests when switching from IDPay to Zarinpal, especially since Zarinpal doesn't have the orderId definition. Furthermore, developers can employ the strategy design pattern to make gateways easily interchangeable. I lean towards supporting this architecture.

Conversely, when we consider ease of use, Laravel Socialite serves as a pertinent reference. This package standardizes callbacks (similar to ours) but leaves the associated logic to developers. However, its providers are not entirely interchangeable due to differences in attributes. We face a comparable challenge on the request side. Still, this architecture seems to have its merits.

In conclusion, I'm ambivalent. Whichever route we choose, developers will need to implement their logic for interchangeability. Let's keep this issue open; it's a fascinating subject.