Customer Initiated Transactions (CIT)

CIT are transactions happening on a checkout page (e.g.: straight sales or initials).

Flow

1. The customer proceeds to check out and provides their details and payment info. If the payment transaction is accepted, FlexFactor remains invisible.
2. If the customer payment transaction is declined, FlexFactor is invoked. The customer is not informed of the declined payment and Flex 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, the transaction is approved in real time with no cardholder interaction — the default CIT experience is fully invisible. As an optional capability available on request, the response can instead include a session key used to activate our UI widget, which may ask the customer for additional information (see Scenario 2 below).
3. Payment transaction is confirmed by FlexFactor. This confirmation is notified via the webhook and is also available via API. By default, the customer experience is completely frictionless — the transaction approves or declines in real time with no customer interaction.

User Experience

Try it on the Demo Shop

To visualize the CIT customer experience on the checkout page, you can try it yourself on the Demo Shop. Replace the placeholders with your own sandbox credentials from the Merchant Portal.

Scenario 1 - Frictionless rescue: no user interaction required

Under this scenario, FlexFactor 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

The challenge flow and UI Widget are an optional capability, available on request — they are not part of the default CIT experience. This flow corresponds to a CHALLENGE response from /v1/evaluate. When the integration embeds the FlexFactor UI Widget, the widget handles the customer interaction; when the widget is not embedded, treat CHALLENGE as a decline.

Under this scenario, FlexFactor 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 FlexFactor

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

Merchant Initiated Transactions (MIT)

MIT are transactions where the merchant initiates the payment on behalf of the customer, without the customer actively participating in the transaction (e.g.: recurring subscriptions).

Flow

On a decline of a recurring payment, transaction is sent over to FlexFactor for a period of time.

During this period, FlexFactor will send status update notifications via webhook:

• APPROVED: transaction was rescued by FlexFactor
• EXPIRED: FlexFactor wasn't able to rescue this transaction during the expiry date.
• CANCELLED: the transaction was declined and will not be rescued (notified via the order.cancelled webhook).

Make sure your integration handles all three terminal outcomes.

User Experience

For the MIT use case, the rescue happens entirely in the background: no customer interaction is required and FlexFactor does not contact the cardholder. As an optional capability, FlexFactor can enable cardholder outreach for your account — contacting the customer via email or SMS to invite them to provide an alternative payment method. Reach out to your FlexFactor representative if you would like to enable this.