Mollie kooperiert mit Klarna - für höchste Zahlungsflexibilität

Mollie kooperiert mit Klarna - für höchste Zahlungsflexibilität

Das Online-Shoppen ist mittlweile in unserem Leben verankert. Mehr Menschen als je zuvor kaufen Dinge, die sie benötigen im Internet. Dies bedeutet jedoch nicht, dass Möglichkeiten, die Geschäfte offline bieten, das Erlebnis nicht noch verbessern könnten. Für die meisten Kunden ist es nach wie vor ein wichtiger Teil ihres Entscheidungsprozesses, ein Produkt vor dem Kauf auszuprobieren. Warum sollten wir also nicht versuchen, das Beste aus beiden Welten zu kombinieren, und im Internet das ultimative Einkaufserlebnis zu erschaffen.

Mehr Transparenz, mehr Wachstum, mit einem Festpreis für Bancontact

Mehr Transparenz, mehr Wachstum, mit einem Festpreis für Bancontact

Der belgische Markt ist für Mollie sehr bedeutsam. Belgien war das erste Land, in dem wir unseren Service außerhalb der Niederlande erweitert haben, und hat deswegen einen besonderen Platz in unseren Herzen. Diese ersten Schritte in den belgischen Markt liegen nun schon wieder drei Jahre hinter uns und waren ein riesen Erfolg: die Anzahl der Bancontact-Transaktionen die von Mollie verarbeitet wurden, ist allein im vergangenen Jahr um 178% gewachsen.

Meilenstein! Mollie verwaltet jetzt Zahlungen für 50.000 Unternehmen!

Meilenstein! Mollie verwaltet jetzt Zahlungen für 50.000 Unternehmen!

Von unserem anspruchsvollen und schnell wachsenden Kundenstamm inspiriert, haben wir uns in den letzten Monaten verstärkt auf die Internationalisierung unserer Dienstleistungen konzentriert. Wir sind stolz auf die Entwicklung unseres Unternehmens, welches von einem kleinen Startup zu mittlerweile einem der größten und führenden Zahlungsdienstleister Europas gewachsen ist. Mit Stolz blicken wir auf dieses Wachstum, das uns heute ermöglicht, Zahlungsdienste für mehr als 50.000 Kunden anzubieten. Ein großartiger Erfolg, für den wir uns bei unseren treuen Kunden bedanken möchten.

Zwei neue Zahlungsmethoden: EPS und Giropay

Zwei neue Zahlungsmethoden:  EPS und Giropay

Wir freuen uns, mitteilen zu können, dass wir dem Portfolio von Mollie zwei weitere Zahlungsmethoden hinzugefügt haben: EPS und Giropay. Diese Zahlungsmethoden werden unseren Händlern beim Wachstum auf den deutschen und österreichischen Märkten unterstützen, denn Kunden in diesen Ländern können nun ihnen vertraute Zahlungsmethoden auswählen.

Mit EPS und Giropay erhalten Sie Zugang zu unserer ebenso simplen wie durchdachten API-Schnittstelle. Diese wurde speziell für eine einfache Integration und hohe Transfervolumen entwickelt.

Wachsen Sie auf dem österreichischen Markt

Electronic Payment Standard (EPS) ist eine von mehreren österreichischen Banken gemeinsam entwickelte Zahlungsmethode. Dies macht sie zur wichtigsten Zahlungsmethode in Österreich, die bei österreichischen Konsumenten hohe Beliebtheit genießt. Mit Mollie können Sie EPS problemlos integrieren und sofort die ersten Zahlungen verarbeiten. Sie zahlen nur für erfolgreiche Transaktionen. Keine versteckten Gebühren!

Bieten Sie Ihren deutschen Kunden die Zahlung per Giropay an

Giropay ist eine der beliebtesten Überweisungsmethoden Deutschlands. Da Giropay von über 1.500 führenden Banken unterstützt wird, schenken deutsche Kunden dieser Zahlungsmethode ihr Vertrauen. Die Implementierung von Giropay über Mollie ist leicht. Umständliche Registrierungen sind nicht erforderlich. Wir bieten Ihnen kostenlose Open Source-Pakete und Plug-Ins für die meisten Programmiersprachen und E-Commerce-Plattformen, damit Ihre Kunden ihre bevorzugten Zahlungsmethoden auswählen können.

Lokalisierte Zahlungsmöglichkeiten fördern das internationale Wachstum

In den letzten Monaten hat sich Mollie verstärkt darauf konzentriert, Händlern und ihren Kunden im Ausland vertraute und bequeme Zahlungsmöglichkeiten anzubieten. Dazu haben wir die Mehrwährungsfähigkeit eingeführt, die Kunden eine problemlose Zahlung mit internationalen Karten erlaubt. Mit dem Lokalisierten Checkout von Mollie ist es noch einfacher geworden, Ihr Internationales Wachstum zu fördern, denn nun können Kunden in ihrer Muttersprache einkaufen.

Verbesserungen der SEPA Zahlungen für Deutsche Verbraucher

Verbesserungen der SEPA Zahlungen für Deutsche Verbraucher

