Question on about contributing

[paxperscientiam]

Hello @judgej ,

I'm interested in contributing to the authorize.net plugin for omnipay, but perhaps you could clarify some things for me first?

Do academe/omnipay-authorizenetapi and thephpleague/omnipay-authorizenet complement each other or should one be used over the other?

I'm unsure which I should be contributing to. Thanks.

[judgej]

Hi Chris,

The two packages complement each other at the moment, but that is likely to change. The league version supports the older services that are deprecated by Authorize.Net, but are still actively in use. This version uses the newer (relatively!) API that covers many features in one big unified API.

It would be great to move my package into the League, but I just have not had time to create enough tests for it, and there are standards to meet :-)

My package is split into two packages: the first to provide models for the API data structures (OMG just seen the download count - it really does need some love and care). That was all hand-built from the documentation, and is getting a bit old, but should still work even if not for the newer features. Ideally I would generate the code from an OpenAPI description, but Authorize.Net do not provide one of those. There is an XML DTD which could be used to gwenerate code, but that is a big job. The JSON API that Authorize.Net provide is just a wrapper over this XML API, so the XML does still describe the JSON data structures - the information is in there, and it explains why the JSON API really isn't REST, when it could have been designed that way. This part of the pair of packages is client agnostic - it just needs a PSR client.

The second part - this package - is the bridge between the models and Omnipay, and should be much simpler than the current League package, since it just handles getting data into and out of models.

So that's where we are now. Feel free to contribute to either packages - they are both in use for different APIs. If you can help get this one into the League, even better. If Authorize.Net release an OpenAPI description, then we are really cooking, because manually coding the models is a long laborious pain :-)

[judgej]

Well, there are some code generatino scripts here that we could use:

https://github.com/AuthorizeNet/sdk-php/tree/master/scripts

Specifically this one to create the models from the DTD:

https://github.com/AuthorizeNet/sdk-php/blob/master/scripts/generateObjectsFromXsd.sh

Here are the models that generates:

https://github.com/AuthorizeNet/sdk-php/tree/master/lib/net/authorize/api/contract/v1

There is a lot of duplicated code in there, that a few traits or inheritance could fix. If the models repo could be built entirely like this, then keeping up-to-date with changes and automating test generation becomes easy.

I'm usually reluctant to use a vendor's SDK directly as the core of an Omnipay package, because they often make assumptions and include dependencies that are not compatible with Omnipay, but I think we can adapt the scripts in the SDK to produce a "mini" SDK that is more PSR complient, has fewer dependencies and can be wrapped into an Omnipay package easily.

[paxperscientiam]

Thank you for the detailed response. I'll be able to think about it more clearly once cruch time is done at work.

[paxperscientiam]

Hey again @judgej , a small fix came up that I'd like to try. I want to add the <includeIssuerInfo> element to the <getCustomerPaymentProfileRequest> request. However, it's not clear to me how to get started. I have to somehow edit the XML. How do I access it? https://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/New-Support-for-Issuer-Identification-Number-for-Customer/ba-p/58758

thanks