Introduction

FlexCharge allows customers who experience a payment decline to complete their purchase, via a real-time, frictionless experience.

Customers don't need to leave the store or create an account. Eligible transactions are taken care of by FlexCharge, requiring little and in most cases no interaction from the customer.

For Customer Initiated Transactions (CIT), the high-level process is as follows:

1. The customer proceeds to check out and provides their details and payment info. If the payment transaction is accepted, FlexCharge remains invisible.
2. If the customer payment transaction is declined, FlexCharge is invoked. The customer is not informed of the declined payment and FlexCharge assesses the transaction within a couple of seconds. If the transaction is not eligible, our service responds with a decline. The customer in this case is shown the usual payment decline message. If the transaction is eligible, our service responds with a session key, used to activate our UI widget. This might trigger our UI to request some additional info from the customer. Most times however this is not required and the customer experience is completely frictionless.
3. Payment transaction is confirmed by FlexCharge. This confirmation is notified via the webhook and is also available via API. Since most of FlexCharge orders do not require any customer interaction, in most cases the customer's experience is completely frictionless.

For Merchant Initiated Transactions (MIT) there is no real-time interaction with the customer and the process takes place behind the scenes.

User Experience

Customer Initiated Transactions

To visualize the CIT customer experience, you can try it yourself with our demo shop

For this use case there are 3 possible scenarios:

Scenario 1: Frictionless rescue

Under this scenario, FlexCharge rescues the payment transaction without asking for any customer interaction. Customers are just informed that their order was successful and are redirected to the success screen of the merchant.

Scenario 2: Rescue requiring some user interaction

Under this scenario, FlexCharge needs to interact with the customer and ask for some additional information. For example, if the CVV provided by the customer was wrong, we would ask for the CVV again.

Scenario 3: Payment transaction is declined by FlexCharge

Under this scenario, the declined transaction sent to FlexCharge is considered not eligible for our service. In this case the decline is confirmed by FlexCharge and the customer is redirected to the decline screen of the merchant.

Merchant Initiated Transactions

For the MIT use case, most of the time there is no interaction required but, depending on the decline error, we might contact the customer via email or SMS inviting them to provide an alternative payment method.