phpjuice / paypal-checkout-sdk

PHP SDK for PayPal's Checkout REST API

Home Page:https://phpjuice.gitbook.io/paypal-checkout-sdk/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Feature: Add Laravel service provider

ankurk91 opened this issue · comments

It would be great to have Laravel support out of the box.
Here is an example of service provider

<?php

namespace App\Providers;

use Illuminate\Container\Container;
use Illuminate\Support\ServiceProvider;
use PayPal\Checkout\Http\PayPalClient;
use PayPal\Checkout\Environment\SandboxEnvironment;
use PayPal\Checkout\Environment\ProductionEnvironment;
use PayPal\Checkout\Environment\PayPalEnvironment;

class PayPalServiceProvider extends ServiceProvider
{
    public function register()
    {
        $this->app->bind(PayPalEnvironment::class, function (Container $app) {
            $clientId = config('paypal.client_id');
            $clientSecret = config('paypal.client_secret');

            if (config('paypal.sandbox')) {
                return new SandboxEnvironment($clientId, $clientSecret);
            }

            return new ProductionEnvironment($clientId, $clientSecret);
        });

        $this->app->singleton(PayPalClient::class, static function (Container $app) {
            return new PayPalClient($app->make(PayPalEnvironment::class));
        });
    }
}

The provider still need to publish the config file.

Here is the example of config file

<?php

// https://developer.paypal.com

return [
    'sandbox' => (bool) env('PAYPAL_SANDBOX', true),
    'client_id' => env('PAYPAL_CLIENT_ID'),
    'client_secret' => env('PAYPAL_CLIENT_SECRET'),
];

Now developers can type hint the PayPalClient class in their controller methods and Laravel container will resolve the correct class automatically.

@ankurk91 I was thinking to add a separate package for that what do you think?

Umm, agree, same as this one
https://github.com/kreait/laravel-firebase

I'm a little bit hesitated though on whether to have it as a standalone package or make it embedded in this package.

If I add it to this package, it will be easier but the downside is I'm planning to create another package laravel-payouts-sdk to cover the payouts section of the PayPal API. and it can't be added to this package so it has to be a standalone package.

If I create another package to handle laravel support, then I can support both packages paypal-checkout-sdk & paypal-payouts-sdk , but then I need to extract the http client to it's own package:

  • paypal-http-client
  • paypal-checkout-sdk
  • paypal-payouts-sdk
  • laravel-paypal

@ankurk91 what are your thoughts?

wouldn't be the best option to add the Laravel provider support to this package instead? https://github.com/phpjuice/paypal-http-client since it's gonna be the shared dependency between all other packages

So the laravel-paypal would require both sdk?

If yes, What if a developer has no plans to use paypal-payouts-sdk?

I would suggest to created a separate package to support laravel, you just to keep namespace separate for both sdk.

The laravel-paypal package will only have service provider, config file and a facade.

It will be a top level package which will require both sdk as dependency.

In future if you need to support symfony framework , you can create another top level package in the same way.

The word laravel in package name is more appealing to developers.

The paypal-http-client is the lowest package in tree, it is not the best place to have service provider for both sdk.

@ankurk91 hmm, but paypal-http-client is gonna be shared between paypal-checkouts-sdk & paypal-payouts-sdk so wouldn't be a good idea if laraval-paypal has as it's only dependency paypal-http-client ?

  • paypal-checkouts-sdk depends paypal-http-client
  • paypal-payouts-sdk depends paypal-http-client
  • laravel-paypal depends paypal-http-client

after all, all what the packages are adding is just the request classes and the value objects which has nothing to do with the laravel providers.

I would suggest to see how this maimatiner is doing for firebase sdk

https://github.com/kreait

yeah, that would be a good option, I'm gonna check it. thanks.