VVV launched a new giftcard VVV Cadeaukaart which supersedes VVV Giftcard. We changed the name in the Checkout and API and have updated the branding.
Added Spanish as a
locale for the Mollie Checkout. Use
es_ES to get Spanish translations and localization in your checkout.
Bank transfer payments can now be cancelled via the API or Mollie Dashboard as long as they are still open.
Added more details to giftcard payments in case multiple gift cards are used or if the remaining amount was paid using another payment method.
Updated the payment screens for payments created in test mode. All screens are now available in English, Dutch, French and German. No changes in the API are needed to use these new screens.
Belfius Pay Buttons now expire the next business day at 09.00 AM, instead of after an hour.
We've updated all payment methods to allow the absolute minimums that the method allows. For most payment methods, you can now create payments with amounts as low as €0.01. In our help center you can find the exact list of minimum and maximum amounts.
Only payment methods that are enabled in the Dashboard will appear in the API and the Mollie Checkout, if the test mode is used. Before, all payment method would be visible in test mode.
This brings the behavior of test mode in line with that of live mode.
The refund status
failed was missing from our API docs. This could happen, if the customer cancels his / her bank account between the payment and the refund.
We have extended the expiry time for Bancontact from 17 minutes to 60 minutes.
We have added a dedicated French bank account for the
banktransfer payment method. Your customers can use this bank account if you specify the French locale
Setting the correct locale is very important for having high conversion and error free bank transfer payments. At the moment, we have dedicated bank accounts for bank transfers in Belgium, France, Germany and the Netherlands.
You will no longer receive an error from our API if you have insufficient balance in your account to create a refund. Instead, we will queue the refund and perform it automatically once enough balance comes in. The payment will transition to
refunded once the refund becomes
pending, at which point we will call the payment's webhook.
We have introducted a new
queued status for refunds in our API so you can see if the refund was queued or is pending.
Added new endpoint
/v1/settlements/*/refunds to retrieve all refunds included in a settlement, and added this URL to the Settlement resource as
refunds in the
We've launched the
giftcard payment method today. Check out the Gift card integration guide to get started.
image map to the issuers endpoint and includes in the Methods API. Just like methods, this map contains two keys
bigger which contain links to images that represent the issuer. Available for the iDEAL, KBC and gift card issuers.
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.
status property to the Settlements resource. The status indicates if the settlement is
refresh_token that is returned from the
/oauth2/tokens endpoint when requesting an access token will not expire anymore. We previously generated a new
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.
The Methods API resource can return
?include=issuers. At the moment this will include issuers for KBC and iDEAL.
The Payments API now supports emoji (such as 🍔) in the payment description.
The Methods API and Payments API now return a
resource parameter to indicate the type of object, consistent with the other APIs.
profiles method of the Reseller API will now return a
<token /> field to help you integrate the Reseller API with our OAuth APIs.
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.
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.
You can now retrieve an organization's open balance using the settlements/open resource.
Changed payment detail
signatureDate of Direct debit payments to return the date without the time.
signatureDate property to the Mandate 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.
countryCode (ISO 3166-1 alpha-2) property to the Payments resource.
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 €
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
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.
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:
belfius. When using
ideal as the payment method value, you will only receive a
mandateId in the response when the
issuer is also set.
The Settlement resource
?include=settlement is now available on all endpoints that return payments.
settlementId property to the Payment resource. It is also possible to include the complete settlement resource by providing the
include parameter, e.g.
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.
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.
recurringType parameter to the list methods endpoint. Using this parameter you're able to retrieve payment methods supporting
first payments and
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
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.
startDate parameter to the Subscriptions API. You can now specify the start date when you create a subscription.
locale parameters on our API endpoints accept non-standard values like
nl (shorthands for
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.