Important information

The API reference is now available here.
The deprecated API reference is available here.


Payments in a nutshell

Learn about payments and the different use cases.

When it comes to payments, the first differentiation is ecommerce (card not present) vs. Point-Of-Sale (POS, card present) vs. Mail Order/Telephone Order (MOTO).

Although the payment instrument is not physically present for the merchant, when it comes to online transactions, the customer is at least initially virtually present (through their device) to authenticate themselves and authorize the transaction. Based on the used payment method, this authentication can differ.

Ecommerce: From buying shoes to booking a flight

Payment is a means to an end: A customer wants to buy a good (product or service) from a merchant and the merchant receives money in return. In retail ecommerce, this also means that the product needs to be packed, shipped, and delivered. The customer should check the quality and decide whether they want to keep the goods.

For digital services, the delivery of product can be immediate, for other industries such as travel, the time period between booking and receiving the service can be quite long.

You can use various payment methods to fulfil these use case requirements.

Who is initiating the payment?


In most cases, the customer is directly initiating the payment. These transactions are called Customer Initiated Transaction (CIT). From the customer’s perspective, the full payment is executed while the progress bar is loading and is completed with the confirmation page. However, in the backend the merchant needs to decide whether it should be a one-step process or a two-step process, where the actual capture of the funds (charge) will be processed immediately or at a later stage (for example, when the product is shipped).

Customer initiated Transactions (CIT)

CITs are initiated by the customer who is in session and wants to pay for the ordered goods, digital content, or services. The customer is either triggering one of the following scenarios:

  • (a single) one-off payment
  • an initial transaction by entering the payment data (Initial payment)
  • a subsequent transaction selecting the stored payment method (One-click payment)

A CIT initial transaction is a precondition for the subsequent transactions because the payment data needs to be entered by the customer which then generates a token that can be used to trigger further transactions on a later stage.

Merchant initiated Transactions (MIT)

Contrary to CITs, there are transactions which are triggered by the merchants themselves. To do so, the merchant stores a token created out of the initial transaction. This token is linked to the respective customer data and will be referenced for all the subsequent transactions.

The merchant triggers the transactions in the background to handle these scenarios:

The following MITs are further scenarios to manage already placed orders:

Go to the individual page to understand all scenarios in a detail and its supported payment methods.

What is the right request flow?

The right request flow is defined by two aspects:

  • The payment method that you want to offer.
  • When do you want to charge money from the customer.

All payment methods support the one-step approach where the customer is charged immediately. Only a few payment methods support the two-step approach where the customer is charged in a separate step after the order placement.

One-Step: Authorization and charge in one request

Once the customer pays with their chosen payment method, the respective card, bank account, or wallet is charged immediately based on the previous online reservation of the amount. In the Unzer API this is realized through charge call.


Confirm the amount to be reserved and charged immediately 1 step workflow

Supported payment methods

All payment methods

Two-Step: Authorization and charge in two requests

There are cases in which a customer provides payment method details but is not charged immediately: for example, if the shipment is delayed or when the service is provided some days later.

The respective payment method is not charged immediately. The funds are reserved and can be charged in a separate request later. Funds reservation is achieved through the authorize call. The charge needs to be triggered once the content or service is delivered or the goods are sent out. For partial deliveries, a partial charge of the respective amount needs to be executed.

1. Authorize

Confirm the amount to be reserved.

2. Charge

Charge the appropriate amount at a later stage based on the previous Authorization

2 step workflow

Supported payment methods