As I am known to do, I take on small plugin projects from time to time. Having small programming code work to keep my mind churning has always helped to distract me from other things that could drag me under.
This time around, I had just finished one Joomla payment plugin for Virtuemart, for the Nigerian payment gateway, Paga, so writing another should have been easier. I was wrong. I was still yet to test the Paga plugin live, as the client was unresponsive, but I felt I could also rush this one in three weeks and be done.
I repeat, I was wrong.
This plugin is for the Nigerian payment gateway, Paystack, a cool new payment solution that everyone in the Tech community is proud to be associated with. Its also heartwarming that the founders are old friends of mine, but don’t let me digress.
Joomla’s plugin system, called extensions, has a very different naming convention compared to WordPress. In Joomla, there are Components (think big complex plugins), modules (think plugins that can be displayed in different positions at the front end), templates (think themes), and plugins (usually do invisible work at the back end). Components can have modules and plugins working with them. There are also extensions exclusively for the front end, and for the back end.
I was to build a Paystack payment plugin for the OS Membership Pro component. Keep in mind that there is no documentation (I had to rely on the skeletal documentation for one of their other plugins which my client claimed he was told was similar). After three months of battling the code, I had something ready for testing, but could not get access to the file server of the client, so I could work on the files directly. No responses from him so I gave up.
Fast forward three more months, and someone at Paystack buzzed me for help. He noticed I was a Joomla! fan, and had developed payment plugins for other components in the past. He needed help with developing one for the OS Membership Pro component, and was wondering if I was game. When he realized I already had something going, he encouraged me to finish, and offer me help
So here are the notes and lessons I learnt the hard way while battling with it. I know I am bound to build another payment plugin for this component, so I figure, having something I can refer to, tomorrow, to make my work easier, online, would be awesome.
- Recurring or not: if the plugin you are developing does not support recurring payments, then don’t test it with plans that have recurring subscription activated. I wasted valuable time testing because I did not do this – sounds easy but when you are not that familiar with the component, it’s not.
- Naming: the name of the plugin in the xml document must be the same as the name of the php file. That’s the only way it will show up in the front end as an option to be selected for payment.
- Blueprint: The PayPal plugin caters to both recurring and single payment modes, so use it as your blueprint for your plugin.
- Redirect or Credit Card: If you want to redirect to the payment gateway, use this skeleton they recently put up on their GitHub page . If you want to build a plugin that uses credit card, use this one. I worked on the Redirect option.
- Classes and functions: The main class extends MPFPayment. There are four functions -> __construct, processPayment, verifyPayment, and validate. Because of the different nature of the payment form, I also created my own renderRedirectForm function.
I will keep adding to this list.