Transaction Limits

Fluid Cashier	Quick Deposit	Fluid Sweepstakes
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 Fluid Sweepstakes the same attribute caps purchases and redemptions.

The limit carries no time period 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. Fluid compares it against every other limit that applies and enforces 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 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 in Content Sets 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. 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 that can’t be 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, Fluid takes the smallest of your limit and every other maximum that applies, including 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 where an out-of-range amount is normally reported. 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 Fluid Sweepstakes 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 is converted before comparing.

Relationship to deposit-limit

The older deposit-limit attribute keeps working, 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 way a stale deposit-limit left 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, like 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. This 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 belongs to the player rather than to one cashier surface, so Fluid tracks 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 HTML 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 Events & Errors.