Skip to main content
The GEFT widget triggers events based on authentication responses and different steps that the user completes within the payment flow. We recommend adding an Event Listener to your GEFT widget integration to track your users’ progress and improve their overall experience. As a user progresses through the guaranteed payment flow, you’ll be notified of all successful (and unsuccessful) attempts to complete a payment. When a user fails to complete the flow successfully, you can review the data from the Event Listener and determine exactly what happened to prevent the same issue from occurring again. For more information about what you can receive from the Event Listener, refer to Reviewing your Event Listener data.

Add the Event Listener to your Integration

To add the Event Listener to your GEFT widget integration, place the following script on the same page as your GEFT widget:
html

React Native WebView

When the GEFT widget is loaded as the top-level page of a React Native WebView, add webview=true to the URL:
Events are emitted to window.ReactNativeWebView.postMessage instead of window.postMessage, so handle them in the WebView’s onMessage handler rather than a message listener. Each event arrives as a JSON string. The events and their order are unchanged from the web.
window.ReactNativeWebView is injected into the main frame only, so the widget must be the WebView’s top-level page and not nested in an iframe.

Reviewing your Event Listener data

You’ll receive the following types of event data from the GEFT widget:
  • A JavaScript event, which indicates a user event during the payment flow
  • Widget state changes, which indicate progress through the guarantee process
Read the lists below for information on what sorts of event data you can receive for user events and widget state changes. We will notify you of the following user events in the GEFT widget:

Institution Selection

Credential

Aggregation Errors

These problems reach you in two different shapes. Two are step events - the payment flow reporting the customer’s progress through their sign-in attempts: RETRY_COUNT (which attempt they’re on, sent earlier during sign-in) and MAXIMUM_RETRY_REACHED (they’ve used them all up). Both arrive on the event’s step field. Everything else here is a flinksCode, a standardized reason code, shared across Flinks, for why the bank turned the sign-in away, delivered on the flinksCode field instead. In short: read step for the two progress signals, and flinksCode for every other problem in this list.

MFA

Account Selector

Deposit

Next Best Offer (NBO)

Guarantee & Review

Errors

Event Examples

Flow Events

APP_INITIATED
INSTITUTION_SELECTED
SUBMIT_CREDENTIAL
ACCOUNT_SELECTED

Guarantee Events

GUARANTEE_OFFERED
PAYMENT_FAILED (Terminating)

Terminal Events

SUCCESS (Terminating)

Implementation Examples

Basic Event Handling

Error Handling and Timeouts

Event Flow Examples

Successful Payment Flow

  1. APP_INITIATED - Payment flow initiated
  2. INSTITUTION_SELECTED - User selects their bank
  3. SUBMIT_CREDENTIAL - User enters bank credentials
  4. SUBMIT_MFA - User completes multi-factor authentication (if required)
  5. ACCOUNT_SELECTED - User selects the account for payment
  6. COMPONENT_DEPOSIT_CONTINUE - User confirms payment amount
  7. GUARANTEE_OFFERED - Flinks approves the guarantee
  8. COMPONENT_PAD_DOWNLOADED - User signs PAD agreement
  9. SUCCESS - Payment completed successfully

Guarantee Declined Flow

  1. APP_INITIATED - Payment flow initiated
  2. INSTITUTION_SELECTED - User selects their bank
  3. SUBMIT_CREDENTIAL - User enters bank credentials
  4. ACCOUNT_SELECTED - User selects account
  5. COMPONENT_DEPOSIT_CONTINUE - User confirms amount
  6. PAYMENT_FAILED - Flinks cannot guarantee the payment
  7. COMPONENT_OTHER_FUNDING_OPTIONS_SELECTED - User chooses alternative methods

Testing Event Handling

During development, test event handling with all scenarios in the sandbox environment. Use the test cases provided in the Sandbox Guide to verify proper event handling for both successful and failed flows. Test the following scenarios:
  • Happy path: Complete successful payment flow
  • Guarantee failure: Handle declined guarantees gracefully
  • User abandonment: Handle when users close the widget
  • Network issues: Handle timeouts and connectivity problems
  • PAD decline: Handle when users don’t accept the agreement