Changelog
Knowledge baseContact

The April update (Week of 10 April)

by Tom Bossink

We have released an update. Read more below 👏

Core data; BillingLineTypes and UnitTypes

We have introduced new endpoints to retrieve Core data for the new Billing API that will be launched soon.

PaymentVerificationMethods

A payment can be secured by different methods. On a card present transaction (on a payment terminal) it is known ad the Card Verification Method (CVM). iDEAL transactions can be verified by e.g. a QR code or by an app2app payment. We combine all these options in the PaymentVerificationMethods

With the Core data API; PaymentVerificationMethods you can retrieve a list of all methods. See for more information; https://developer.pay.nl/reference/get_paymentverificationmethods

And with the Transaction:Status and Transaction:Info endpoints the used method is returned if it is available.

Support for different "base URLs"

For the Transaction:Create, Transaction:Status and Transaction:Info endpoints support for different base URLs is added. In this documentation environment you can select (in the API explorer) against which base URL you want to try you API request.

Merchant:Create

We have introduced a few changes in the Merchant:Create endpoint

  • The Pay. welcome e-mail will only be sent if loginAccount=true.
  • The phone number and e-mail adress of a person is now optional. It is not required anymore

The March update (Week of 13 March)

by Tom Bossink

We have released quite a big update. Read more below 👏

AuthorisationGroups

We have introduced a new endpoint to retrieve the AuthorisationGroups (https://developer.pay.nl/reference/get_authorisationgroups). If you call this API then you will retrieve PAY.'s public groups. If your account has rights to create own groups, you will also retrieve these groups.

Merchant:Create

We have introduced several enhancements to this endpoint:

  • You can submit one or more clearing accounts
  • You can supply compliance data (e.g. pep indication, ubo status etc) for each person linked to the merchant
  • You can directly create authentication tokens. You can indicate which authorisation groups needs to be linked to this token.
  • The account will be linked to the merchant if there is already an account available for the e-mail address that is supplied. Note; the account needs to accept in the PAY. admin that he/she is related to that company.
  • You can directly indicate which authorisation groups needs to be linked to the account that you have created
  • We return the secrets (ie the token , the service secret and the license secret), these can be used in other API calls.

The full API definition, including some samples can be found here; https://developer.pay.nl/reference/post_merchants

Other improvements

  • The Languages API also returns a link to an image URL
  • The Categories API now returns the initialMCC and initialRiskCategory that is linked to each category
  • The Countries API also returns nationality data, including translations;
  • The Merchant:GetConfig endpoint is removed, instead the Service:GetConfig endpoint is changed. You can authenticate with an AT-code/token or with an SL-code/secret. If AT-code/token is used the serviceID needs to be included in the body parameters. See; https://developer.pay.nl/reference/get_services-config
  • The Service:GetConfig API is enlarged with encryptionKeys
  • If there are no translations available (mainly in the Core API's) we now return translations: null instead of translations:[], since the translations are returned in objects instead of arrays.

A few smaller improvements (week of 27 feb)

by Tom Bossink

We have released a few small improvements. Read more below! 🤝

Merchant:Create

if you create a merchant as a partner of Pay the merchant will be created under your partner account. For more information, please refer to: https://developer.pay.nl/reference/post_merchants

Transaction:Create

You can send a reference with refers to e.g your internal order id when you create a transaction. This field is now mapped to the correct field in the Pay. admin. With this improvement you can see which reference you have send if you open the details of a transaction. For more information, please refer to: https://developer.pay.nl/reference/post_transactions

Introduction of v2

by Tom Bossink

We have introduced v2 of our API's. The mean reasons for this version bump is that we now provide error details according RFC7807 for all our API's and that we have introduced an updated response for the Service:GetConfig and Merchant:GetConfig. We have also added some minor changes. More details below 🌱

New way to provide error details

We now adhere to the Problem details for HTTP APIs standard (RFC7807; https://www.rfc-editor.org/rfc/rfc7807).

When HTTP response code 400 or 422 is returned in the body the details are provided as follow:

{
    "type": "https://tools.ietf.org/html/rfc2616#section-10",
    "title": "An error occurred",
    "detail": "merchant.name: Is empty\nmerchant.coc: Is empty",
    "violations": [
        {
            "propertyPath": "merchant.name",
            "message": "Is empty",
            "code": "PAY-2828"
        },
        {
            "propertyPath": "merchant.coc",
            "message": "Is empty",
            "code": "PAY-2828"
        }
    ]
}

Updated response of the Service:GetConfig and Merchant:GetConfig

We have introduced a new response of the Service:GetConfig and Merchant:GetConfig. With this change the frontend implementation to create your own checkout will become much more easier. For a detailed description, please check https://developer.pay.nl/docs/create-the-checkout

Other changes

  • You can now authenticate the Transaction:Create API (https://developer.pay.nl/reference/post_transactions) with an SL-code and a secret besides an AT-code and a secret
  • Introduced a new endpont to upload documents; Documents:Add (https://developer.pay.nl/reference/post_documents)
  • Added support for the accept-languageparameter in the header. If supplied the API will return 400/422 error message in the language specified, if available. If there is no translation available, we will fallback to error messages in English.