omnipay
omnipay copied to clipboard
How to improve driver quality?
There are a lot of drivers for Omnipay available but most of them don't work out of the box because they don't comply fully to the Omnipay standards. This seems to be the biggest problem of Omnipay.
Some examples of what is done in the drivers:
- Different URL keys (instead of returnUrl, cancelUrl) are used
- Objects are expected to be set with setParameter() and returned with getParameter()
- "orderId" is used instead of "transactionId"
I know there's an omnipay-tests suite but either it's not used or it doesn't check for these kind of things. I would like to discuss now how we can improve the situation and what kind of other problems we should check for.
Can you tell me which driver's your running into these problems with?
The Wirecard gateway requires an object to be set: https://github.com/igaponov/omnipay-wirecard#installation
The Mobilpay gateway (non-official) uses "orderId": https://github.com/BusinessMastery/omnipay-mobilpay#basic-usage
I also know some libraries that have problems with transactionReference and transactionId, but also because not all gateways work the same way.
It would be nice to be able to verify if a gateway works like all the others, or something is different.
Hi,
I've been thinking about this recently - the transactionReference / transactionId issue is an important example - there are some others. I feel like a best practices guide (with perhaps a list of extensions that do & don't break them) would be a good thing - I was thinking of starting one & trying to PR it in - any thoughts about where such a thing might sit.
I was imagining perhaps an explanation of expected methods such as set/getTransactionReference & perhaps a table of which ones are known to comply at the end.
I have concluded that I will fork & 'fix' gateways that I want to use who don't comply - but there are compatability issues to actually fix the main version. Perhaps if we clarify & confirm the problem then we might do a point version update late in the year which does fix non standard ones.
It's a bit strange that Mobilpay (the gateway) even uses the term orderId
for a payment transaction. There is no guaranteed one-to-one relationship between an "order" on the merchant site and a "payment" towards that order. Unless it actually means something different to our understanding of a transactionId
? But I don't think that's the case - found this in some docs:
orderId (Mandatory) - payment transaction identifier generated by merchant; helps merchant to interpret a request to confirm or return url; it should be unique for the specified signature
Anyway, that's a diversion. The library needs an issue raised and a PR with five lines of code, then it's sorted.