I was recently asked to implement a subscription offering for a client on their web application.
I was initially apprehensive based on the naive assumption that taking payments had to be complicated.
Given that the client offers a single product at a single price and that the subscription is 'digitally delivered', I was essentially looking for a way of implementing a payment process that could be completed in a few clicks.
I am aware of products such as Square and Stripe, and I believe that they have APIs which one can utilise. Given the specification however I felt that these offerings would be overkill (disclosure - I did not actually investigate).
During my time at Uniregistry I had also had the experience of working with more traditional payment processors. Again, I did not want to implement a full checkout process. I was aware that their application processes were complex and that they had significant minimum transaction volumes, and (if my memory serves me correctly) the APIs offered were somewhat complex.
As such I went back to the original payment behemoth - Paypal, and began to investigate their API.
I thought that Paypal's API would be extremely complex and that they would have an arduous application process. Whilst their API might be complex, they provide an extremely well documented PHP SDK as well as detailed example source code.
Implementing the above mentioned specification took a matter of hours. It was simply a case of:
- Installing the SDK with composer.
- Creating an application within the developers console.
- Reading the sample source code.
- Implementing and adapting the 'PayPal Payments - similar to Express Checkout in Classic APIs' example.
- Testing the implementation in the Paypal sandbox.
- Changing a configuration parameter to 'live'.
The one (and only) complexity that I encountered was that when a prospective buyer was checking out, the payment screen would display 'Double Negative Solutions' in the header.
Whilst strictly correct, I wanted to display the clients product name to make it clear to the buyer that everything was in order, and that they were in the correct place.
After a little investigation I discerned that this could be achieved by creating a 'Web experience profile', as demonstrated here. You can also create the profile by executing a CURL request directly to the appropriate endpoint.
This little extension in my requirements allowed further investigation into their offerings..
My personal interactions with Paypal have sometimes been complex - recurring payments, multiple currencies, partial refunds etc. This is why I had assumed that integrating with their API would be tough.
In reality they have created a simple, modular, and well documented API which allows you to utilise as much or as little as you need. Were my client to want to implement more complex payment functionality it would be a step-wise process - implementing things as/when they are needed.
No huge time investment is required to learn and work with the Paypal API, and that makes it great for time constrained developers (all developers).
A brief investigation indicates that PayPal offer Java, PHP, Node, Python, Ruby, and .NET SDKs as well as mobile SDKs for both iOS and Android. Assuming that they are as well written (and documented) as the PHP SDK then implementing Paypal payments on any platform should be an absolute doddle.
Good job Paypal !