This week we have released a few improvements:

• Service:GetConfig we have added a few data items to the output of this API
  • For each checkoutOption we now return an id. This ID reflects the ID that can be used to start a payment. If for Online Card payments (CNP) and for Vouchers/Giftcards in the sales location grouping is enabled, the 'generic' creditcard or voucher/giftcard ID is returned. If grouping is not enabled then we return the ID of the payment method;
  • For each checkoutOption we also a returning a smartGrouping flag and for each paymentMethod in the checkoutOption we return a targetCountries list. The idea is that if the payer originates from e.g. Danmark and for the Online Card payments (CNP) payment methods smartGrouping is enabled, you can check if there is a payment method specific for Denmark and show this as 'seperate' payment method in you checkout page, before showing the other CNP payment methods (grouped) in your checkout.
• The Transaction:Info now returns in the paymentMethod object also the terminalCodeif the transaction is an in-person card payment, so that you have a reference on which terminal this transaction is executed.

We have also created new endpoints to set invoice and clearing settings on the merchant and added these settings to the Merchants:Info endpoint. The following settings are available:

• clearingPeriod; possible options are DAY, WEEK, MONTH and indicates how transactions are grouped on your clearing. By default they are grouped per month. If grouped by WEEK and there is a change of month two clearings will be generated that week. If grouped by DAY a clearing will generated every day;
• clearingFrequency; possible options are MANUAL, DAY, WEEK, MONTH. We check every DAY, WEEK, MONTH if there are funds that needs to be cleared. If that is the case we will do a settlement to the clearing bank account. If MANUAL is configured we will not check automatically if we need to clear funds and we expect you to use addClearing endpoints to clear funds to the clearing bankaccount.
• clearingMoment; possible options are DIRECT or COLLECT. Each payment method has a so-called release period. These release periods are defined in payout scheme's. Depending on factors such as your relationship with PAY, transaction history, payment mix, and the company’s service level (e.g., few chargebacks and disputes), a higher payout speed can be applied. DIRECT means that the funds will be cleared as soon as the revenue has been released. COLLECT means that the funds will be cleared as soon as the revenue from the clearing period has been released.
• invoicePeriod; possible options are WEEK or MONTH. Transaction costs and/or other fees will be grouped per MONTH or per WEEK;
• invoiceFrequency; possible options are WEEK or MONTH. We will send an invoice (or will settle the invoice with your balance) every WEEK or MONTH;
• settlementPerClearing; indicates if every clearing results in a separate settlement on the clearing account;
• splitByTurnoverGroup; indicates if we need to spilt the clearing by turnovergroup. For each turnovergroup a different clearing will be generated;
• mt940;
  • change the MT940 bankaccount in the MT940 file;
  • change the headers in the MT940 file; possible options are STANDARD, CUSTOM or TWINFIELD. If CUSTOM is defined then the custom headers configured are returned.

With the Merchant:Info endpoint a settings object is available which returns these settings. With the Merchant:UpdateSettings endpoint these settings can be set.

📘

Note; depending on your rights you can set and retrieve these clearing and invoice settings

In this new version, we've released local ECR. This feature allows you to start payment using TCP messages on your local network. This allows for an alternative to the Cloud ECR solution we already provide.

For more technical information, go to our Github Example page: https://github.com/paynl/PAY.ECR

• Added a new keycustomerMethod to every Payment object in an order. When available, this object will contain a key type which specified the used method. The second key, data will contain specific data for that method. We currently have 2 types, iban and card:

IBAN:

"customerMethod": {
  "type": "iban",
  "data": {
    "iban": "NL35RABO0117713678",
    "name": "Stichting Derdengelden Pay.nl",
    "bic": "RABONL2U"
  }
}

Card:

"customerMethod": {
  "type": "card",
  "data": {
    "maskedPan": "123456******7890",
    "scheme": "VISA",
    "issuerId": "18533",
    "countryCode": "642",
    "cardType": "consumer",
    "fundingType": "debit",
    "brandCode": "F",
    "brandName": "Visa Classic",
    "brandProduct": "CN"
  }
}

