No 8.1 support in 2023 is actually insane.

[RickKukiela]

How in the world is the official SDK from the biggest/oldest online credit transaction gateways, for the most popular back-end programming language this out of touch with reality?

This is unacceptable and quite frankly an embarrassment at this point.

PHP7.4 is already EOL and 8.0 is not going to be far behind.

What in the actual F***?

[Mark-H]

I wouldn't personally have used the same strong language in an open source repository, but I very much share your sentiment as I'm just finding out I wont be able to use this SDK.

@kikmak42 @gnongsie Should this SDK be considered end-of-life as it hasn't been upgraded in a few years and there are many issues and open PRs detailing how it does not work on currently supported versions of PHP?

[RickKukiela]

For sure, you are 100% right. I am quite animated some times. This is actually me "toning it down" :) I guess it is quite unprofessional of me to word it this way but I'm not exactly as well spoken as Barack Obama either! I guess It's my way of matching the ridiculousness of the situation for dramatic effect.

To that end, there is a fork over at https://github.com/zhartaunik/authorizenet-sdk-php that I have been using for 8.1, but recently realized there is a bug in the Log class that fails if you do not set a cardCode value on "stored card" transactions where you would not normally store it, and do not have deprecated warnings suppressed in your environment.

I pushed a PR to fix that just today, but I'm not sure if they will merge it or not, so feel free to use my version @ttag 3.0.1 using a custom "vcs" repository in your composer.json file: https://github.com/BelniakMedia/authorizenet-sdk-php

[djdevin]

What in the actual f*** is right.

Though I am not surprised at a major payment company being out of touch with security.

[adrovz]

What in the actual f*** is right.

Though I am not surprised at a major payment company being out of touch with security.

Yeah, quite sad. We can't upgrade our PHP version due to this and are most likely going to switch to Stripe instead in few weeks if nothing changes with Authorize.NET.

[XIAOXIAOSIYU]

Is it possible that they have already provided an answer to this inquiry in a different forum?

[RickKukiela]

@XIAOXIAOSIYU Just look at this issue tracker. They haven't responded to this or many other issues. It's like this whole SDK is a dead project at this point.

[XIAOXIAOSIYU]

@RickKukiela I'm not entirely comfortable using an unofficial package. Could you please share what you did instead?

[jdpace2]

@RickKukiela @djdevin @adrovz I forked the repo and modified files to address the problems. I submitted a pull request, but if you need an immediate solution, download my fork by adding/merging the following into your composer file:

  "repositories": [
    {
      "type": "vcs",
      "url": "https://github.com/jdpace2/sdk-php"
    }
  ],
  "require": {
    "authorizenet/authorizenet": "dev-master"
  }

