It’s been nine months since we first published our SDKs on GitHub, and we couldn’t be more delighted with the level of developer interaction and community involvement. From the very first formatting pull request to the latest feedback on our new controller model, we truly feel like we’re building the API and SDK with our developers as well as for our developers. Happy Holidays to everyone who has forked us on GitHub!
Version 1.8.3 Enhancements
The new 1.8.3 release of the Authorize.Net SDKs includes support for the most recent core API changes, fixes a number of community issues and incorporates continuous integration to enable our projects to constantly build and pass unit tests. It also introduces a new design paradigm across our .Net, Ruby, Java and PHP SDKs to allow us to be as responsive as possible to core API changes.
Core API Changes
Specifically, we have added SDK support for:
- Apple Pay – allows your merchants to use their Authorize.Net account to securely accept and process in-app payments from customers with the new iPhone 6 and 6 Plus, iPad Air 2 and iPad mini 3.
- PayPal – allows your merchants to accept PayPal using their Authorize.Net Payment Gateway account.
- Consolidated Accounts – allows merchants to process Card Not Present (CNP) and Card Present (CP) transactions with a single payment gateway account.
Community Issues and Pull Requests
In this release, we merged pull requests on all of the SDKs and fixed a majority of open issues. If your issue did not get included, bear with us as we continue to make regular releases. As a reminder, a pull request always helps us understand the issue better, even if it’s just adding a failing test.
Continuous Integration
All projects on GitHub now include Travis-CI. Internally, we believe passionately in continuous deployment, and it was a high priority for us to enable it in our GitHub repos. More build and analysis tools will be added in the coming months as well.
New SDK Design
One of our commitments when launching the SDKs on GitHub was to release simultaneously with core API changes. We also needed a more efficient way of incorporating API changes, where the majority of them (for example request/response additions) would require nothing more than a rebuild. And we wanted new methods to be a few lines of code and tests.
Over the past couple of months, we have been working on a new model whereby we generate the request and response classes from our XSD and then have simple controllers which implement that request for our API methods. We have not deprecated any of our existing SDK code, far from it – the new model lives side-by-side for now, so we encourage you to try it out and send us your feedback. We’ll soon post more details on the new model, but for now, the READMEs on GitHub include information on how to get started.
We look forward to hearing from you on GitHub or here in the community.
Happy Holidays!
Brian and the Developer Experience team