• Updated several polish translations on the checkout screen.
• Giftcards: Added support for non-numeric PIN entry.
• Giftcards: Fixed a bug preventing customers to be redirected to the giftcard input screen when an order was started with payment method giftcard. Customers were redirected to the payment method selection screen in stead.
• Giftcards: Payments requiring input will now have an expire time of 30 minutes. They previously had no expire time, causing abandoned orders to linger for longer than needed.

📘

These new API's are in pilot phase, please contact your contact person within Pay if you want more information or if you want to join the pilot phase.

We have released new API's to manage look & feel templates (layouts). If you have the appropriate rights you can add one or more look & feel templates (layouts) in your merchant account. With these look and feel setting you can customize our hosted payment page so that it shows the page with your logo and your colors.

We have created the following endpoints:

• Layout:Create; Create a new layout. With this layout you can change e.g. the layout of our hosted payment page;
• Layout:Files; Add files e.g. a logo or a background image to the layout you have created;
• Layout:Update; Update the basic settings of a layout;
• Layout:Get and Layouts:Browse; Get a list of layouts or get the basic information of a layout. For all details of a layout use the Layout:Info endpoint;
• Layout:Info; Get the details (also a base64 representation of all uploaded files) from a specific layout;
• Layout:Delete; Remove a layout.

We also released a few smaller improvements;

• The Invoice:Lines endpoint now returns for the turnoverGroup also the bankaccount that is linked to that turnoverGroup;
• The Transctions:Browse endpoint now support a filter on merchant.

📘

These new API's are in pilot phase, please contact your contact person within Pay if you want more information or if you want to join the pilot phase.

We released new API's to create and manage services /sales locations:

• Service:Create; Create a new service (for a merchant). On a service you can enable payment methods and process payments;
• Service:Update; Update the basic settings for a service;
• Service:EnablePaymentMethod; Enable a payment method for a service, including specific settings for certain payment methods;
• Service:UpdatePaymentMethod; Update a payment method if you have set specific settings;
• Service:DisablePaymentMethod; Disable a payment method for a service;
• Service:GetAvailablePaymentsMethods; Get an overview of available payment methods for the merchant/service, including their boarding status for a service;
• Service:UpdateSettings; Update advanced settings on service, e.g. configure your verify settings or configure your exchanges
• Service:AddUrl / Service:DeleteUrl; Add or delete multiple website URLs for a services;
• Services:Browse; Get an (paginated) overview of all services available for a merchant ;
• Service:Get; Get the basic information of a specific services for a merchant;
• Service:Info; Get the detailed information for a service, including all advanced settings and the enabled payment methods.

📘

More information regarding these API's (and a step by step walkthrough) can be found here

PAY.POS SDK

For selected Merchant, it is now possible to integrate the PAY.POS app into your own app, using the SDK! The PAY.POS SDK makes it possible to accept and process payment card on your iPhone or Android (softpos only).

Documentation and examples regarding the SDK can be found on the PayNL Github.

If you want to get started, please contact PayNL support to get your integrationId!

PAY.POS Local ECR

Starting on PAY.POS version 1.1.18, it is possible to use local ECR. This allows PAY.POS to accept payment requests on the local network using the TCP/UDP procotols.

This feature comes with a new screen: The Order presentation screen. Instead of using TRANSACTION_START via Local ECR, you can show the description & products to the customer live via ORDER_CREATE. When all the products have been registered, and the customer wants to pay, you can transform your order into a transaction and the full order object is sent to the PayNL processing.

Documentation and examples regarding the SDK can be found on the PayNL Github.

• Fixed an error where an additional payment was created when redirected to the hosted payment page after a payment was already created.
• Add supplier data for failed pin transactions to make the incident_code and incident_test fields available.
• Fixed not being able to start an order for several high risk payment profiles:
  • 711 (Carte Blue High Risk)
  • 715 (Maestro High Risk)
  • 708 (Postepay High Risk)
  • 1948 (Nexi High Risk)
  • 1942 (Dankort High Risk)
