The user group contained information about the user sending the request. It consisted of
USER.PWD. In the new API parameters like these become obsolete. The authentication process and the associated user are all included inside the keypair.
In other words: A keypair contains all necessary information and configuration for a specific merchant and is tied to said merchant.
The identification group consisted of all IDs used for identification of a transaction. Beside the unique and short ID, the others (namely the transactionId, shopperId and invoiceId) could be set by the merchant. The referenceId was required for payments which referenced a former transaction. The new API supports all of that functionality and makes it easy for you to use it. Although unique and short ID are still in use, they aren’t necessary to uniquely identify a specific transaction anymore. Furthermore the referenceId becomes obsolete due to the nature of resource oriented approach the new API takes - by putting different resources inside each other they automatically get tied together.
If you wanted to distinguish between a test and live system, you had to specify that by setting the appropriate parameter for the
TRANSACTION.MODE, for instance you could set it to
With the new API it’s even easier to set the transaction mode. Your keypair will either support live or test transactions. By either putting
p- (for production) or
s- (for sandbox) in front of both the public and the private key, you determine the transaction mode to be used.
Here’s a quick example of a sandbox keypair:
|Sandbox public key:||
|Sandbox private key:||
|Sandbox charge example:||
|Production charge example:||
In the old API the payment methods are identified by a two letter code. Within the new API we use
types resources instead of the two letter code. The payment type not only identifies the payment option but also contains the data for the type. So in case of a
In the past you also had to specify a brand to differentiate between different payment methods. Sometimes you also had to use different channels. This is all obsolete in the new API. You just need to create a
Here’s a mapping from payment code to
|Payment type||Payment code / Brand||Types|
|Online Transfer||OT / SOFORT
OT / EPS
OT / GIROPAY
OT / IDEAL
OT / PRZELEWY24
The type code used to identify the specific payment activity performed on the payment method. For instance a debit (
DB) on a credit card. A few other previously supported transaction types include credit (
CD), reversal (
RV) and reservation (
The new API is capable of all of that as well, but in a much easier and more readable way. Instead of concatenating different codes to create a fully valid API call, you can simply call an authorize (previously reservation) or a charge (previously debit) on a specific payment type resource (previously method code). In addition to that, all authorize and charge calls have a unique resource-ID as well.
|Charge resource-ID example:||
The difference in the new API is that the charge id is only unqiue within a payment. The following table explains the mapping from transaction type to payment resource URL’s:
|Transaction type||Old API Code||Payment resource URL|