If you want to perform the fix yourself, search vendor/authorizenet for all files that had public function jsonSerialize() and add #[\ReturnTypeWillChange] above the method declaration:

    // Json Serialize Code
    #[\ReturnTypeWillChange]
    public function jsonSerialize(){
        ...

[RickKukiela]

@jdpace2 I already have a fork that fixed the issue as described in my last comment: https://github.com/AuthorizeNet/sdk-php/issues/440#issuecomment-1472463501 but I do appreciate the contribution. Ideally the people responsible for maintaining this project would pokes with stick ... "do something".

[jdpace2]

@RickKukiela Yeah, I noticed that after I made my changes. My hosting provider upgraded PHP to 8.1, and the issues with this SDK prevented my client from processing cards. In my scramble, I skimmed the coments. I agree that the owner ideally would make these changes, but it's nice to have a community to do it, too. Thank you for your contribution.

[WalrusSoup]

I last checked this in March to see if we could upgrade, it's now August with zero news.

I'm not sure what the companies priorities are right now but it blows my mind we still don't have a native json API in 2023 either. They still provide a handicapped JSON interface via a translation layer when the content type is application/json.

If we need to start a community run fork, they should just come out and say it.

[jdpace2]

I think the volume of forks indicates that the community is already established -- we should consolidate them. I suspect that AuthNet's code is generated from an API spec, so it may not be straightforward for them to incorporate changes and release.

[jdpace2]

@WalrusSoup I'd nominate the fork made by @RickKukiela as representative of the community's needs. I validated his changes and incorporated them into my project. What sort of validation do you need to use his fork over the official?

[gregorysandoval]

I'd like to make a couple of points that I know will be unpopular but ...

• PHP is on a 3 year release/support cycle. They set that. The fact that PHP 7.4 is "EOL" as of November 2022 is strictly their doing. The REALITY is that there are millions of PHP 7.x implementations out there, it's hardly ancient.
• The expectation that Authorize.Net would keep apace with this 3 year support cycle is a bit unrealistic when you consider that most of the financial systems that are the backend infrastructure of payment gateways, batch settlement and funding are DECADES old. Yes, IDEALLY, they would keep apace of this 3 year cycle but that is not REALITY. This is precisely why other players (Stripe, et al) have been able to move in to the space.
• I'd remind you that VISA bought Authorize.Net. Their priority - as dictated by the stock exchange - is to KEEP GROWING. They let go of most of the Auth.Net staff who were, indeed, quite proactive and were constantly working to keep API's, SDK's, etc. alive and updated. If you want to be mad at someone be mad at Visa and the tyrannical demand of quarterly P&L statements.
• Auth.Net recently did send a notification out to partners that they are aware of the situation and are working to update their offerings. Whether that's good or bad will remain to be seen. I'm just saying that all of the vitriol on here shows a lack of perspective with how the REAL WORLD works and what can reasonably be expected given the current situation.

I am supporting six integrations all on PHP 7.4 with the most recent (unforked) SDK and they all work flawlessly and with no security issues. YMMV.

[RickKukiela]

@gregorysandoval The reason I do not allow out dated versions of PHP on my servers is that I do not want, for example, some new 0-day PHP7.4 exploit that is discovered to allow attackers to break in into my server. Such an exploit will not be patched because 7.4 is no longer even receiving security updates. It's my opinion that running EOL server processes that could allow remote code execution if exploited with no avenues to patch such holes, should they occur, is irresponsible at best.

Given this, a "real world" example is that my servers do not run 7.4 anymore yet I have many sites that need authorize.net integration on them. Authorize.net is the author and maintainer of this SDK and it strongly behooves them to maintain the SDK to be compatible with the current (secure) versions of the programming language it is for. Failing to do this is failing their community and their customers as there is no doubt plenty of extra billable time that is being spent by their customers to have 3rd party fixes (like mine) vetted and implemented into their code base to ensure uninterrupted operation of their site; in the event that their web host deprecates EOL PHP versions that are no longer considered "secure".

Furthermore, there is no really valid argument here because the changes required to make the SDK compatible with 8.1+ were relatively minor and could have been implemented without a lot of fuss if they just would have put someone on the task. They could have even hired one of "us" to do it, I'm sure, if the are that pressed for developer resources...

[RickKukiela]

I suspect that AuthNet's code is generated from an API spec, so it may not be straightforward for them to incorporate changes and release.

This is exactly the reason they gave for not updating it. IMO if the bug is not in the spec, then the code that "generates" the SDK files has a bug and it should be fixed there... :shrug:

[gregorysandoval]

@RickKukiela All fine points, I don't dispute any of them. I'm just saying that - given the real world business climate - it's not a bit of an overstatement to say that lack of 8.1 support is "insane" or to lament the lack of response from Auth.net. The folks in the boardrooms at Visa are interested in maximizing shareholder value, period. They wouldn't know an API or SDK if it bit them in the you-know-what.

I think it's a far better use of one's time and energy to acknowledge the complexities involved here. It's not about the minimal engineering effort to fix the situation. It's about the fact that the people responsible for maintaining the SDK's were let go long ago. If being on the latest version of PHP is a dealbreaker for you (and some security experts would argue that is as problematic as being on 7.4), then that's a valid requirement. Write your own middle layer to communicate with the API endpoints and be done with the SDK if and until Visa decides to make that investment again. That's a far better use of one's time and energy. I completely agree with you, it's lamentable that this is the case, but that's the reality.

BTW, you know who's far worse? PayPal. If you've ever done any integrations with PayPal, you'd be shocked at the state of their SDK's and documentation. Thanks to years of acquisitions, shifting business priorities, etc. their stuff is a mess.

[IncredibleHat]

I came here to find an updated SDK because we need to upgrade our server to a new OS, and PHP8 is the bare minimum for that process.

The crazier part is, it was the PCI Compliance company thats demanding we upgrade our OS, PHP and SSL etc etc. A PCI Compliance company that is tied to our authnet gateway provider. Yet here authnet has an SDK which doesn't even run on the versions the PCI Compliance is demanding. Arg!

So, it looks like I'm going to have to drill through the hundred or so phpcs ERRORs in their code and fix all of this myself. While I think I could trust the work done by @RickKukiela .... I am wary. Or I can just write my own handler like I did with the original authnet some 15 years ago. Guh. This is also why we are switching to NMI and Braintree.

On the note about PayPal... yes, their whole sdk keeps changing around, but so far running phpcs on it, there are no errors or warnings generated for 8.1 checks. Haha. Its still a mess though, and bloated.

[RickKukiela]

@IncredibleHat you could certainly download both releases and diff them if you're concerned.

[IncredibleHat]

@IncredibleHat you could certainly download both releases and diff them if you're concerned.

That actually sounds like an excellent idea. I'm just so angry right now by the lack of support from authnet!

[proseLA]

few things:

• i could not find @RickKukiela's fork. maybe i'm just slow
• i used @jdpace2's fork which looks to be rick's fork incorporated into his own.
• from what i remember, authorize was very slow to update this repo on the move to php7.x
• there will be new issues if running php 8.2, mostly around around creation of dynamic properties. here is one such error log:

--> PHP Deprecated: Creation of dynamic property net\authorize\util\Log::$sensitiveStringRegexes is deprecated in /var/www/zcdev/includes/modules/payment/authorizenet/authorizenet-sdk/lib/net/authorize/util/Log.php on line 366.

• unfortunately, i find none of this surprising considering that authorize deprecated all of their Name Value Pair APIs many many moons ago; and yet i believe they still process transactions submitted that way.

best.

[RickKukiela]

Sorry, my fork was actually done via my org account: https://github.com/BelniakMedia/authorizenet-sdk-php

[proseLA]

Sorry, my fork was actually done via my org account: https://github.com/BelniakMedia/authorizenet-sdk-php

and here i thought i was just slow...

[iteracymat]

Thanks so much @jdpace2 for your suggestion, we followed these instructions and now, finally, we've been able to move the site to PHP 8.1. 🙏If only Authorize.net support were as helpful as you!

If you want to perform the fix yourself, search vendor/authorizenet for all files that had public function jsonSerialize() and add #[\ReturnTypeWillChange] above the method declaration:

    // Json Serialize Code
    #[\ReturnTypeWillChange]
    public function jsonSerialize()
        ...

[IncredibleHat]

I was unaware of this whole ReturnTypeWillChange bit, and why PHPCompatibility checker wasn't really throwing any warnings or errors about all the functions that this should be added too. After doing some reading up on it, I now see what the whole issue is about. Also by adding ReturnTypeWillChange, its just suppressing the problem ... where when php9 comes around, this authnet SDK will surely die for good.

Looking at this SDK, and the simplicity of the core authnet API ... this SDK is an awful lot of code for just making a basic json payload and sending through curl.

Hopefully the warning suppression fix will last for however long we stick with authnet before the other gateways are in place and migrated too.

[IncredibleHat]

Well, we tried to use the modified one with all the additions to the jsonSerialize entries. We just get actual fatal errors now instead of warnings. Errors like:

Uncaught TypeError: Return value of net\authorize\api\contract\v1\ANetApiRequestType::jsonSerialize() must be an instance of net\authorize\api\contract\v1\mixed, array returned in /.../lib/net/authorize/api/contract/v1/ANetApiRequestType.php:127

So, this looks to be a nightmare in the brewing. We are moving away from authorize.net entirely now, but we need something cobbled working until we are off them 100%.

[jdpace2]

What version of PHP are you using?

On Tue, Sep 19, 2023 at 12:46 PM IncredibleHat @.***> wrote:

Well, we tried to use the modified one with all the additions to the jsonSerialize entries. We just get actual fatal errors now instead of warnings. Errors like:

Uncaught TypeError: Return value of net\authorize\api\contract\v1\ANetApiRequestType::jsonSerialize() must be an instance of net\authorize\api\contract\v1\mixed, array returned in /.../lib/net/authorize/api/contract/v1/ANetApiRequestType.php:127

So, this looks to be a nightmare in the brewing. We are moving away from authorize.net entirely now, but we need something cobbled working until we are off them 100%.

— Reply to this email directly, view it on GitHub https://github.com/AuthorizeNet/sdk-php/issues/440#issuecomment-1726214462, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACW6TT3V2A3TE6MZNKGWD23X3HK6ZANCNFSM6AAAAAAV5PTT3I . You are receiving this because you were mentioned.Message ID: @.***>

[IncredibleHat]

@jdpace2 currently staging fixes in php 7.4 so things are ready when we do the php8 upgrade this week. Not sure why the authnet-sdk fixes would be any issue in 7.4, but they are. Im not sure if those same issues will exist in php8.... so, gonna play it by ear and hot-seat fix whatever breaks. Authorize.net are providing no support in the matter.

[jdpace2]

@IncredibleHat I'm interested to know how it goes. I've found the transition from PHP 7.2 to 8 easier than 7.2 to 7.4 (in general).

[cdbessig]

I made composer patches that can be used instead of an alternative third party repo:

patches.zip

So my method was to do composer patching.

composer require cweagans/composer-patches In my case I had an issue with some legacy packages and actually had to do:

composer require cweagans/composer-patches:* Then download the patch zip file, extract it, and put the patches folder in the root of your project.

Then make sure your composer.json includes the below.

    "config": {
        "allow-plugins": {
            "cweagans/composer-patches": true
        }
    },
    "extra": {
        "patches": {
            "authorizenet/authorizenet": [
                "patches/authorizenet-authorizenet-lib-net-authorize-api-contract-v1-updatesplittendergrouprequest-php.patch",
                "patches/authorizenet-authorizenet-lib-net-authorize-util-log-php.patch"
            ]
        }
    }

Now when you install authroize.net you will see the below telling you the patches are being ran. That’s it, now you have a portable composer patch off the official repo. This feels safer to me and if the official repo ever gets 8.2 support, I can just pull my patches out.

$ composer install
...
Gathering patches for dependencies. This might take a minute.
  - Installing authorizenet/authorizenet (2.0.2): Extracting archive
  - Applying patches for authorizenet/authorizenet
    patches/authorizenet-authorizenet-lib-net-authorize-api-contract-v1-updatesplittendergrouprequest-php.patch (0)

Our clients use case is very simple, so I cannot guarantee this will solve all the php 8.2 problems in the library as we didn’t have budget to explore this any further. Hopefully it works for you.

Full write up here on my blog.