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"
}

Added field PointOfInteraction to Orders

This field is used to indicate where a transaction takes place. Based on the value of this field, certain payment methods might be enabled or disabled. Possible values are:

• ON_THE_MOVE
• ECOMMERCE
• IN_PERSON
• INVOICE
• DEBT_COLLECTION
• FUNDING
• PAYMENT_REQUEST
• RECURRING
• UNATTENDED
• MOTO
• PAYOUT

The main use of this feature is the Pin payment method (1927) which is only available when the pointOfInteraction is one of the following values:

• IN_PERSON
• DEBT_COLLECTION
• UNATTENDED

Note: If the payment method is set to pin (1927) when starting an order, the point of interaction is automatically set to IN_PERSON if no specific point of interaction is given.

new_ppt IPN behaviour for authorised/captured flow

If autocapture is enabled, no IPN will be sent when the order is authorised. When autocaptured, a new_ppt IPN will be sent. When autocapture is disabled, the new_ppt will be sent when the order is authorised. When the order is manually captured, a capture IPN is sent. The payload of all these IPN's will still remain the same. This behaviour is updated the match the behaviour of transactions created using the rest.pay.nl and rest-api.pay.nl API's.

Other changes

• Giftcard: Added the Purdey Cadeaukaart

• Giftcard: Added the Nationale Tuinbon

• Giftcard: Added the Huisdieren Cadeaukaart

• Pin: Determine the correct TRM and secure status for pin transactions.

• Update the amount input in the Donation/Payment screen to allow for decimal values on mobile devices

• Fix an error where the Donation/Payment screen would allow lower amounts than the minimal amount.

• Pass the customer locale to the ECR pin server if available to start the transaction in the correct language.

• PayPal: The order will now also get the status Declined if PayPal denies the capture of an authorised payment.

• Klarna: Fixed an issue where some authorised Klarna orders could not be voided.
• Fix issue where a customer_key was generated based on an empty customer identifier. The customer_key will now stay empty until there we have received an actual customer identifier.
• Add CORS headers to the Order:Status API to allow all origins to access this API.
• Endusers will now be redirected to the known successUrl or errorUrl when finishing an order when there is no known returnUrl. The most common use-case for this is the Payment/Donation screen where an order is started without a known returnUrl.

We have released a few new endpoints in the last days:

• Directdebits & Mandates; On a mandate direct debit transactions are executed. You can create a mandate for a single direct debit transaction, for recurring direct debit transactions of for flexible direct debit transactions. Note you need to have additional permissions to use these new endpoints. Please contact your contactperson within Pay.
• We introduced a Refunds:Browse endpoint and adjusted the output of the Refunds:Get (is backwards compatible according our API definition. You can use the Refunds:Browse endpoint to get a list of all executed refund transactions.

Also some smaller improvements and bugfixes:

• We made the integrationCode field and the authenticationTokens object in the Merchant:Create endpoint optional. Note if no authenticationToken is supplied we will automatically create a default token in your merchant account.
• In the Terminals:Create endpoint the description fields is now optional

• Improved the detection of the enduser's locale when no enduser locale info was given when starting the order.
• Givacard: Fixed an issue where the Givacard payment method would not be available on the hosted payment page.
• Fixed an error when handling exceptionally large exchange URL's.

• Add the new Order:Payment API. With this API you can add a payment for any enabled payment method payment method on an existing order. The input for the selected payment method is the same as the Order:Create , so any required user input can be given right away. In case the order is fully paid, this API will return the returnUrl as redirect URL to return the enduser back to the shop. If the order is not fully paid, the redirect URL will link to the payment page for the enduser to complete the order. If needed, you can also repeatedly call this API for the same order and create multiple payments to complete an order. This could be useful when redeeming multiple giftcards for one order for example.
• Updated the donation screen to support all available payment methods. Also, the donation screen now takes the correct layout id (LY-code) into account, applying the correct styling for your brand like on the hosted payment page.
• Add support for the status Pending (98) on the sandbox payment screen.

• Add support for the Intratuin Giftcard.
• Add support for the Travelbags Giftcard.
• Add support for the Loods5 Giftcard.
• Add support for the Wissel Giftcard.
• Allow the result key for JSON payment notifications to be at the root level. By default we expect the result key to be in a subkey 'request': $response['request']['result']. We now also allow the result key to be at the root level: $response['result'] .
• Fixed a rare issue where the payment notification was sent twice occasionally for bancontact payments. In this second notification, the links to the order were also malformed.

We have released a few small improvements in the last days.

TGU improvements:

• Added a payment history overview for partial payments where you can see the previous payments. This is a setting and is disabled by default. Please contact your contactperson within Pay if you want to enable this setting.
• Added functionality to redirect the enduser directly to the payment method if there is only 1 payment method available in the hosted payment page. This is also a setting and disabled by default. Please contact your contactperson within Pay if you want to enable this setting.
• Add currency selection to the sandbox screen to enable testing with multi-currency.
• Updated the payment screen when paying with Google Pay. Instead of showing the standard credit card screen when you pay with Google Pay, we now show a specific Google Pay payment screen.

GMS improvements:

• In the Service:GetConfig API we now return the contactPhone and contactEmail and the address configured on the sales location. If no specific data is configured on sales location level we return the data configured on merchant level.