Fluid Widget Integration
Integration
The Fluid Widget is implemented as a web component integrated into the host page DOM. By design, the Fluid widget script should get injected into the host site upon user authentication, followed by either:
- injecting
<fluid-widget>
web component into the DOM, providing required init attributes (Automatic Init) - calling
fluid.init
function with the init params object (Programmatic Init)
Automatic Init
This is the recommended way in most cases.
The <fluid-widget>
custom element expects several attributes required for initialisation (more on attributes here). If the required initialisation parameters are provided at injection, the widget will automatically initialise and be ready for use. This initialisation should occur once per user session, immediately after user authentication. A notification will indicate that the widget is ready for opening - it should not be allowed to open before this notification is emitted.
Once the session ends, the widget should be removed from the DOM to ensure proper shutdown.
Programmatic Init
This method is recommended if the widget is embedded in an element rendered on open, injected many times.
If your website injects the Fluid component multiple times during a user session, ensure the widget is initialised upon user authentication. To do this, call the global fluid.init
function with the necessary payload immediately after downloading the Fluid script. This function accepts an instance of the FluidInitParams type, available in the @fluidpayments/types
package. Unless it's specifically intended, fluid.init
should be called only once per user session and to update widget parameters, use the reactive attributes.
type FluidInitParams = {
operatorId: number;
userId: string;
sessionId: string;
locale: string;
countryCode: string;
currencyCode: string;
bonuses?: FluidBonusData,
userData?: FluidUserData;
transactionAttributes?: Record<string, string>;
}
Then on injecting the widget component provide only the reactive parameters, like transaction
, open
, balance
, withdrawable-balance
, bonuses
, deposit-limit
, success-cta-link
and session-id
.
Note: if bonuses
data doesn't change the widget won't process it again on inject, same with session-id
- if it's the same as provided to the init function, the widget won't re-initialise. Otherwise, if any of the required init parameters change, the widget will re-initialise itself on inject.
Warning: Only one Fluid Widget custom element should be present in the DOM, otherwise unexpected behaviour may occur.
Fluid custom element attributes in detail
Fluid widget setup expects a list of parameters to properly configure itself for an authenticated user:
operator-id
- unique identifier of the host site / operator **session-id
- up-to-date session code of the currently authenticated user **user-id
- identifier of currently authenticated user **user-data
- details of currently authenticated user of typeFluidUserData
**locale
- locale tag according to IETF BCP 47 (e.g.en-NZ
ores-MX
), withen
(default English) andar
(default Arabic) being an exception **country
- country of currently authenticated user in ISO 3166-1 Alpha-3 format **currency
- currency code according to ISO 4217 **transaction
- deposit | withdrawal | quick-depositopen
- true or falsebalance
- current user balance in given currencywithdrawable-balance
- amount available to withdrawbonuses
- stringified bonus data, structure described belowdeposit-limit
- responsible gaming deposit limitsuccess-cta-link
- link for the CTA button after a successful transactionz-index
- use a value high enough to display the wallet in front of other elements on the host siteturned-over-percentage
- percentage of the turned over amount. If none is provided the information will not be displayedtransaction-attributes
- a stringified json object of key-value pairs that will be sent to the payment provider as transaction attributes together with the user agent and bonus code (if applicable)deposit-amount
- the amount that will be pre-filled for the user in deposit. It takes precedence over the configured ones and should be unset for bringing back the default behaviour
** Mandatory for Automatic Init
The operator-id
value must correspond to the Payment Operator Config property value. This value is provided by Fluid Payments.
Observed (reactive) Attributes
The following attributes are observed by the widget and change in their value on the host site causes a reaction/event within the wallet.
open
- triggers the wallet to become visible or hiddenbalance
andwithdrawable-balance
- update withdrawal informationsession-id
- assures consistently valid user session
Other reactive attributes are observed only while the wallet is closed:
transaction
- updates transaction typebonuses
- updates bonuses informationdeposit-limit
- updates responsible gaming deposit limit amountuser-data
- updates user data for resolving Suggested Deposit Amounts, Payment Methods Order and KYC statussuccess-cta-link
- sets the link to follow on successful transactionturned-over-percentage
- sets the turned over percentage
Note that there won't be any reaction to changes of those 6 attributes while the wallet is open. This is to assure integrity of user's experience and that the transaction flow is not interrupted by any changes on the host site.
Notifications emitted by the Fluid Wallet
In addition to receiving information from the host site, the Fluid wallet emits information out to the host website using CustomEvent
(https://developer.mozilla.org/en-US/docs/Web/API/CustomEvent),
with the detail
property containing the information. This property is an object with the following structure, also available as a type in the @fluidpayments/types
package as FluidNotificationDetail
type FluidNotificationDetail = {
message: string;
[key: string]: any;
}
message
contains a string with the different event types listed below.
Add the following code to receive those events:
fluid.addEventListener('fluid-command', onFluidCommand);
fluid.addEventListener('fluid-info', onFluidInfo);
fluid.addEventListener('fluid-error', onFluidError);
fluid-info
- messages of informational nature, with the purpose of e.g. tracking or allowing user actionfluid-error
- unexpected failure notificationsfluid-command
- commands to react to
Possible values of those types can be expected to be:
fluid-info
:- initialised - wallet has been prepared for opening - it should not be allowed to open before this is emitted
- opened - the wallet has been opened
- destroyed - the wallet instance has been terminated
- internal-operation-change - transaction flow has been amended internally, e.g. upon withdrawal without a positive withdrawable balance
- success-cta-click - the user has clicked on the CTA shown on the successful deposit or withdrawal screen
- deposit-success - when a successful deposit is made
- deposit-failure - deposit attempt failed
- withdrawal-success - when a successful withdrawal is made
- withdrawal-failure - withdrawal attempt failed
- withdrawal-cancelled - when a withdrawal is cancelled
- start-kyc-verification - when the user clicks on the Verify button in the fluent message
- contact-support - when the user clicks on the Contact Support link in the failure screen
fluid-error
:- initialisation-failure - Fluid wasn’t able to configure itself, e.g. due to a network or backend issue
- operation-execution-failure - an operation failed unexpectedly due to an error
- invalid-bonus-data - the bonus data is not in the correct format expected
- invalid-user-data - the user data is not in the correct format expected
- invalid-transaction-attributes - the transaction attributes are not in the correct format expected
fluid-command
:- close - user selected to close the wallet from within, the
open
attribute should be set to false
- close - user selected to close the wallet from within, the
Note: The list above gives examples of notifications emitted by the fluid widget, it is not an exhaustive list of all notifications.
Example code
The following is an example of what's to be injected to your website DOM upon user login for Automatic Init:
<script type="module" src="https://get.fluidpayments.io/index.js"></script>
<fluid-widget
operator-id="<your operator ID>"
session-id="<authenticated user session ID>"
user-id="<authenticated user ID>"
user-data="<authenticated user details>"
locale="<locale tag>"
country="<authenticated user country>"
currency="<user currency code>"
transaction="<deposit / withdrawal / quick-deposit>"
open="<false / true>"
balance="<user current balance>"
withdrawable-balance="<user current withdrawable balance>"
bonuses="<bonus data>"
deposit-limit="<responsible gaming current deposit limit>"
success-cta-link="<link to URL/Path following successful transaction>"
z-index="<z-index value>"
transaction-attributes="<stringified json object of key-value pairs for payment provider>"
deposit-amount="<pre-filled deposit amount>"
>
</fluid-widget>
It should stay present in the DOM for the time of user session.
Initial mandatory attributes are: operator-id
, session-id
, user-id
, user-data
, country
, and locale
.
Bonus Data Object
The structure containing sample data (type of FluidBonusData
available in the @fluidpayments/types
package) is as follows:
const bonusData = [{
"code": "DepositBonus",
"title": "Deposit Bonus",
"description": "100% up to 200€ + 10 Mega Spins",
"logoUrl": "https://<operator-site>.com/assets/img/rewards/bonus-img/deposit-bonus.png",
"maxBonus": "200",
"maxBonusPercentage": "150",
"minDeposit": "10",
"selected": true,
"termsAndConditions": "Welcome Offer Terms And Conditions 1...",
"paymentMethodFilter": {
"applyTo": [
{
"providerType": "CREDITCARD"
},
{
"providerType": "WEBREDIRECT",
"service": "BLIXTPAY"
}
],
"excludeFrom": [
{
"providerType": "JETON"
}
]
}
}]
Figure 4 - Definition of Bonuses Passed to the Fluid Widget (Example)
- The
termsAndConditions
of the bonus should be provided as an HTML string. - The
logoUrl
represents the URL of the bonus image*. IflogoUrl
is absent or the path is 404, a fallback image will be used.
This fallback image has to be set from the CMS's theme. - Bonus codes will be available for all payment methods unless a
paymentMethodFilter
is specified. - If a
paymentMethodFilter
is used, the bonus is applied depending on the properties set.- If
applyTo
is set then the bonus only would apply to those listed payment methods. - If
excludeFrom
is set then the bonus won’t apply to those payment methods.
- If
providerType
is sufficient if the payment method does not have aservice
. Both values should be provided exactly as in Payment Provider configurationmaxBonus
andmaxBonusPercentage
are not mandatory.maxBonusPercentage
requires amaxBonus
value.minDeposit
is an optional property indicating the minimum deposit amount required for the bonus.- If there is a
maxBonus
but nomaxBonusPercentage
, it is assumed thatmaxBonusPercentage
is 100% (examples of bonus calculations can be found in the deposit example section). selected
is an optional property indicating the bonus should be preselected. If more than 1 bonus is set to true a bonus configuration error will be thrown.
*Bonus logo image size should be 84x84px (168px168px for retina)
User Data Object
Used for resolving Suggested Deposit Amounts and Payment Methods Order with use of Machine Learning based on historical transactions' data.
The structure, available as FluidUserData
type in the @fluidpayments/types
package, is as follows:
type FluidUserData = {
age?: number;
fullName?: string;
previousDeposit?: number;
lifetimeDeposit?: number;
kycStatus?: FluidKycStatus;
}
All the properties are optional.