• Blik: Fixed using the wrong value as the payer id. Payer id will now be empty as Blik does not provide any.
• PayPal: Fixed setting a PayPal payment to captured with amount 0 if the capture is still pending.

We released two new endpoints:

• Transaction:Browse; returns a list of transactions. This endpoints supports various filters to narrow search for transactions
• Transaction:Find; if you want to search a specific transactions. You can provide a needle. The API returns the transactions that match the needle string, which is applied to various fields such as the transation description, amount, date etc.

📘

These new endpoints are in pilot phase, please contact your contact person within Pay if you want more information.

Smaller improvements:

• We noticed that some API's that supported pagination where not returning a pagesobject. That has been fixed. All API's that support pagination are now returning a pages object which returns the number of pages in the complete resultset.
• In the Terminals:Get and Terminals:Browse endpoints we now return "connectionStatus": "UNKNOWN" if we don't know the connectionStatus.
• In the Clearings:Settlement endpoint we introduced a few new filters:
  • settlementDate; filter your settlements on a date. You can use the equals (eq), greater then (gt), greater then or equals (gte), less then (lt) or less then or equal (lte) operators.
  • turnoverGroup; filter your settlements on a certain turnovergroup. You can use the equals (eq) or not equals to (neq) operators.

• Added a new giftcard: BBQ cadeaukaart
• Added a new giftcard: Sauna en Wellness cadeaukaart
• Added a new giftcard: U-pas
• Added a new giftcard: Beauty & More cadeaukaart
• Stop sending new_ppt IPN on status authorised for orders that have autocapture enabled.
• Removed the hosted payment page for MobilePay, customers are now redirected directly to MobilePay.
• PFP (Pay by phone): Several updates to the PFP payment flow that should increase conversion.
• Fixed an issue that prevented YourGift voucher payments to be handled incorrectly.
• Purdey cadeaukaart: Fixed an issue where the Purdey Cadeaukaart prefix was not detected correctly on the voucher input screen.

• Remove support for the ideal bank selection, this is no longer supported by iDEAL2.0
• PayPal: Fixed the order reference not being sent to PayPal as invoice_id in some cases
• PayPal: Add a fallback product name to products if the given product name is empty
• Fix the rounding down product having a positive amount rather than a negative amount
• Pin: Send the locale to the pin provider so the terminal switches to the correct language if supported
• Pin: Add the fields incident_code, incident_text, authorization_code, signature and ticketData to the supplierData of a pin payment. See below for a sample:

"supplierData": {
    "signature": false,
    "ticket_data": {
        "period": "5087",
        "legal_id": null,
        "merchant": "123456",
        "terminal": "ABCDEF",
        "date_time": "2025-03-28 10:16:14",
        "shop_logo": "",
        "valid_thru": null,
        "card_number": "123456xxxxxxxxx7890",
        "dcc_label_1": null,
        "dcc_label_2": null,
        "dcc_value_1": null,
        "dcc_value_2": null,
        "transaction": "1000511",
        "acquirer_zone": null,
        "shop_location": "",
        "dcc_disclaimer": null,
        "cardholder_name": null,
        "pin_status_text": null,
        "issuer_label_name": "V-PAY",
        "reading_mode_text": "Leesmethode: CHIP",
        "authorization_code": "AB1234",
        "dcc_billing_amount": null,
        "merchant_reference": "2000 0123 1234 1234",
        "service_identifier": "8810",
        "transaction_amount": 3,
        "card_sequence_number": "1",
        "signature_label_text": null,
        "ticket_footer_line_1": "DANK U",
        "ticket_footer_line_2": "TOT ZIENS",
        "transaction_currency": "EUR",
        "card_brand_label_name": "V PAY",
        "formatted_card_number": "123456xxxxxxxxx7890",
        "application_identifier": "a0000000032020",
        "cardholder_name_extended": null,
        "dcc_exchange_rate_information": null,
        "cardholder_billing_currency_name": null
    }
    "incident_code": "0000",
    "incident_text": "Ok",
    "authorization_code": "W00208"
}