Transaction Limits

Fluid Widget	Quick Deposit	Sweepstakes (Virtual)
Yes	Deposit only	Yes

The transaction-limits attribute lets you cap how much a player can deposit or withdraw, and lets you supply your own message for when they try to exceed it. On the Sweepstakes widget the same attribute caps purchases and redemptions.

The limit carries no time period meaning on our side. You decide what it represents, whether that is a daily allowance, a per session cap or a remaining balance of some entitlement, and you keep the value current. Our only job is to compare it against every other limit that applies and enforce the smallest.

The attribute value is a JSON string with the following shape:

type TransactionLimits = {
	deposit?: {
		limit: number; // required within the entry
		'warning-message'?: string; // optional; shown when the player exceeds the limit
	};
	withdrawal?: {
		limit: number;
		'warning-message'?: string;
	};
};

Both entries are optional and are evaluated completely independently, so you can cap one transaction type and leave the other alone.

Field rules

• limit is required within an entry. An entry that carries only a warning-message is ignored entirely: nothing is enforced and nothing is shown.
• warning-message is optional. When you omit it, the limit is still enforced and the player sees the standard "amount above the maximum" message, which you edit under Content in the back office.
• warning-message replaces the body of the message only. The heading stays the one you have configured, so your copy reads in context with the rest of the cashier.
• A limit of 0 stops the transaction type for that player, the same way a deposit-limit of 0 does today. Your warning-message is used on that screen too, so you can explain why the transaction type is unavailable.
• Values must be JSON numbers, so they take a dot and no digit grouping whatever the player's locale: "limit": 1500.5, never "limit": "1.500,50".
• If the attribute value is not valid JSON, the widget emits an invalid-transaction-limits fluid-error event and keeps the limits it already had, so a momentary serialisation bug on your side cannot quietly lift a cap. Anything else we cannot read, such as a limit that is not a number, is reported through the same event while the rest of the payload still applies.

How the limit is enforced

For each transaction type we take the smallest of your limit and every other maximum that applies, which includes the payment method maximum, any bonus maximum and any verification ceiling. The result becomes the maximum the amount field accepts, so the displayed maximum, the validation and the transaction button all agree.

When the player enters an amount above that maximum, the button stays disabled and the message appears in the usual place for an amount that is out of range. Your warning-message is used only when your own limit is the one being applied. If another maximum is lower, that limit's own message is shown instead, because telling the player about your cap would send them to the wrong place. On a deposit, an exact tie counts as yours.

Both limits are always expressed in your fiat currency, never in a virtual one. On the Sweepstakes widget the deposit limit is compared against the fiat price of the pack the player is buying, and the withdrawal limit against the fiat value of the redemption, which we convert before comparing.

Relationship to deposit-limit

The older deposit-limit attribute continues to work exactly as it does today, so no change is required on your side. It is deprecated: use transaction-limits in a new integration.

If you send both, the stricter of the two applies. That is deliberate: it means a stale deposit-limit left behind on the page can never raise a cap you have lowered through transaction-limits. When you migrate, remove deposit-limit once transaction-limits carries the value, so there is only one number to keep current. While both are set and deposit-limit is the stricter one, your warning-message is not shown, because it would describe a cap that is not the one being applied.

Reactivity

transaction-limits is observed while the cashier is closed, in the same group as deposit-limit. Updating it while the cashier is open leaves the current transaction alone, and the new limits take effect the next time it opens. That is what keeps a player from having an amount rejected mid flow by a value that changed under them.

On the inline <fluid-quick-deposit>, which is always visible, the deposit limit applies as soon as you change the attribute.

Mounting more than one element

Set transaction-limits on every Fluid element you mount on the page, with the same value. A limit is a property of the player rather than of one cashier surface, so we track a single current value for the session. If you set a cap on one element and leave it off another, the element without it clears the cap when it next opens, and the player is no longer capped. The same applies to deposit-limit.

Examples

The value is a JSON string, so an object has to be stringified before it reaches the attribute. The examples below wrap it in single quotes because the JSON itself uses double quotes. An apostrophe inside your warning-message would then close the attribute early, so write it as ' in static HTML, or set the attribute from JavaScript and let JSON.stringify handle the quoting:

element.setAttribute('transaction-limits', JSON.stringify({
	deposit: { limit: 500, 'warning-message': "You've reached your daily deposit limit." }
}));

A deposit cap with your own message:

<fluid-widget
	transaction-limits='{"deposit":{"limit":500,"warning-message":"You have reached your daily deposit limit. Visit your account settings to review it."}}'
	...
>
</fluid-widget>

Both types capped, with a message on the redemption only:

<fluid-virtual
	transaction-limits='{"deposit":{"limit":500},"withdrawal":{"limit":200,"warning-message":"You can redeem up to 200 per day."}}'
	...
>
</fluid-virtual>

The related events are listed in the Events and errors catalogue.