As you might already know, we have recently released a new API here at PayLane. The reason we’ve done that we wanted our API to be accessible in any way possible – no matter which programming language or platform you would use to integrate with us. How have we achieved that?
We started to be more RESTful :)
What is REST?
In plain English, REST is an API design standard and technology that standardizes how API should be made and how it should work. But what is more important – the basic principles of REST say that your interfaces should not be tied/connected to any specific technology or language. Also, you really should focus on keeping your API as simple as possible in terms of its usage – you are giving access to your application to your future customers – do not let them down! RESTful APIs take a good use of what’s already there – the HTTP protocol. If we want to be more specific, they use basic Internet protocols to communicate with the outside world – and that’s pretty much all you need to know about it.
read more
If you want to accept card payments with a mobile device, you’ll probably end up with Square or one of similar solutions (mPowa, iZettle etc.) – that’s what the search results will give you. But ask yourself, do you really need and want to set up a new account and attach a piece of hardware every time someone pays you?
Is this really the only solution?
Well, it depends.
There are alternatives, but whether you should use them or not – this mostly depends on your business type, its model and needs. It’s quite different if you want to accept payments in a single restaurant, a chain of restaurants, if you deliver goods to your customers or sell both online and offline.
read more
I have recently been working on one of our new projects, and I needed to have my own copy of our system with full functionality. The changes made by me would affect the whole system so my workmates couldn’t work on their features then.
Although every respectful development company uses version control systems, typically every change is made to main repository – then every developer can be up to date and they can work on the same project. But sometimes – as in my case – your changes are going too deep to work on the same repository. Here branching comes in. It is used globally in any version control system. It allows you to create branches that are (depends on system) independent copies of HEAD (or another branch) created from one particular commit in main repository.
read more
Most of us, freelancers, have a similar opinion hardcoded in our heads – work for yourself, gain experience and knowledge from any source in our own time. But I need to change your thinking. I’ve just started working for PayLane as a developer and just after three short weeks I totally changed my mind.
read more
