Customer Groups (beta)

A customer group defines who is charging. Charging policy tariff rules reference customer groups through customerGroupIds: a rule with an empty list applies to every token, and a rule naming one or more groups applies only when the presented token matches at least one filter of at least one of those groups.

A group holds one or more filters, each a type plus a list of values:

INTERNAL_TOKEN, ACCOUNT, USER and TOKEN_BILLING_PLAN match on ids the platform issues, so their values must be UUIDs and anything else is rejected on create and update. This is deliberate: authorisation compares the values to ids with an exact string match, so a card uid pasted into an INTERNAL_TOKEN filter would otherwise be stored happily and simply never match.

Which filter applies depends on how the token is authorised, and the two paths do not overlap: an internal token is only ever matched by an INTERNAL_TOKEN filter (its card UID is not compared against UID filters), while a roaming token is matched by all of the other types and never by INTERNAL_TOKEN. ACCOUNT, USER and TOKEN_BILLING_PLAN additionally require the token to be known to Road. UNSPECIFIED is a placeholder and must not be used. Ad-hoc payment (scan-to-pay, tap-to-pay) carries no token identity at all, so a tariff rule that names any customer group is skipped for those sessions.

This API is in preview. It is functional and safe to build against, but breaking changes may still occur; any breaking change is announced in advance.