Today, we’re announcing the addition of a new payment method to Mollie’s products: gift cards. Starting today, all merchants who have an agreement with one or more of the supported gift card brands, can accept online gift card payments through Mollie.
Because of the Belgium National Holiday all banks will be closed on Friday July 21st. Settlements can be created and send, but they won’t be transferred to your bank account. The transfers will be done on Monday.
Over the past couple of weeks, we optimised the SEPA Bank Transfer payment method for German consumers. We integrated a German IBAN, which provides improvements for both our German customers and German consumers that use this payment method. Instead of being asked to transfer funds to a foreign, in this case Dutch, bank account, they can now transfer funds to a German IBAN, which will increase trust and transaction speeds.
Mollie has been the sponsor of the Dutch PHP Conference for two years now. We have since become active in the Belgian market as well and would like to bring ourselves to the attention of local developers. We regularly sponsor meet-ups, user groups and conferences. This allows us to do something for all those developers who have chosen Mollie or implemented our API.
We are therefore pleased to announce that we will be the sponsor of the PHPBenelux Conference 2017. The annual PHPBenelux Conference is a two-day event for PHP developers from Belgium, the Netherlands and Luxembourg. The event is held in the Antwerp Hotel Ter Elst, the 27th and 28th of January. Tickets are almost sold out, so be quick!
At Mollie we use PHP for our back-end code. Over the years the source code style that we used was primarily based on personal preferences of team members from days of yore. For example, tabs were used for indentation, and certain PHP constants like true, false and null were written in uppercase, and we had our own little rules about where the opening brace { should go.
It is required for every developer to use the Mollie PHP code style. This helps in understanding each other’s code (reduce cognitive load), and prevents reformatting code to match own personal preferences (and any debates about that!).
To aid in sharing a common code style, the code style settings of our IDE PHPStorm are added to VCS with each project. Additionally, we use PHP_CodeSniffer from Squiz Labs, a PHP tool to check PHP source code using a set of predefined rules. This tool can also be integrated into PHPStorm to give real-time feedback about the source code in your editor.
Unfortunately, learning our proprietary coding standard took a lot of time for new developers and wasted many hours in code reviews, hours that could have been spent discussing code design or delivering value to our customers. For this reason, we decided to switch to a more established coding standard.
Recently, BOOKEO, an online scheduling software and reservation system integrated Mollie as their preferred payment service provider for Europe. Customers of BOOKEO can now easily link their account with their merchant account at Mollie.
Usually such integrations of SaaS platforms with Mollie consist of an option to use Mollie for payments and a text field for pasting your API key. However, BOOKEO implemented the integration via our OAuth 2.0 API.
Integrating your platform with Mollie via OAuth 2.0 has a number of benefits over exchanging plain API keys:
As you can see, integrating Mollie as a platform via OAuth 2.0 offers significant advantages. Check out our getting started guide on Mollie Connect if you would like to know more.
To see how easy the integration with Mollie can be set up, you can check out the BOOKEO guide for connecting with Mollie.
American Express is one of the world’s most well-known brand names, with more than 55 million loyal cardholders across the globe. And we have good news, because as of today American Express is included in our range of payment methods!
This will enable you to focus on a larger international target group. American Express is of particular interest to those retailers focusing on the higher market segment: Amex users enjoy an above-average income and on average spend 60% percent more than holders of other credit cards.* And even though Amex is generally speaking relatively expensive for retailers, Mollie is offering this option at a uniquely competitive rate. So activate the credit card payment method in your Mollie account now and reap the benefits in the run-up to the festive season.
During interviews with developers we are often asked: what does an average working day look like for a developer at Mollie? To publicly answer that question, we’ve interviewed Thijs, who has been a developer at Mollie for about a year now.
Thijs, how did you start at Mollie?
During my studies at the University of Amsterdam, I had the option to take a two month internship for study credits. At my previous job, I had implemented Mollie as a payment service provider. Impressed with their API, documentation and work culture, I decided to apply for an internship.
During the internship I worked on adding support for gift cards to the Mollie API. I also did an internal research project on error rates and on how they impact Mollie. After my internship, Mollie extended me an offer for a position as a developer.
What did you learn during your internship?
For the most part, my study Computer Sciences focuses on topics like compiler design, sorting algorithms, data structures and a lot of math. All very interesting subjects, but a far cry from working on a live application that processes API requests each and every second of the day. At Mollie, I learned how to work as part of a team. I learned where to to apply object oriented design patterns, and where not to. I learned to test my code properly to validate my implementations. I learned to create and improve products that people use on a daily basis. Working on an actual product and growing the product is much more inspiring than the theoretical topics of my studies.
After my internship, I’ve worked on various things at Mollie – important updates like adding a fallback connection to a secondary iDEAL acquirer, and working on our open source API clients. I’ve worked on smaller changes as well, like allowing our customers to add descriptions to refunds, or improving the verification of VAT numbers.
Can you tell us a bit about the project you are currently working on?
At the moment, I am part of the Payments team. We’re in the process of adding a new payment method to improve our proposition for our Belgian customers. In recent weeks I’ve been working on making sure we charge the correct fees for the new product, as well as adding unit tests to ensure my changes work as intended. I am also working on the payment method’s reconciliation – the process where we match incoming transactions on our bank statements to the payments in our back office. We are getting more and more transactions on our bank accounts, so to ensure optimal performance, I’ve refactored our statement handler system to support input streams (using PHP’s yield functionality, among other things).
What are some activities that are part of your daily routine?
Usually I come in around half past nine. I’ll start coding on a smaller issue, or review a colleague’s code, until everyone’s in for our daily stand up. The remainder of the day I spend coding, reviewing, or brainstorming with the team on how we should tackle current issues.
Occasionally, we have team meetings like a sprint planning or a retrospective. Yesterday, I participated in a conference call with one of our suppliers. Around noon, we’ll have lunch at the office, which is prepared by our own chef. When it’s sunny outside, we like to spend some time on our office balcony as well.
What are some things you like working as a developer at Mollie?
Mollie has a team of developers who are all just as interested in software development as I am, which is very different from my previous job. There is lots of tooling available, such as pre-configured virtual machines for development, an extensive test suite, a continuous integration environment, and guides on how to set up debugging or profiling. We go to conferences as well. In June, the development department went to the Dutch PHP Conference, which was really informative.
Mollie is growing really quickly as well, and it’s cool to be a part of that.
We hope this gives you some insight in what working at Mollie as a developer entails. If you would like to know more, why not drop by for a cup of coffee?
locale parameter to the List methods and Get method endpoints.description parameter to the create payment refund endpoint. Use this parameter to add a description, which we will pass to the consumer when possible.first recurring payments. If you want to use this minimum for regular payments, please contact us to enable this on your account.address field to the organization resource.locale property.cardExpiryDate to credit card mandates.recurringType field to Payments API to support first and recurring payments.v1/customers/*/mandates that allows an application to find out whether a customer has valid accounts or cards that can be charged with recurring payments.Previous entry: API changes January—April 2016.
At Mollie, we recently switched to Composer to manage our applications’ dependencies. Composer is an application-level package manager for the PHP programming language that provides a standard format for managing dependencies of PHP software and required libraries. Using Composer is considered a best-practice in PHP application development.
Before our switch to Composer, we managed dependencies by creating local copies of their repositories and including them in our application using Git submodules. Disadvantages of this approach were that it took a lot of effort to add a new dependency and that it was very hard to update the dependencies. In practice, this resulted in our developers creating their own solutions instead of using high quality open source packages and us quickly getting behind on whatever package we did manage to add.
We decided to follow Composer best practices. The required dependencies are configured in the file composer.json, which is managed by the Composer binary. The actual versions of dependencies installed in the application are stored in the composer.lock file, which is for that reason under version control. This way, when someone runs composer install, the installed dependency’s versions are always predictable. The dependencies themselves are stored in vendor/ and are not under version control. This is the recommended way to use Composer.