We have introduced an order type and return this order type in the response of the Order:Create, in the Order:Status API and in the exchange call payload. Possible values can be sale (which is the default value), paylink (when a order is created with payment method id 961) and payment_based_checkout (when a payment based checkout order is started.

When a payment based checkoutis started you can use the Order:Update API to set the reference and a description of the order, after you have created the payment based checkout order. It can be possible then during the creation of such a payment based checkout the order is not yet fully processed by the order management system, therefore the reference and description for these kind of orders can be updated after the creation of a payment based checkout order.

Furthermore we have released a few smaller improvements:

• The hosted payment page now uses the payment method sequence if available. Endusers mainly see this page during partial payments to select the payment method with which they can complete an order.
• PayPal: Fixed an issue where products with a negative amount were incorrectly added to the products list.
• PayPal: Fixed an issue where PayPal payments would not transition from status authorised to the correct status if an error occurs while capturing.
• Payconiq: Fixed an issue where the payer IBAN field contains the name of the payer and the name field was left empty. The IBAN and name are now both set correctly.
• Pin: Added an optional field terminalPin to the ORDER.PAYMENT.PIN object in preparation to support SoftPos terminals.
• Banktransfer: Updated the banktransfer screen to fix some display issues involved with currency conversion.

We have released a few improvements in processing orders on our TGU's.

• Negative and positive amounts for products we now allow negative and positive amounts for all order products. Before this change we forced the amount to be positive or negative based on the product type. The system will still add a ROUNDING product if the amount of all the products combined does not match the order amount.

• Improved functionality regarding grouped payment methods if you had grouping enabled for giftcard payments (which can be configured when editing your sales location in https://my.pay.nl) and you would start an order for a specific giftcard (eg Fashioncheque), the order would have payment method giftcard and would route you to the generic giftcard screen. Now the order will correctly get the payment method fashioncheque and will immediately route the user to the fashioncheque branded screen.
  Please note the screen will still accept card number inputs of other card brands that are enabled even though the user is on the fashioncheque branded giftcard screen.

• The status of a payment will now better reflect the payment process when a user is redirected to a payment method, the payment will get the status Paying to reflect that the user is redirected.
  Before this change, we would start polling the status and receive a Pending status and move the payment status to Pending accordingly even though the user is still in the payment process. Now the payment will keep the Paying status to indicate the user is still in the payment process.
  The status Pending is now used as intended: When the enduser has returned from the supplier but the state of the payment is not known or not guaranteed. This mostly happens with bank transfer payments for example, where the user has completed the payment process but the amount has not yet been transferred to our bankacccount.

• The sandbox will not generate random values anymore the sandbox screen now allows an empty customer id and name. The sandbox will not generate a random name anymore if they are left empty. To accommodate the generation of random names and ids we have added a button in the input fields to generate a random customer name or id in the sandbox screen. Please note that the random name and id generator will take the chosen language into account when generating a random value.

We have released some small changes for the following endpoints:

• In the Terminals:Get and the Terminals:Browse the address configured on service location level is now returned in the output instead of the address configured in the terminal details.
• In the Merchant:Create a contactPhone, contactEmail and a website URL can now be submitted. The contactPhone and contactEmail are the primary contact details used if the merchant needs to be contacted. Additional contact methods can be added with the ContactMethods API's. In the Merchants:Get and the Merchants:Browse these data elements are returned. In the Merchants:Update these elements can be updated.

We have added some extra attributes in the PaymentMethods core data API

• targetCountries; indicates the targetCountries for each paymentMethod. E.g. the targetCountry for iDEAL is 'NL', the targetCountry for Bancontact is 'BE'.
• For each paymentProfile in a paymentMethod we now also return:
  • The riskCategory; e.g. iDEAL has a low risk category
  • The customerIdType; indicates how the payer is paying for the transaction. E.g. for iDEAL the payer is using his/her IBAN. For card payment the payer is using a creditcard.

We have released a few small improvements for the following endpoints:

• In the Service:GetConfig we now return the address that is configured on service location level
• In the Order:Create response and in the exchange call we now return the stats data and the transferData if supplied when creating an order.

We have released to new endpoints to get more information about your clearings & settlements. These endpoints are still in beta, so if you want to have access to these API's please contact your contactperson within Pay. to retrieve the necessary authorisations.

A short description of these endpoints:

• Clearings:Summary; A Pay. clearing contains multiple clearing lines. This API returns the clearing grouped by settlement (the actual transfer of the money to your bankaccount. You can filter on clearing id or settlement code (the code visible on your bank statement).
• Clearing:Records; Retrieve the transactions that are in a clearing. Provide a clearing ID or a settlement code (the code visible on your bank statement) to retrieve the transactions that are in that clearing.

We have released new functionality for some endpoints

• Terminals:Get and Terminals Browse we added the following fields to the output:
  • The hardwareCode (our TL-code) and physical serialNumber from the terminal;
  • The MCC code linked to your service / sales location in the service object;
  • The contact details (phone number and e-mail) that are linked to your service / sales location in the serviceobject;
  • The incorporationCountry field in the merchant object, this country represents the country in which the merchant is legally registered or incorporated.
• In the Merchant:Create, the License:Create and the License:Update we have added a rolesobject, so that you can indicate if the person that you want to add (to the company) is:
  • A primary contact person (for Pay); meaning that this person that will be contact by Pay when there a generic questions regarding which cannot be handled by operational/financial or technical employees. Usually a program manager or a project leader;
  • An internal administrator; will be shown to your users when there a errors or issues.
• The License:Get and License:Browse are retuning this roles object in the output.

The settings of Tip request in the APP only work if you perform a Direct Payment, if an external Application starts the payment, Tip can be enabled now by request by sending some parameters via the integration object.

Read more: https://developer.pay.nl/docs/softpos#ask-the-customer-for-a-tip-through-inject

We have introduced a new endpoints for terminal management (to support in-person payments).

• Terminals:Create; use this endpoint to create a terminal for a service location. You need to have an activation code (will be presented on the payment terminal). If you are a partner and have access to your sub-merchants you can also create a terminal for a service location from one of your sub-merchants. Note you need to have additional rights to use this endpoint.
• Terminals:Delete; if you want to remove a terminal from a service location you can use this endpoint. Also here; if you are a partner you need to have access to that merchant to be able to remove a terminal for a sub-merchant. Note you can undelete your delete action within a 15 min time windows with the Terminals:Undelete endpoint.

With the introduction of V3 of our API’s we have introduced our new transaction processing platform; called the Transaction Gateway Unit platform. Together with this TGU platform we have released V1 of our Order API.

The main benefits of this Order API;

• Brand new API's for the processing of transactions on our Transaction Gateway Unit platform
• Support to handle multiple payments to pay for an order. E.g. an order can be paid with a voucher and with an iDEAL transaction.
• Fully compatible with iDEAL 2.0 and all of iDEAL's new features (like fast checkout). See this page for more information: https://developer.pay.nl/docs/ideal
• All new features (and new payment methods) will be introduced on this TGU platform
• Easy switching between different TGU's when a TGU is unavailable due to disruptions or maintenance

We strongly advise to change your implementation to use these new Order API’s, please contact your contact person within Pay for more information.