Response codes

Introduction

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.

Codes vs Resources

Down below are comparisons between the old and the new API in regards to the aforementioned codes.

Method code vs payment type

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 types resource-ID:

Type resource-ID example (credit card): p-crd-wln5j3zcmjzi

Status & reason code

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: isSuccess, isPending and isError. 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.

Payment code

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.

Processing code

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.