Payments in a nutshell
Learn about payments and the different use cases.
When it comes to payment, the very 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 present to authenticate themselves and authorize the transaction. Based on the used payment method this authentication can differ.
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 as well as finally decide whether they want to keep it.
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.
In most cases, initially the customer is directly initiates the payment directly. These transactions are called Customer Initiated Transaction (CIT). From their perspective, the full payment is done while the progress bar is loading and is finished 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).
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.
Contrary to CITs, there are transactions which are triggered by the merchant himself. 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 subsequent transactions.
The merchant triggers the transactions in the background to handle these scenarios:
- scheduled payments (COF, subscriptions/recurring)
- unscheduled subsequent payments (UCOF, additional top up)
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.
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.
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
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
authorize call. The
charge needs to be triggered once the content or service has been delivered or the goods have been sent out. For partial deliveries a partial
charge of the respective amount needs to be executed.
Confirm the amount to be reserved
Charge the appropriate amount at a later stage based on the previous Authorization
Unzer Invoice Secured and Unzer Instalment mainly use the two-step approach but there is an additional
shipment API that is used for charging the payment amount. For more details on each payment method, see Unzer Invoice Secured and Unzer Instalment.