Payment transaction
User group
The user group contained information about the user sending the request. It consisted of USER.LOGIN
and 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.
Identification group
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.
For instance: If you perform an authorize (formerly reservation PA
) on a credit card resource you can then easily perform a chargen (formerly capture CP
) by simply using the payments resource ID.
Transaction group
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 LIVE
.
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: | s-pub-xxxxxxxxxx |
---|---|
Sandbox private key: | s-priv-xxxxxxxxxx |
Additionally the p-
or s-
keywords are visible in every created resource, such as a payment, a payment typeor a charge / authorize:
Sandbox charge example: | s-chg-1234 |
---|---|
Production charge example: | p-chg-1234 |
Payment methods
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 sepa-direct-debit
it will contain also the IBAN and BIC of the customer. We recommend to use our Javascript UI components to create types
resources.
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 types
resource.
Here’s a mapping from payment code to types
:
Payment type | Payment code / Brand | Types |
---|---|---|
Credit Card | CC | https://api.unzer.com/v1/types/card |
Debit Card | DC | https://api.unzer.com/v1/types/card |
Direct Debit | DD | https://api.unzer.com/v1/types/sepa-direct-debit https://api.unzer.com/v1/types/sepa-direct-debit-secured |
Invoice | IV | https://api.unzer.com/v1/types/invoice https://api.unzer.com/v1/types/invoice-secured |
Unzer Prepayment | PP | https://api.unzer.com/v1/types/prepayment |
Online Transfer | OT / SOFORT OT / EPS OT / GIROPAY OT / IDEAL OT / PRZELEWY24 |
https://api.unzer.com/v1/types/sofort https://api.unzer.com/v1/types/eps https://api.unzer.com/v1/types/giropay https://api.unzer.com/v1/types/ideal https://api.unzer.com/v1/types/przelewy24 |
Paypal | VA | https://api.unzer.com/v1/types/paypal |
Transaction Types
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 (PA
).
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: | p-chg-1 |
---|
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 |
---|---|---|
Reservation | PA | https://api.unzer.com/v1/payments/authorize |
Debit | DB | https://api.unzer.com/v1/payments/charges |
Capture | CP | https://api.unzer.com/v1/payments/{id}/charges |
Reversal | RV | https://api.unzer.com/v1/payments/{id}/charges |
Refund | RF | https://api.unzer.com/v1/payments/{id}/charges/{chargeId}/cancels |
Registration | RG | https://api.unzer.com/v1/types/{type} |