• Creditcard: Added support for tokenisation for recurring creditcard payments
• Riverty: Orders rejected by riverty will now correctly get the denied status
• Fixed orders not going to status captured when we receive a successful payment notification when the order has status aborted
• Giftcards: Updated the error message when customers submit the form with only the card prefix filled in.
• De Cadeaukaart: Updated the header image
• Beauty and More: Updated the header image

We have added several new payment methods:

Twint

Twint is a mobile payment app widely used in Switzerland, designed for everyday payments in stores, online, and between individuals. It is backed by major Swiss banks like UBS, Credit Suisse, and Raiffeisen, making it a nationally trusted platform. Twint links directly to a user's bank account or a prepaid balance and allows payments through QR codes or Bluetooth.

The app is more than just a payment method; it also supports storing loyalty cards, sending money to friends, and even paying for parking. With over five million active users, it has become deeply integrated into Swiss commerce and daily life. However, Twint is tailored exclusively for the Swiss market and cannot be used internationally. Its security standards are high, relying on bank-level encryption and authentication, which adds to its credibility and widespread adoption.

To read more click here.

Swish

Swish is a Swedish real-time mobile payment platform that integrates with participating banks’ infrastructure and the national Bankgirot clearing system. Each transaction is initiated via the Swish mobile app, authenticated through the BankID e-identification protocol, and linked to the user’s bank account via their registered phone number. Payments are processed in seconds, 24/7, using encrypted communication and direct bank-to-bank settlement. The system supports peer-to-peer transfers, merchant payments, and e-commerce integration through QR codes or API endpoints, and is restricted to accounts in Swedish banks participating in the Swish network.

To read more click here.

Bizum

Bizum is a mobile payment solution widely used in Spain, designed to enable instant money transfers between users and businesses through mobile phone numbers. For merchants, Bizum offers a fast, secure, and user-friendly way to receive payments both online and in physical stores. It integrates directly into a business’s website, app, or point-of-sale system, allowing customers to pay simply by entering their phone number or scanning a QR code. Transactions are settled in real time, and payments are authorized through the customer’s banking app, ensuring strong security and compliance with PSD2 regulations. Since Bizum is supported by most major Spanish banks and has over 25 million users, it provides businesses with broad customer reach, reduced cart abandonment, and no risk of chargebacks.

To read more click here.

Satispay

Satispay is a mobile payment platform originating from Italy, designed to facilitate secure and convenient transactions directly from users' smartphones. Unlike traditional payment methods, Satispay operates independently of credit or debit card networks, instead linking directly to users' bank accounts via their IBAN (International Bank Account Number).

To read more click here.

Vipps

Vipps is a Norwegian mobile payment app developed by DNB. It allows users to send and receive money using phone numbers, pay businesses, split bills, and donate to charities. Vipps is secured with BankID and widely used in Norway, with over 4 million users. It works for both personal and business payments and is a key player in Norway's move toward a cashless society. In recent years, Vipps merged with Denmark’s MobilePay and Finland’s Pivo to form a Nordic mobile payment alliance.

To read more click here.

We have released new version since the last POS.SDK. Make sure to update to the latest version for the newest features and bugfixes!

• Android softpos: v0.0.83
• Sunmi hardpos: v0.0.18
• PAX hardpos: v0.0.8
• iOS Tap to pay on iPhone: v0.0.23
• React Native: v0.0.49

NOTE: the SDK is still in active development, so if you encounter an issue, please contact PayNL support!

Documentation: https://github.com/paynl/POS.SDK

New features

• Added support for printing tickets! (supported on Sunmi softpos printers or the build-in hardpos printers)
• Added support for MIFARE classic cards (documentation)
• Added support for Merchant Approved Transactions (offline processing)

Bugfixes

• fixed issues where the PIN prompt was not shown on dual screen devices
• fixed issues where the Android softpos SDK did not initialize correctly
• fixed issues where the Sunmi P terminal did not want to keyload
• Several small fixes to prevent app crashes

MB Way is now available to use. It is Portugal’s leading mobile payment app, developed by SIBS, the operator behind the country’s Multibanco system. It allows users to link their bank cards and make peer-to-peer transfers, online payments using virtual cards, in-store purchases via QR or NFC, and even ATM withdrawals without a physical card.

With over 3.5 million users and around 45% of Portuguese e-commerce transactions, MB Way is deeply embedded in the country’s payment ecosystem. It’s widely accepted across banks, retailers, toll systems, and more.

The app is known for its ease of use, strong security, and popularity among young people. It supports up to eight bank cards and is expanding internationally through the European Payments Initiative.

We released a few small improvements:

• The Service:GetConfig API now returns a publication object with a domainUrl; which reflects the configured URL on service / saleslocation level;
• The DirectDebit:Get and DirectDebits:Browse API now returns a decline object if the direct debit transaction is not successfully executed with more detailed information. A description can be found here; https://developer.pay.nl/docs/transaction-statuses#direct-debits-statuses.

• PayByBank: Fixed a problem where the country dropdown would not contain all available countries.
• Creditcard: Added the missing creditcard object in the payment data when using the legacy /v1/transactions API endpoint.
• Resolved an error processing an order for a service that has been deleted after the order was started.
• Mondu: Removed the requirement to start the order with a company name and VAT number to select this payment method.

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.