Migrating from v1 to v2
The v1 API has been shut down on December 31st, 2024 and is no longer available to use. If you have technical question regarding switching API versions, feel free to join our Developer Community on Discord.
Why upgrade to v2
The Mollie API v2 offers some compelling new features compared to the older v1 API:
- Fully supports multicurrency. You can create payments, subscriptions, and refunds in non-EUR currencies. Your account will still be settled in EUR, so new fields have been added in the API to reflect the settlement amount for various resources.
- Possible to update details of payments via the new Update payment.
- Improved support for accessing large sets of objects, now uses cursor-based pagination instead of pagination based on counts and offsets.
- Settlement details are now available for refunds and chargebacks as well.
- New features such as Mollie Components, Place a hold for a payment, and wallets such as Apple Pay are only available in the Mollie API v2.
- Improved error messages. Error message will contain more details to help you quickly resolve any implementation problems.
How to upgrade to the v2
To migrate to v2 API, follow these basic steps:
- Understand the changes
- Refer to this section, to understand the changes, deprecated features, and new functionalities.
- Update your code
- Identify affected areas: Locate the parts of your code that interact with the old API.
- Modify requests: Update the API endpoint URLs to the new version.
- Change parameters: Adjust the request parameters to match the new API specifications.
- Handle responses: Update your code to correctly process the new API responses, which might have different formats or additional fields.
- Test the v2 API
- Execute your existing tests to see if they still pass. Write new tests if necessary to cover the changes in the new API.
- Look out for any errors or unexpected behaviour in your application.
- Update your internal documentation to reflect the new API usage.
- Monitor
- After updating, keep an eye on the performance of your application.
There are no changes to the authentication. API keys, Organization and OAuth tokens work both on V1 and V2.
Changes in v2
In general, the API has adopted the HAL specification, allowing you to discover new resources and follow links to new resources while working with the API.
Several fields have changed too to support new features or to clear up confusing aspects of the v1 API.
The identifier for the payment method Bancontact has been renamed from mistercash to bancontact in the v2 API.
Some resources support embedding of related sub-resources. For instance, when retrieving a payment any refunds can be embedded by using the embed=refunds query string parameter. See the Get payment endpoint for more information.
Amount changes
All amounts in the API are passed as a map containing both a currency and a value property, for example:
{
"amount": {
"currency": "EUR",
"value": "10.00"
}
}
This example object describes an amount of โฌ10.00.
NoteIf you specify an amount, you must specify the correct number of decimals. We strongly recommend sending
valueas a string. And even though most currencies use two decimals, some use three or none, likeJPY.
All amounts returned in the v2 API will use this format.
Locale changes
Only full locales with both the language and the country code are supported, e.g. nl_NL. Locales are always returned as full locales.
Combined date and time fields
Formatting of fields such as createdAt has been updated to be strictly compliant to ISO-8601 formatting. Example value: 2018-03-05T12:30:10+00:00.
Changes in the Payments API
The following changes have been made in regards to the status of payments:
- The statuses
paidout,refundedandcharged_backhave been removed. - The status
cancelledhas been renamed to canceled (US English spelling). - If you want to see if a payment has been settled to your bank account, it will contain the
settlementkey in the_linksproperty. - If you want to see if a payment has any refunds, the payment will have the
refundskey in the_linksproperty, which will point you to the refunds resource where you can view the refund details. - If you want to see if a payment has any chargebacks, the payment will have the
chargebackskey in the_linksproperty, which will point you to the chargeback resource where you can view the chargeback details.
The individual billing and shipping address parameters that can be used when creating a credit card or PayPal payment have been replaced by address objects. Instead of passing billingAddress, billingPostal, billingCity, billingRegion and/or billingCountry (or the equivalent fields starting with shipping), one should now pass a billingAddress (and/or shippingAddress) object, as follows:
{
"amount": {"currency": "USD", "value": "100.00"},
"description": "Order #12345",
"billingAddress": {
"streetAndNumber": "Dorpstraat 1",
"postalCode": "1122 AA",
"city": "Amsterdam",
"region": "Noord-Holland",
"country": "NL",
}
}
NoteThe usage of the address object parameters remains optional. Please refer to the Create payment documentation for exact specifications on what input is accepted.
The following fields have been changed, renamed or moved:
cancelledDatetimehas been renamed tocanceledAt.createdDatetimehas been renamed tocreatedAt.expiredDatetimehas been renamed toexpiredAt.failedDatetimehas been renamed tofailedAt.paidDatetimehas been renamed topaidAt.canBeCancelledhas been renamed toisCancelable.recurringTypehas been renamed tosequenceType. This field is now always present. A one-off payment (not the start of a recurring sequence and not a recurring payment) will have the valueoneoff.redirectUrlandwebhookUrlare now part of the top-level object for Payments.links.paymentUrlhas been renamed to_links.checkoutas per HAL specifications.failureReasonhas been moved from the Payment resource to the credit card detail object, and no longer available for Bancontact payments.
The following fields have been removed:
expiryPeriodhas been removed from the Payment resource. You can useexpiresAtwhich contains the same information.issuerhas been removed from the Payment resource. You can however, still pass it to the Create payment endpoint.details.bitcoinRatehas been removed from the Bitcoin detail object.details.bitcoinAmounthas been removed from the Bitcoin detail object.details.cardCountryhas been removed from the credit card detail object.- The option to include the settlement using the
includequery string parameter has been removed.
These new fields have been added:
settlementAmounthas been added to the responses of the Payments API, the Refunds API and the Chargebacks API. This optional field will contain the amount that will be settled to your account, converted to the currency your account is settled in. It follows the same syntax as theamountproperty.
Note that for refunds and chargebacks, thevaluekey ofsettlementAmountwill be negative.
Any amounts not settled by Mollie will not be reflected in this amount, e.g. PayPal or gift cards._links.statushas been added to the responses forbanktransferpayments. Your customer can check the status of their transfer at this URL._links.payOnlinehas been added to the responses forbanktransferpayments. At this URL your customer can finish the payment using an alternative payment method also activated on your website profile.
Changes in the Refunds API
The following fields have been changed, renamed or moved:
amountis now mandatory when creating a refund. You must specify bothamount.currencyandamount.value.- The
amountfield is now of theamounttype and contains avalueand acurrency. payment, which contained the payment resource related to the refund, is no longer returned. Instead, the payment ID is returned by default, in thepaymentIdfield. The payment resource can still easily be accessed using thepaymentkey in the_linksproperty.- The resource will contain a link to the settlement if it is settled (via the
settlementkey in the_linksproperty.
These new fields have been added:
settlementAmounthas been added. See the explanation of thesettlementAmountfor the Payments API.
Changes in the Chargebacks API
The following fields have been changed, renamed or moved:
- The
amountfield is now of theamounttype and contains avalueand acurrency. chargebackDatetimehas been renamed tocreatedAt.reversedDatetimehas been renamed toreversedAt. This field is now only returned if the chargeback is reversed.payment, which contained thepayment IDrelated to the chargeback, has been renamed topaymentId. The payment resource can easily be accessed using the payment key in the\_linksproperty.- The
resourcewill contain a link to the settlement if it is settled (via the settlement key in the\_linksproperty.
These new fields have been added:
settlementAmounthas been added. See the explanation of thesettlementAmountfor the Payments API.
Changes in the Methods API
The following fields have been changed, renamed or moved:
amountincluding minimum and maximum have been renamed tominimumAmountandmaximumAmount. This should be an object containingvalueandcurrency.- The
imagefields normal and bigger have been renamed tosize1xandsize2x. - Pagination has been removed, so all fields related to pagination are not available anymore. The
listmethod will now return all payment methods.
The following parameters have been changed or added:
- The parameter
recurringTypehas been renamed tosequenceType. Possible values areoneoff,firstorrecurring. - The parameter
amounthas been added. This should be an object containingvalueandcurrency. Only payment methods that support the amount/currency will be returned. Example:https://api.mollie.com/v2/methods?amount[value]=100.00&amount[currency]=USD
Changes in the Issuers API
The issuers API has been removed. Instead, you can get the issuers via the Get method endpoint on the Methods API using the issuers include.
Changes in the Customers API
The following fields have been changed, renamed or moved:
createdDatetimehas been renamed tocreatedAt.recentlyUsedMethodshas been removed.
Changes in the Subscriptions API
The following changes have been made in regards to the status of subscriptions:
- Subscriptions that are canceled can be retrieved from the API, and will not return a HTTP status
410 Gone. - The canceled status is changed from British English to American English.
The following fields have been changed, renamed or moved:
createdDatetimehas been renamed tocreatedAt.cancelledDatetimehas been renamed tocanceledAt, and is now only returned when the subscription is canceled.webhookUrlis now part of the top-level object for Subscriptions.
Changes in the Profiles API
The following fields have been changed, renamed or removed:
createdDatetimehas been renamed tocreatedAtupdatedDatetimehas been removed.- phone is now formatted in
E.164formatting. - The API keys
subresourcehas been removed.
New APIs have been added, such as the Get current profile endpoint.
Changes in the Settlements API
The following fields have been changed, renamed or moved:
createdDatetimehas been renamed tocreatedAt.settledDatetimehas been renamed tosettledAt.- The fields
paymentIds,refundIdsandchargebackIdshas been removed. - All amounts have been changed to the
amounttype. Note that thecosts.amount\*fields can have more decimals than you would expect. The same goes forrate.fixed, which can contain fractional cents.
amount.net,amount.vatandamount.grosshave been moved one level up asamountNet,amountVatandamountGross. - If the settlement has been invoiced, it will contain the invoice key in the
\_linksproperty. - The
referenceparameter in the List settlements endpoint has been removed.
Changes in the Mandates API
The following fields have been changed, renamed or moved:
createdDatetimehas been renamed tocreatedAt.
Changes in the Organizations API
- The fields country,
registrationDateandregistrationTypehave been removed. - The field
addressis now anAddressobject.
Changes in the Permissions API
- The field
warninghas been removed.
Changes in the Invoice API
issuedDatehas been renamed toissuedAt.paidDatehas been renamed topaidAt.dueDatehas been renamed todueAt.amount.net,amount.vatandamount.grosshave been moved one level up asnetAmount,vatAmountandgrossAmount.pdfhas been moved into the\_linksproperty.
Changes in error reporting
In general, error reporting has been improved to help you resolve any implementation errors as fast as possible.
The HAL specification has been adopted for error reporting as well. The difference between v1 and v2 is best explained using an example.
The new error reporting format in v2 is the following:
{
"status": 401,
"title": "Unauthorized Request",
"detail": "Missing authentication, or failed to authenticate",
"_links": {
"documentation": {
"href": "https://docs.mollie.com/overview/authentication",
"type": "text/html"
}
}
}
The HTTP status returned is now part of the error response, title is the default HTTP status message, the message field is renamed to detail.
Updated 4 months ago