Include non-official gateways

[judgej]

The OmniPay Common package contains the list of "official" gateways in its composer.json. This application will load up just the gateways listed in that file (through Omnipay::find()). There are many more gateways out there, which it would be great to be able to list and use in the example application.

A list of additional gateways to load (if available) would be great. A list of additional gateways that are known about but may not be loaded yet (they have not been installed via composer) would be great also. The ability to add your own gateway to the list that you may be developing, or is not on any official lists anywhere, also would be good.

[delatbabel]

I will refer to my other comments -- I don't think that this is a good idea.

[judgej]

At the moment you can install any non-official gateway, but the example application will not see it. That is what I would like to see solved here. Because of the way composer works, the application needs to start with a list of gateways that it can scan for - just the short names are all that is needed (or the namespace in OmniPay 3.0). So that list needs to be somewhere the example application can access at run time. composer.json is almost certainly not the place to keep that information.

For example, while developing the PAYONE driver I set the root route up like this in index.php

// root route
$app->get('/', function() use ($app) {
    $supported_gateways = array_merge(
        Omnipay::find(),
        ['Payone_ShopServer', 'Payone_ShopClient', 'Payone_ShopFrontend']
    );
    sort($supported_gateways);

    $gateways = array_map(function($name) {
        return Omnipay::create($name);
    }, $supported_gateways);

    return $app['twig']->render('index.twig', array(
        'gateways' => $gateways,
    ));
});

If that list (['Payone_ShopServer', 'Payone_ShopClient', 'Payone_ShopFrontend']) could be pulled in from some other source - a file or even a file of known gateways + .env for adding development gateways, then that would be ideal I think.

It's about helping people evaluate, try out and develop gateways with the minimum of hurdles to jump over.

[delatbabel]

What I tend to do is define an array somewhere in my application config that looks something like this:

omnipay: {
    PayPal_Rest: {
        secretKey: asdfasdf12341234,
        testMode: false
    },
    Pin: {
        apiKey: blablabla,
        testMode: false
    }
}

That way I can call Omnipay::create on $key and pass in $value as the parameters to initialize().

I can stick this array in a config file, or shove it in a database where a super-admin can edit it.

Everyone has their own solutions and I don't think that mandating one will achieve very much. YMMV.

[judgej]

If there is already a way of doing it, I'll give it a go and get some documentation in.

[delatbabel]

There is already a way of doing it -- not necessarily a recommended way of doing it. Everyone has their own implementation of $config these days it seems. I even recall having stand-up shouting arguments with devs about whether to use php files or .ini files to initialise $config -- these days I go for JSON blobs stored in the database if I can.

[judgej]

Just coming back to this in connection with thephpleague/omnipay-common#137

That PR removes the list of all gateways from omnpay/common and removes the OmniPay::find() method for locating them all and checking which are installed. Going down that route for OmniPay 3.0, I guess we need the config approach here, and I would suggest a config file preset with all the gateway drivers we know about, and a config file that can be customised, allowing the gateway drivers we don't know about to be added.

I'll have a play and see what I come up with. The key, to me, is an example application that lets people get up and running and try out OmniPay quickly and easily, but also offer flexibility for those wirting their own drivers or experimenting further.