The Affirm API
Affirm's SDK takes care of the hard work presenting pre-designed UI elements to the user, helping them log into their Affirm account without ever leaving your site, and it even handles the payment gateway webhooks for you, so long as you formatted your order data correctly.
This SDK also takes care of some of the scarier legal baggage that comes with loans and deferred payment systems. It does this by making sure users always have access to detailed information about their borrowing power directly from your site. It even renders a handy UI element that describes how much a product would cost in terms of monthly payments.
At the end of the process, they even have someone review your work to make sure you did it correctly and met all of the integration criteria. Having the peace of mind that they won't let you get sued for missing a tiny detail was a pleasant addition to the experience.
Although the SDK is a fine solution for the frontend, it doesn't solve any of the backend concerns. How do you mark an order while Affirm is processing the payment? When they're done, how will you know? If a customer wants a return, do they do that through Affirm or through your site? How do you store and synchronize all of this data? This is where having a plugin designed just for the software your site uses is key, and it was this element that was somewhat out of our reach.
Reviving Old Software
There were no officially supported plugins that would work with our client's site, just a beta community plugin that hadn't seen the light of day for over 4 years. Even if we wanted to make a new plugin from scratch, we still wouldn't be able to count on any support or upstream updates in the foreseeable future.
Knowing nothing else, it looked like the best solution would have been to just make a new plugin from scratch. However, this would have required building and debugging a handful of webhooks to keep the two services in sync. For example, whenever Affirm approved a shopper to take out a loan for their purchase, they would need to send a package of data to Bison Disc's site saying that the payment had gone through.
Building and debugging webhooks of this nature can be a tricky and time consuming job, and it had the potential to eat up a lot of time if we weren't careful.
Long Term Maintenance
Assuming that we could even build a working package, we would still have to stay alert for upstream changes to Affirm's API. Most 3rd party software vendors are good about supporting their old APIs in perpetuity, but it isn't always a guarantee.
If anything, this consideration made it all the more important to have a wide degree of control and understanding over whatever form our plugin took. If we had the luxury of using an official plugin that worked out of the box, we wouldn't really know what to do if Affirm introduced a breaking change to their service.
Integration With The Existing Software
The payment gateways already in-use on the site each had a very predictable workflow. They would handle updating the order status whenever a customer completed checkout, they provided backend reports and logging, and they each offered a suite of settings and options that admins could use to customize its behavior for their specific needs.
Regardless of how we decided to implement an Affirm plugin, these features were critical to ensure a uniform experience and ease of management.
All of the challenges that stood before us posed an interesting question: if we weren't going to get any of the perks of officially supported software anyway, why not just fork off the dead community version and make our own in-house plugin that suited our needs? Even if it was out of date, maybe we could repair the package to the point where it worked.
There was only one potential trade off: all of this proposed repair work came at the cost of time and energy. In short, I had to be sure that this solution would work, or risk throwing away too much time on a pipe dream.
To make sure our fears weren't unfounded, I took some time to read up on how Bison Disc's existing payment gateways worked. Then I took what I learned and compared it to the outdated Affirm plugin. All in all, I discovered the Affirm plugin was a good candidate for refactoring. It handled most of the work that we needed, and the parts that it didn't do were easy enough to implement that we could get it built well within the proposed budget.
Part of what tipped me off that this old Affirm plugin might fit our needs was the fact that the creators had based it off of the PayPal payment gateway: a plugin our team was already familiar with and used regularly. Given the fact that our team already had a strong background in that family of software, there was a strong body of evidence that getting up-to-speed with Affirm would be quick and easy.
In the end, the plugin I created was a fork of the community version with a handful of customizations that integrated it seamlessly into our more modern stack. This work involved coding up a few system hooks that handled updating order statuses, creating a few settings panels, and updating some deprecated function calls. I also discovered one or two database queries that weren't quite as efficient as they could be for stores with lots of orders, so I took the time to optimize them as a best practice.
Once the vendor-required inspection got the green light, we were able to deploy the completed feature. Not long after, Bison Disc started receiving some of its first purchases using Affirm.