[3.0] Roadmap

[jvalecillos]

Apart from the following tickets/discussions #327 #362 #368 I would like to know what is holding 3.0 back for a release. How could I contribute to it?.

[barryvdh]

I was hoping for PSR-17 (Http messages factories) and I'm playing with the Container indeed. But besides that, I don't think there are any blockers.

[jvalecillos]

This one was accepted already https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-7-http-message.md

[barryvdh]

17, not 7; https://github.com/php-fig/fig-standards/blob/master/proposed/http-factory/http-factory.md

[jvalecillos]

I know, but there is no reason why not implement RequestFactoryInterface, ResponseFactoryInterface, ServerRequestFactoryInterface and UriFactoryInterface. Even if the proposal is never accepted it would be a good idea for omnipay use cases.

[barryvdh]

Yes but we need to require the psr interfaces. And we can't tagged until it's accepted, otherwise they could change.

[yellow1912]

https://groups.google.com/forum/?fromgroups#!searchin/php-fig/17%7Csort:relevance/php-fig/NTlrJKZZWao/Q7gxum01AQAJ

With 17 being stalled from being Accepted due to Internal Politics at FIG, I wonder when 3.0 will see the light :(

[psrpinto]

I think it would be useful to keep the v3 milestone updated. There are several issues/PRs for v3 which are not tagged with that milestone.

[barryvdh]

I've put some more work in the PSR-7 factories and HTTP client stuff, what do you think? https://github.com/thephpleague/omnipay-common/pull/125

[StudioMaX]

Any updates?

[GuidoHendriks]

Guess this is no longer happening? Is this project end of life?

[barryvdh]

Sorry, need to make some time, but a few gateways have already been upgraded, like Mollie.

[judgej]

@barryvdh Do you have a link for the 3.x Mollie driver? So far as I can see, Mollie still runs from Omnipay 2.x, even though the driver has had a 3.x version number for three years. I'm wondering how best to handle the workflow to take a driver to Omnipay 3.x, so a good example would be useful.

[barryvdh]

The current dev-master is for omnipay 3, you can use 4.x@dev to get it.

[judgej]

Is this the one you are looking at: https://github.com/thephpleague/omnipay-mollie

[barryvdh]

Yes

[erictompkins]

Is it possible to get an update on omnipay 3? We are starting to integrate it into our CMS but concerned that version 3 has been in progress for quite a while.

Is it also possible to get a list of new features that version 3 brings? Does it include support for bank payments? Thank you!

[barryvdh]

It will be released soonish with no new features, only compatible with Symfony 3/4 and psr7 clients.

[erictompkins]

Thank you @barryvdh . Do you know if there are any plans to support bank payments (#245)? Or is this something that we will need to handle outside of omnipay?

[barryvdh]

I think that should be required outside Omnipay. Bit not sure what it actually entails to do it in Omnipay.

[judgej]

For many gateways, the bank details would be entered off-site, so should not have any real impact on what Omnipay offers above what it does now.

[barryvdh]

But is that different than the existing off-site gateways?

[erictompkins]

@judgej What do you mean by "off-site"?

By bank details I referring to something like Authorize.net's echeck service or Braintree's ACH Direct Debit, which allows you to process a payment against a bank account instead of a credit card.

[judgej]

The very first payment gateways took credit card details on your site then your site back end posted the details to the gateway. The CreditCard class is built around that approach.

PCI rules recognised that was a bad idea, so many gateways now send the user to the gateway instead, either directly or in an iframe. Some tokenise cards on your site using javascript instead.

What these all have in common is that payment card/bank details do not pass through your site under any circumstances. Because they don't pass through your site, the Omnipay backend does not need to know about those details.

[judgej]

@erictompkins here is an example that I've just finished:

https://github.com/academe/Omnipay-GiroCheckout

That one gateway does credit cards, saved card references, bank direct debits, PayPal, Giropay (a kind of direct bank transfer service), Paydirekt, or a mix of all at the same time for the customer to choose from. It supports Omnipay 2.x and 3.x (as it currently stands) and has not needed any kind of additional special functionality or extensions to do that. It's still waiting for production trials in a few weeks, but I'm hoping it will be usable as "just another Omnipay driver" with no special treatment.

I think where Omnipay has not laid down any standards, and is a lot less supported, is in features such as profiles, stored customers (just look at Authorize.Net as an example), more complex baskets. Those are kind of up to the driver developers to create if they have a need to, and each gateway is so different and specific, that it's difficult to see how these features can be standardised.

[ejunker]

Any updates on 3.0? Based on #483 it doesn't appear that Omnipay is compatible with Symfony 4 or Laravel 5.6. Or perhaps a 2.x version could be released that uses php-http/guzzle6-adapter so that people can use that until 3.0 is released?