August 2017

Added the image map to the issuers endpoint and includes in the Methods API. Just like methods, this map contains two keys normal and bigger which contain links to images that represent the issuer. Available for the iDEAL, KBC and gift card issuers.

July 2017

Added the createdDatetime property to the settlements resource. This field shows the moment that the open funds were transferred to a new settlement.

Added the settledDatetime property to the documentation. This field was previously undocumented, but already exposed through the API. This field shows the moment that the funds were settled (i.e. paid out by Mollie).

The Payments API now returns a dueDate parameter for SEPA Direct Debit payments. The dueDate is the estimated date the payment is debited from the consumers bank account.

Added the status property to the Settlements resource. The status indicates if the settlement is open, pending, paidout, or failed.

The refresh_token that is returned from the /oauth2/tokens endpoint when requesting an access token will not expire anymore. We previously generated a new access_token and refresh_token pair when a new access token was requested. We've changed this to only generate a new access_token - the refresh_token will stay the same indefinitely.

Application fees can now be created in test mode. This won't actually move any money, but you can now test integrating application fees in your platform.

Occasionally, we would not call the web hook for iDEAL payments if the payment status had already been retrieved via the API. This behavior has now been brought in line with the behavior of the other payment methods: we will now always call the web hook if there is a status update, whether or not the status has retrieved from the API.

May 2017

The Methods API resource can return issuers using ?include=issuers. At the moment this will include issuers for KBC and iDEAL.

April 2017

The Payments API now supports emoji (such as 🍔) in the payment description.

March 2017

The Methods API and Payments API now return a resource parameter to indicate the type of object, consistent with the other APIs.

February 2017

The profiles method of the Reseller API will now return a <token /> field to help you integrate the Reseller API with our OAuth APIs.

You can now retrieve an organization's open balance using the settlements/open resource.

Added a details.qrCode include for the Payments resource. You can add this parameter to the resource endpoint ?include=details.qrCode during creation, get or list operations and it will give you an object with a QR code embedded.

QR codes can be scanned by mobile applications to continue the payment on the mobile device.

At the moment, the QR code is only available for Bank transfer and Bitcoin payments but we will add support for more payment methods soon.

In the Netherlands, the bank transfer QR code can be scanned by the mobile banking apps from ING and bunq. Bitcoin QR codes can be scanned by bitcoin wallet clients.

January 2017

Added the signatureDate property to the Mandate resource.

Added the countryCode (ISO 3166-1 alpha-2) property to the Payments resource.

The Reseller API erroneously only returned verified profiles for the profiles method. Now all profiles, including profiles you just created are returned. Use the <verified /> element to test if a profile is verified.

Changed payment detail signatureDate of Direct debit payments to return the date without the time.

December 2016

The final state of Recurring Credit card payments will no longer be reported in the initial API call. Instead, we will report the final payment state via the webhookUrl, as per our documentation. This ensures any supplier outages will not delay or block our API response to your payment creation request.

Changed the minimum amount for PayPal to € 0.01.

November 2016

Added the settlementId property to the Payment resource. It is also possible to include the complete settlement resource by providing the include parameter, e.g. /v1/payments/tr_7UhSN1zuXS?include=settlement.

The name and email parameters have been made optional when creating a customer via the Customers API. It is now valid to create a customer via our API without providing any details about the customer.

When creating a payment without the method parameter, optional parameters are applied once the consumer selects the payment method. For example, you can send the dueDate parameter when creating a payment without a method. If the consumer then selects bank transfer, the due date is applied. If a different payment method is choosen, the due date is ignored.

Creating a first Recurring payment now returns the mandateId when available. When providing any of the following values for the method parameter, you will now directly receive a mandateId in the response: kbc, creditcard, mistercash, sofort and belfius. When using ideal as the payment method value, you will only receive a mandateId in the response when the issuer is also set.

Added new endpoint /v1/settlements/*/payments to retrieve all payments included in a settlement. Also added this URL to the Settlement resource as payments in the links property.

The Settlement resource include parameter ?include=settlement is now available on all endpoints that return payments.

October 2016

Added the startDate parameter to the Subscriptions API. You can now specify the start date when you create a subscription.

Added the recurringType parameter to the list methods endpoint. Using this parameter you're able to retrieve payment methods supporting first payments and recurring payments.

We have added a new payment method, the KBC/CBC Payment Button. As a result the method parameter now supports the value kbc, which will create a KBC/CBC payment.

When the method parameter is passed with the value kbc or when no method value is passed and KBC/CBC is chosen as the payment method, the description parameter value will be truncated to 13 characters. This will be increased in the future.

Added the issuer parameter for KBC/CBC payments. These work the same as for iDEAL, however they are not dynamically available through the API and the possible value are kbc and cbc. When the issuer parameter is set in the API request, the Mollie Checkout screen will be skipped and the customer will be sent to KBC or CBC directly.

September 2016

The locale parameters on our API endpoints accept non-standard values like en and nl (shorthands for en_US and nl_NL, respectively). We still support those non-standard values, but we're discouraging using those notations in our API documentation in favor of ISO-15897 locales.

You can now use locales such as de_AT and we will try to provide translated and localized payments.

If you send any codepages or modifiers these will be stripped.

August 2016

Added the locale parameter to the list methods and get method endpoints.