I ready that the NMI (www.nmi.com) gateway is supported by the self hosted Ninja Invoice system, but I am not seeing that option.
In addition, they have an Authorize.net emulation mode which we have used extensively and works well, but It is not working either (after changing URLs etc.).
I have tried both. When I use the XML Emulator (is that the correct one that we should use, you are using the newest Auth.net API?) I am getting a credit card expiry date error.
While this was supported by the older transact.dll API, the new API calls for it to be formatted as YYYY-MM. I’m guessing that when Authorize.net implemented their new API, they carried over support for all of the old formats but just made their documentation list YYYY-MM supported. NMI, on the other hand probably just implemented their API to support what the Authorize.net documentation lists, rather than what the API actually supports, which makes sense.
I changed my local code to use the YYYY-MM format, and the transaction went through successfully. The code I had to change is part of the Omnipay library, so fixing this would require getting the change approved into the Omnipay library and then getting Invoice Ninja to update to the latest version.
Hi, not sure if you read the whole thing. It was made to work by “hacking” the code. If/when the system is updated this “fix” would stop working. As per my last, there is an error in the Omnipay library that needs to be fixed. In Invoice Ninja able to advise Omnipay of same.
This information was tested and advised by Bold Compass, who you advised we should contact.
Hillel, thanks for the recommendation. I checked into this, and the reason the Authorize.net emulation isn’t working with NMI is that there’s a minor issue in the Omnipay Authorize.net library. On line 99 of AIMAuthorizeRequest.php the library is using the format MMYY to submit the expiration date, while the Authorize.net API documentation shows that it should be formatted as YYYY-MM.
It seems that the Authorize.net API has an undocumented “feature” that supports more formats than are documented, but the NMI API doesn’t. I’d consider this a bug in the Omnipay library, so I plan to submit a PR to omnipay-authorizenet to fix it. Do you know of any reason they’d be using the incorrect MMYY format, and once the Omnipay library is up to date, would you have any reason to not update to the latest version of the library?