The FlexitiSDK will capture these events and it will send the response through the function handlers defined on the Widget instance creation.
| Info |
|---|
Events will be used to send data from the widget to the Merchant Front-End using the following method and structure. |
| Code Block | ||||
|---|---|---|---|---|
| ||||
window.parent.postMessage({ 'eventType': 'flx-success', 'eventData': { 'accountNumber': 2233000 / null 'verified': true / false 'action': Enum ["apply"|"purchase"|"activation"|"retry"] / null 'mfaOptionSelected': Enum [ |
...
“sms”| |
...
“email”| |
...
“security_question”] / null 'widget_session_id': GUID 'customerId': "1234567-12345" 'accountType': "business" / "consumer" } }, '*'); |
Success
‘eventType': ‘flx-success’: When the widget ends, after performing all the corresponding customer verification steps related to the flow, it will send the eventData JSON object with the following structure:
| Code Block | ||||
|---|---|---|---|---|
| ||||
'eventData': {
'accountNumber': 2233000 / null
'verified': true / false
'action': Enum [“apply”|“purchase”|“activation”] / null
'mfaOptionSelected': Enum ["apply"|"purchase"|"activation"|"retry"] / null
'widget_session_id': GUID
'customerId': "1234567-12345"
'accountType': "business" / "consumer"
} |
| Info |
|---|
Mandatory: The merchant must call the POST /apply endpoint on a successful flx-success widget response on the application flow. |
...
'eventType': ‘flx-failure’: To be used for error handling and catching exceptions, it will return the following error structure:
| Code Block | ||
|---|---|---|
| ||
{
'error':HTTP Status Code
'message': string //description of the error
} |
...
'eventType': 'flx-cancel': If the customer cancels the flow within the widget, eventData will not be sent. The merchant should handle the cancellation of the flow.
| Code Block | ||
|---|---|---|
| ||
{
'eventType': 'flx-cancel'
} |
...
Based on the application or purchase flow, there will be certain actions (“action” data) that the customer can choose which will be returned through the “flx-success” event. The Merchant can then determine the next step for the customer depending on these scenarios.
...
Purchase Scenarios
APPLY SCENARIO #1: Action = Activation
Customer has multiple accounts and chooses to activate an existing account on the account selection screen (“Continue to activate“ button). “action”=“activation”:
Where a Customer has more than one account, an account selection screen (multiple account selection screen below) is presented to the Customer with a call to action. If the customer chooses an account requiring activation, the customer will be informed to activate their account via Flexiti’s online account servicing tool, the Customer Portal (https://my.flexiti.com/index).
This action ends the widget returning the “accountNumber” in NULL and the “verified” flag is FALSE.
After the widget ends, the Merchant can open the Flexiti Customer Portal URL (https://my.flexiti.com/index) in a new tab or let the customer perform that action themselves to complete activation.
...
APPLY SCENARIO #2: Action = Apply
Customer completes a new application and Flexiti identifies the customer has an existing account. On the account selection screen the customer selects “Continue with application”
...
This action allows the customer to continue with a new application and perform the corresponding identity verification steps.
...
Description | “accountnumber” | “verified” | “action” | Implementation |
|---|---|---|---|---|
Customer attempts to make a purchase and completes verification successfully. | numeric | TRUE | purchase | After the widget ends, the Merchant |
...
should send the purchase request to the / |
...
authorizations endpoint |
...
. |
APPLY SCENARIO #3: Action = Apply
Customer completes a new application
This action allows the customer to continue with a new application and perform the corresponding identity verification steps (happy path).
This action ends the widget returning the “accountNumber” in NULL and the “verified” flag as FALSE or TRUE according to the result of the verification methods performed.
After the widget ends, the Merchant must call the /apply endpoint to complete the flow.
APPLY SCENARIO #4: Action = Null
Customer cannot proceed with an application due to derogatory status’s on an existing account. “action”=null
...
This is when a customer has an account with a derogatory status which will prevent them from continuing with the application flow. An example of a derogatory status is Fraud or Charged-Off.
...
In this case, the widget ends returning the “accountNumber” is NULL and the “verified” flag as FALSE.
Customer attempts to make a purchase and completes verification unsuccessfully. | numeric | FALSE | purchase | After the widget ends, the Merchant |
...
should inform the customer |
...
Purchase Scenarios
PURCHASE SCENARIO #1: Action = Activation
...
that they failed to make a purchase |
...
and redirect them back to the checkout to select an alternate payment method. |
Customer attempts to make a purchase with an account needing activation |
...
and selects activate on the account selection screen |
...
. |
...
...
NULL | FALSE | activation | After the widget ends, the Merchant can open the Flexiti Customer Portal URL (https://my.flexiti.com/index) in a new tab or let the customer perform that action themselves to complete activation. |
PURCHASE SCENARIO #2: Action = Apply
...
Merchant sends |
...
who’s account |
...
needs activation. They are presented with the account selection screen and |
...
choose to continue with a new application |
...
. |
...
NULL | FALSE | apply | After the widget ends, the Merchant should redirect the Customer to complete a brand new application. |
...
PURCHASE SCENARIO #3: Action = Purchase
Customer completes a new application and is presented with the account selection screen and selects “Continue to purchase”.
this is when the multiple account screen is presented for a Customer that has more than one account. Any accounts with a derogatory status will not be presented on the multiple account screen. An example of a derogatory status is Fraud or Charged-Off
This action ends the widget returning a valid “accountNumber” (the one chosen by the customer) and the “verified” flag as FALSE since no verification method was performed.
After the widget ends, the Merchant must redirect the customer to the page their consider appropriate to start a purchase within their Ecommerce (cart, check out, landing page, etc). The widget would need to be presented again to the Customer to confirm their identity.
PURCHASE SCENARIO #4: Action = Purchase
Customer is performing a purchase and is presented with the account selection screen and selects “Continue to purchase”
...
This is when the multiple account screen is presented for a Customer that has more than one account. Any accounts with a derogatory status will not be presented on the multiple account screen. An example of a derogatory status is Fraud or Charged-Off
...
This action allows the customer to continue with the purchase, performing the corresponding identity verification (happy path).
...
Customer cannot proceed with a purchase due to derogatory status’s on an existing account. | NULL | FALSE | NULL | After the widget ends, the Merchant must |
...
PURCHASE SCENARIO #5: Action = Null
...
inform the customer they cannot proceed with a purchase |
...
. |
...
This is when a customer has an account with a derogatory status which will prevent them from continuing with the purchase flow. An example of a derogatory status is Fraud or Charged-Off.
...
Customer attempts an application but there is an IT related error. | NULL | FALSE | retry | After the widget ends, the Merchant |
...
should display a message that there was an error and either retry the application or return the customer to the previous screen/step. |