In den letzten Wochen haben wir die Zahlungsart SEPA für unsere Deutsche Kunden optimiert. Wir haben ein Deutsches Bankkonto und IBAN eröffnet, somit ist die Nutzung dieser Zahlungsart deutlich verbessert für unsere Deutsche Kunden und Nutzer. Anstelle einer Überweisung an ein ausländisches Bankkonto, in diesem Fall an die Niederlande, können Zahlungen jetzt direkt an eine Deutsche IBAN geschickt werden. Diese Änderung sorgt für ein größeres Vertrauen und eine schnellere Verarbeitung von Transaktionen.

Was ist notwendig um diese Deutsche IBAN zu nutzen? Das hängt davon ab ob Sie den Mollie Checkout oder die Mollie API nutzen um Zahlungsdetails wie die Bankkontonummer und Referenzen zu erzeugen. Beim Mollie Checkout ist keine Handlung von Ihrer Seite erforderlich, denn unsere Prozesse lokalisieren automatisch den Zahlungsablauf Ihrer Kunden und nutzen die Deutsche IBAN wenn nötig. Wenn Sie die Mollie API nutzen für Zahlungen von Deutschen Kunden, dann können Sie davon ausgehen, dass die Deutsche IBAN generiert wird mittels den Wert de_DE der an den locale Parameter gegeben wird.

In 2015 haben wir eine Belgische IBAN für Belgische Verbraucher hinzugefügt und konnten große Verbesserungen beobachten. Wir erwarten ein gleiches Ergebnis für Verbraucher in Deutschland.

English version

Migrating to a new datacenter (completed)

Update: we have completed the migration to our new data center. Follow our status page to stay updated.

This change will not affect the payment services.

Somewhere in the near future, there will be a change in our network structure.

This change will mean that the webhook requests you receive, will come from new IP addresses. If you use a firewall or security plugin on your website or server, and you have whitelisted our IP addresses,  you may experience some problems . We recommend to NOT whitelist our IP addresses. The way how our API works makes this unnecessary. Whitelisting adds complexity, but no additional security.

If you still wish to whitelist our IP addresses, please add these two IP addresses to the whitelist: 87.233.229.26 and 87.233.229.27. Do not remove the existing IP addresses!
In case this information is too technical, or when you do not have access to the whitelist, please send this e-mail to your technical advisor.

Join Mollie at the PHPBenelux Conference 2017

Join Mollie at the PHPBenelux Conference 2017

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! 

Schermafbeelding-2016-12-20-om-10.50.42 (1)

Several of the members of our Development Team will attend both days of the conference. If you’re going to be there and would like to meet our developers, please come talk to us! You will recognize us from our Mollie shirts.

Vacancies at Mollie

We’re always looking for new colleagues. If you’d like to know more or meet up, get in touch for a cup of coffee at our offices. Interested in how we work? Check out our development blog!

From the development department: Migrating to PSR-2 at Mollie

From the development department: Migrating to PSR-2 at Mollie

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.

Standards

In 2012 the PHP Framework Interop Group (FIG) accepted two coding standard recommendations: PSR-1 and PSR-2. The PSR-2 recommendation defines a “coding style guide”, and it extends the PSR-1 “basic coding standard”. The FIG is “a group of established PHP projects whose goal is to talk about commonalities between our projects and find ways we can work better together.” (quote from their website)

Many libraries and frameworks are already using the PSR-2 coding style guide, and new ones are adapting it as well. That means that a lot of developers are getting used to writing code using the PSR-2 style.

As a Mollie developer, if you are reading a lot of code written in the PSR-2 coding style, you also want to write code using it. New developers would also become more quickly acquainted with the Mollie codebase. So we decided to use PSR-2 for our complete code base instead of hanging on to our own proprietary coding style. But that meant that we had to convert all existing code to adhere to the recommendations of the PSR-2 spec. And of course we wanted to do that automatically.

Tooling

A couple of tools exist to format PHP source code. PHP_CodeSniffer has the PHP Code Beautifier and Fixer (phpcbf) that can format and fix some code styles changes. Another one is PHP-CS-Fixer by Fabien Potencier. This tool can use a format specification (like PSR-1/PSR-2), but you can also specify additional individual rules to be included or excluded during the formatting. After some tests we decided to use PHP-CS-Fixer on all of Mollie’s repositories, and use phpcbf to only fix the usage of tabs in places that PHP-CS-Fixer ignores.

The most important changes were the following:

After converting the code in a project all the unit and integration tests were run to check if nothing was broken. Next the changed files were committed using a different author than the person running the converter. We did this to distinguish the commit from other regular commits:

git commit --all --author="PSR-2 Mollie <codestyle@mollie.com>" -m "Convert to PSR-2"

Comparing code from previous commits (using for instance git blame) with the newly formatted PSR-2 code would of course show a lot of differences, even if you ignore whitespace. So we investigated if it was possible to convert all code from previous commits using the git filter-branch command.

With this command you can change each commit from the project history. So then you can format all code and commit it back into VCS. The downside is that each changed commit creates a new commit SHA-1 hash, which invalidates all cloned repositories. And each changed commit ideally needs to be checked with the tests. Reformatting thousands of commits would end up quite time consuming. These two arguments helped us decide not to change any code in repository's histories.

Results

The conversion created a bit of work for all team members with older local branches. They needed to merge the tooling, then run the reformatting on their branch and then finally merge the tip of the master into their branch.

But we are very happy with the end result. A standard and well-established code style between libraries and project code help developers understand code more quicker and reduce developers' cognitive load. New developers can get up-to-speed more quickly. More time is spent on discussing code design instead of the placement of braces.