search

academe / Omnipay-Wirecard

Wirecard payment gateway driver for the Omnipay
GNU Lesser General Public License v3.0
1 stars 0 forks source link

Gateway default values - how to handle? #4

Closed judgej closed 7 years ago

judgej commented 7 years ago

When a gateway class defines default values for its parameters, then all requests created by that gateway class must support all the parameters that are defaulted. The tests insist on this, and it makes sense that this happens so that each default parameter can be explicitly set when not provided by the merchant site.

Now the problem comes when some default parameters are handy to have (the demo application and other applications use this information in their management screens), but are not relevant to all of the messages,

For example, the Checkout Page gateway has authorize and purchase requests that take a big bunch of parameters such as payment page colours, notification email, window names etc. The complete and the acceptNotification requests do NOT* need those parameters, but if those requests are to remain under the same Checkout Page gateway AND are given default parameters in that gateway, then they MUST support those parameters.

One solution - not used on gateways such as PAYONE - is to split the requests up into different gateway classes with different sets of defaults. So CheckoutPageGateway may handle the authorize request, but to capture that authorisation you must use the CheckoutPageBackendGateway (for example). This is fine for specific use in an application, but harder to manage in a framework that handles lots of Omnipay drivers in a generic way.

The other option is to simply not have those default values that are not supported by ALL requests handled by a gateway class.

Neither approach is ideal. So what do we do?

aimeos commented 7 years ago

Please use default values only where required and where they make sense. Different gateway classes would be hell for framework projects like Aimeos.

judgej commented 7 years ago

I suspected that would be the case.

It is a lesson to keep the default values to the essential minimum, though it does mean application management UIs such as the Omnipay Example application can't show the features off fully, since the admin pages are driven by the default values. Something to feed into Omnipay 3.0 perhaps.

judgej commented 7 years ago

Closing. We have the practical way forward for Omnipay 2.x