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.
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.
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 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.
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.
