This article describes the new features and changes in API version 4 compared to API version 3.1.
A new major version is introduced when a change means that the backward compatibility of the API can no longer be ensured. Before switching to this API version, please check whether the changes have an impact on your system and make the necessary adjustments.
Specification of the UTC offset in date/time
The date and time values output by the konfipay API are in CEWT (Central European Winter Time) or CEST (Central European Summer Time). To enable an automatic conversion, date and time values from API version 4 contain the UTC offset. This represents the deviation from UTC time. In the following example, you can see that the date specification in the timestamp field receives the addition +02:00 with API version 4. This means that the specified date value is 2 hours ahead of UTC time. Converted to UTC time, the date would thus be 2021-07-15T15:54:27.
Date and time information of PayPal transactions also contain the UTC offset. In this case, however, the time zone depends on the country settings stored in PayPal for the respective PayPal account and thus may differ from the time zones used by konfipay (CEWT/CEST).
Correction of wrong namespaces for PayPal transactions
In API version 3.1, PayPal transactions were generated in XML format with the wrong namespace
"http://schemas.datacontract.org/2004/07/LibPayPalRestClient.Models.Transactions". This has been fixed with API version 4.
File names for documents
The DocumentItem object is extended by the fileName field. The field contains the original file name. This varies with the source of the file:
Retrieval via EBICS/service data center: The file name is assigned by the bank data center.
Import via the portal: Name of the file at the time of upload.
Affected API endpoints:
Document - Camt
Document - Misc
Document - SWIFT MT
New status: FIN_CONFIRMED
Version 3.4.0 introduces the new FIN_CONFIRMED status for payment order files.
The retrieval and processing of bank-specific logs for the payment status in pain.002 format introduced with this version provides more detailed information on the status of a payment order file on the bank side. The logs are retrieved via the EBICS order types Z01, CRZ, CDZ, CIZ and XMF. In the previous process of processing payment orders, the FIN_ACCEPTED status was the last possible positive status of a payment order file. This is based on the feedback from the EBICS customer log (order type: HAC). The FIN_ACCEPTED status indicates that all steps relating to the EBICS procedure have been successfully completed, but this does not guarantee that the payment will be executed.
The new FIN_CONFIRMED status represents a clear, bank-side confirmation of the execution of the instructed payment orders. FIN_CONFIRMED thus replaces FIN_ACCEPTED as the final, positive status of a payment order file. For backward compatibility, the FIN_CONFIRMED status is returned as FIN_ACCEPTED status in API versions < 4.0.
The order types Z01, CRZ, CDZ and XML are optional and are not supported by every EBICS server. They must also be configured and released for the respective EBICS access by the bank. If these requirements are not met, FIN_ACCEPTED remains as the last possible positive status of a payment order file.