Previously codes were used for all sorts of things like payment methods, types, processing and risk management methods. All codes were given within the
code attribute and followed by a specific scheme of alphanumerical letters and numbers.
In the new API there is no need to use or memorize different, hard to read codes. Instead, there are resources put in place to represent all necessary information in a much more accessible and readable way.
Down below are comparisons between the old and the new API in regards to the aforementioned codes.
Note: All resource IDs across the new API are only unique in the scope of the keypair they were generated with!
They are not unique across multiple keypairs.
The old payment platform of Unzer supported various payment methods and identified each one by a two letter code in the form of
AA. The new API supports even more payment methods and distinguishes them by so called payment type resources. These resources have a unique resource-ID called the
typeId which can be use do to identify or reference a specific payment method.
You can find a list of all supported payment methods and a detailed explanation to every single one here - additionally there are code samples in the API reference. Here is an example of a credit card
|Type resource-ID example (credit card):||
Where the old payment platform put it’s status and reason code, the new API provides you with more descriptive status, reason and information. The codes consisted of 2 separate numbers and were in the form of
00. They were meant to give a more specific idea about a payments status. When paired together, the status and reason code categorized the error codes.
The new API however gives far more information on the status or the error of a certain operation or transaction. When performing a charge or authorize you receive 3 different status flags, amongst other things:
In case of a success there is an additional message with a general code and a short description of the operation.
In case of an error an error code and 2 separate message get returned: A merchant message with a description of what went wrong and a customer message which gets displayed to the customer. Simply take a look at some of the authorize or charge response examples.
The payment code is simply the method and type code concatenated, therefore becoming obsolete in light of all already existing calls in the new API.
Due to the fact the processing code ist created through concatenation of the method, type, status and reason code (which are implemented in a different way in the new API) it too becomes obsolete. In the new API you will use the according URL to specify what action should be executed.