OneClick Payment

How OneClick payment works and what it is actually good for

OneClick payment allows regular customers to pay significantly more conveniently and faster. At the first (registration) payment, the customer gives permission to perform subsequent payments and completes the payment in the standard way (redirection to the payment gateway, entering the card number, validity, CVC, payment authentication using 3D Secure). With each subsequent payment, the customer just says that they want to use the card from the previous purchase. Communication with the payment gateway takes place in the background without the need to re-enter the card number which is stored on the payment gateway.

The OneClick payment function is not universally accessible, it must be enabled by ČSOB for a specific merchant. The settings distinguish between a subsequent payment (1) up to the amount of the first (registration) payment, or (2) in any amount. The default setting limits subsequent payments to the amount of the first payment. When activating the service, please request the settings that correspond to the method of using OneClick payment in your e-shop.

Create a OneClick payment template  

The initial payment is very similar to a regular card payment at the payment gateway. The only difference is that in the e-shop the customer chooses to store the card for the next payment. It is absolutely necessary to obtain this consent and at the same time it is not allowed to hide the consent - the consent must always take place by active customer selection ("check boxes checked by default" are not allowed). After obtaining approval, you indicate to the payment gateway when creating the payment that you want to create a template for OneClick payment (see also the API documentation of the payment/init). If this initial payment is successfully authorised, the payment gateway creates a template, which it identifies using the payID of the initial payment.

Use a OneClick payment template to make payments without redirecting to the payment gateway and without entering a card number  

If the customer wants to pay the next time they visit the e-shop, the merchant offers OneClick payment saved by card. The customer selects this option and the merchant requests the use of the customer's OneClick payment template at the payment gateway (in the e-shop, the template must always be linked to a specific customer account). The oneclick/init refers to the payID of the payment template and requests payment with the amount of the customer's current purchase.

Authenticating OneClick payments  

Theobligation to authenticate the card payments also applies to OneClick payments. The initial OneClick payment will always be authenticated with customer's confirmation. For the subsequent OneClick payments, which take place without redirection to the payment gateway (only in the e-shop environment), the merchant must distinguish between two types:

Payments in the presence of the customer (“Customer Initiated Payment”)  

Payment in the presence of a customer is the most typical use of OneClick payment. The customer normally makes a purchase in the e-shop (is "present") and the OneClick payment is used to speed up the payment. Such payment must be authenticated according to the legislation.

Payments without the customer's presence (“Merchant Initiated Payment”)  

Payment without the customer's presence takes place on the basis of an agreement between the merchant and the customer that the same or different amounts will be regularly or irregularly deducted from their card. It can be, for example, a subscription payment or a payment in a taxi application, where the final price is calculated without the customer's presence. Such payment does not have to be authenticated.

The authentication process of the subsequent payments in the presence of the customer  

OneClick payment can be authenticated both with confirmation by the customer or - in less risky situations - without confirmation by the customer, while in this case the authentication is ensured by the behavioural risk model of the card issuer. These two variants differ significantly in the context of OneClick payment in terms of payment comfort. In the case of authentication without confirmation, the entire payment processing takes place in the background and in the e-shop, the customer sees nothing but information about the ongoing payment. If the card issuer requests authentication with a confirmation during the payment, the e-shop must display the customer's authentication page and the customer must confirm the payment, for example in his bank's mobile application.

The payment process at the payment gateway reflects both variants:

• Step 1: create payment - the merchant creates the payment (oneclick/init), selects whether the payment is in the presence of the customer or without the presence of the customer and sends additional purchase data to the payment gateway
• Step 2: the payment gateway confirms the creation of the payment and assigns payID
• Step 3: merchant starts processing OneClick payment (oneclick/process)
• Step 4: the payment gateway informs about the result of the payment (in case of authentication without confirmation), or passes a link to the authentication page of the card issuer
• Step 5: (for authentication with confirmation only) the merchant opens the authentication page, the customer confirms
• Step 6: (for authentication with confirmation only) the merchant checks the status of the payment (payment/status) until the payment is confirmed or declined

Authentication without confirmation OneClick payment significantly simplifies the payment and increases the comfort of payment. Therefore, we recommend transmitting to the payment gateway as much as possible purchase metadata, according to which the card issuer can assess the payment risks and verify as many payments as possible without requiring the customer's confirmation.

Authentication in iOS / Android mobile applications and the use of SDK  

For OneClick payments in native mobile applications, it is possible to use the mobile SDK, which is globally technically standardised by EMV platform. This SDK collects technical data about the user's device (for card issuer risk analysis) and displays the card issuer's Authentication page in case of authentication with confirmation. SDK is not tied to the payment gateway, so you can use any EMV-certified SDK. You can find a list of their providers in this list. ČSOB works with NetCetera's mobile SDK - if you are interested in it, please contact akceptacekaret@csob.cz. For the transmission of SDK outputs and the acquisition of SDK parameters from the payment gateway, see technical specification of OneClick payments.

When does OneClick payment end or is cancelled?  

Although the customer does not have the option to cancel the consent to authorise OneClick payments through their card issuer, there are several situations in which OneClick payment is no longer possible:

1. The registration payment was not completed successfully - if the initial payment is not verified, authorised and does not go through complete clearing, it cannot be considered as a registration payment for OneClick payment. If you use manual closing of a payment (including closing for a lower amount), don't forget to close the payment.

2. More than 13 months have passed since the last OneClick payment.

3. The card registered for OneClick payment has expired.

4. The initial payment (or any payment from the subsequent series) has been disputed by the customer or his card issuing bank (by a complaint process, so-called chargeback) and the issuer systematically rejects all further payments.

5. The customer has had the card cancelled or transferred to his issuer.

Checking the status of a payment template  

You can use the oneclick/echo operation to check the status of the OneClick payment template. You can use this operation to make sure that the template can be used before offering OneClick payment. If the template is not applicable, do not offer OneClick payment. Explain to the customer that a payment with a previously saved card is no longer possible and offer to save a new card. This prevents an unnecessary payment decline and increases the probability that the customer will save a new card.

The second example of use is to find out the status of the template when displaying stored cards in the customer's account. Depending on the result of the oneclick/echo operation, you can graphically distinguish between active and inactive templates in the view. For the inactive, it is possible to offer an exchange for another card using a crown registration payment.

Recommendations for OneClick payment solutions  

1. Always obtain the customer's consent to make OneClick payments before the payment, not after it. The customer's consent to the creation of the OneClick payment template is required for the correct payment gateway call. In addition, you have a better chance that the customer will deal with your request before the payment (than after the payment when everything is done and the customer learns at the payment gateway how the payment turned out).

2. Explain to the customer how OneClick payment will be good for him and emphasise that the data is stored by the bank, not by the e-shop. Always tailor the explanation to the context of your business. The value of OneClick payment is different when ordering fast delivery than when buying a refrigerator.

3. Use OneClick payment actively on mobile websites and mobile applications. The value of the OneClick payment function is even higher on the mobile channel than on the desktop as it removes one of the biggest barriers to m-commerce from the customer's point of view - inconvenient payment.

4. If OneClick payment is not processed, explain to the customer what is happening and guide him to the alternative. According to the return code, tell the customer whether his payment was declined (and the reason) or inform the customer that the previously saved card is no longer available (see the reasons above). If a card is not available for OneClick payment, offer the customer the creation of a new one and try to keep them active within the OneClick payment scheme.