-
-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mollie Api v2 #48
Comments
The biggest breaking change looks like the 'amount' is now passed as a map ... |
Yeah and different return codes |
This may be a good example of where an external library can be pulled in to help. The official Mollie package models all the resources that the REST API supports, and they can be used to construct the request message, and possibly to parse the responses. I've done this for the new Authorize.Net driver - it gets all the XML, JSON, some validation etc, out of the driver, results in more re-usable code, less duplication and a less complex Omnipay driver. On the other hand, there are now two packages to maintain, but I think it is worth it. |
Hi, Willem from Mollie here. I agree with @judgej that the fastest way to move is to use our PHP API client as a dependency. Let me know, how we can help! |
I'm open for a v5 implementation for the v2 api, using the Mollie package. Perhaps Willem would like to make a PR? |
Ah yeah, great, we can also directly implement this proposal/suggestion I added yesterday. |
It does have Guzzle as a dependency, which could add complications for some use-cases. Omnipay Common 2.x uses an earlier version of Guzzle, and Omnipay Common 3.x does not have any preference for a HTTP client, and there are many alternatives that could be used. This is - I think - the reason why Omnipay purposefully stayed clear of any third-party dependencies in the past. Providing models for the API is great and saves time, but then they all tended to pull in their own explicit locked-in transport layer, and that got in the way of Omnipay's (and now the merchant site's) preferences. However, @willemstuursma the gateway could make a general HTTP client a generic requirement, so the end user could choose, and then pull in Guzzle specifically for dev clones. But I may just be overstating a non-problem anyway :-) |
@judgej that's fine, can you provide a PR on I need to discuss planning internally and will report back here. |
Yeah that is the downside of using those libraries. Not so bad for just 1 gateway, but relying on multiple clients could give some problems. As the current implementation seems solid, how big would the change be to just use the REST api? |
As discussed with Mollie, we are open for a change to the Mollie SDK, as long as it doesn't create extra dependencies. For now it's just Guzzle which could be replaced with something HttpClient agnostic, but I do fear that that might be a BC break for Mollie API SDK. |
Good morning all! Martijn from Mollie here. I've been looking at a way to abstract the http implementation and stumbled upon: This uses a virtual package and some discovery and PSR packages to be HttpClient agnostic. |
Hello Martijn, That is indeed what we also use for Omnipay, see https://github.com/thephpleague/omnipay-common/blob/master/src/Common/Http/Client.php You do have to realise that you cannot drop the Guzzle requirement from your existing SDK without a major version release. And if you still require both HttpPlug + the Guzzle adapter, the dependency is still existing.. What we do with Omnipay is to have an So not sure what is best for Mollie SDK, creating a separate 'core' package or release a new major version which is not tied to any HTTP client. (for reference, my initial hope was to use PSR-18, but that isn't released yet after years of progress; https://github.com/php-fig/fig-standards/blob/master/proposed/http-client/http-client.md ) |
Hi @barryvdh, We are choosing to do the necessary changes and release this under a Minor. You can find our updated composer.json here: Is this acceptable on your end for updating this package with the SDK? |
Goodmorning! We've created PR #49 for updating to v2. We decided to not introduce the SDK as dependency. |
Okay nice, I've merged the PR. The branch-alias is updated to 5.0 so you should be able to required |
Hi @barryvdh, Thanks! We've already been able to do so by adding our fork as repository to test stuff out. |
Okay let me know if you tested the actual version from this repository, then I can tag 5.0.0 |
I was not able to require on |
Mollie now has a v2 API: https://docs.mollie.com/migrating-v1-to-v2
I haven't check extensively, but it looks like it might have some breaking changes. The current v4 of this library could remain on the V1 API, while 5.x could use the v2 API.
The text was updated successfully, but these errors were encountered: