Skip to content

Releases: academe/OmniPay-Payone

PR #45 + some cleanup

20 Oct 23:07
Compare
Choose a tag to compare
  • PR #45 merged.
  • Tests fixed for OmniPay test suite 4.1.
  • "pint" code formatting - includes using the array square bracket - [] - syntaxt (it's about time) so my break on some ancient versions of PHP.

Misc PRs

23 Aug 17:40
70552f7
Compare
Choose a tag to compare

PR#44 support phpmoney v4

23 Aug 16:59
0119b5b
Compare
Choose a tag to compare

PR#44 support phpmoney v4

Fix missing exception import

25 Jul 10:38
Compare
Choose a tag to compare

Support for Omnipay 3.0

15 May 11:41
Compare
Choose a tag to compare

Support for Omnipay 3.0

Some PHP 5.4 compat changes + test fixes

11 May 22:54
Compare
Choose a tag to compare

Fixed tests directory (was not running all tests).

Test coverage still needs expanding substantially, but that will probably happen more on the 3.x branch.

Some PHP 5.4 incompatible structures have been fixed, just for completeness.

Otherwise, no functional changes.

Update licence for packagist

14 Feb 10:12
Compare
Choose a tag to compare

The legacy LGPLv3 was not a valid SPDX licence.

No functional changes.

Increase minimum required version of omnipay-common to 2.4

14 Jun 14:24
Compare
Choose a tag to compare

This is due to the use of the notificationInterface for the back-channel transaction recording.

Raised in issue #27.

Additional parameters

13 Jun 13:23
Compare
Choose a tag to compare

A number of additional parameters to support various merchants.

  • PR #23 Add wallettype parameter (PR #24 is a duplicate of this, and so not merged)
  • PR #26 Add financingtype parameter
  • Issue #27 check supported creditCard methods for when running against omnipay/common <v2.4
  • Issue #25 Tracking for PR #26

Ideally, these all need to be validated against the clearingtype, as they are optional or mandatory depending on the clearingtype value. The gateway appears to ignore parameters that it does not need in the context though.

This is a pre-release for now, until it has been tried in production.

PR#22 Notification transaction result status logic changes

10 May 10:23
Compare
Choose a tag to compare

This change recognises that the notifications can go through a long sequence of events before the final "success" or "fail". This is caught by lookin at the event type and assigning many of them to the transaction STATUS_PENDING status.

This is a minor release because the logic behind $notification_request->getTransactionStatus() has changed slightly, so some code may need revisiting, depending on how the notifications are handled.