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.

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.