Location-Based Price Exceptions (LBPE) is a legacy pricing feature designed for specific, limited use cases. While it remains available for customers currently relying on it, the feature has known limitations in terms of scalability and operational robustness.
We are aware there is currently no alternative pricing rules to implement LBPE’s supported use cases. Nevertheless, at the moment, we are focusing on revamping our more standard pricing options, namely initiating development towards API based tariff management, so we won’t pursue these advanced features for the foreseeable future.
Typical Use Case
LBPE is most commonly used in semi-private charging scenarios. These setups typically apply when a location owner is allowed to charge at a reduced rate - or at no cost - compared to the standard roaming tariff.
In this model, the CPO configures:
- A regular roaming tariff for third-party eMSP users
- An ad-hoc tariff for unregistered users (for example, via QR-code based charging)
- A specific exception tariff for private or semi-private users, such as the location owner or a closed user group → aka Location Based Price Exceptions.
This allows differentiated pricing at a certain location, for a given set of tokens.
How to setup these tariff exceptions?
Location Based Price Exceptions (LBPE), as the name indicates, enables CPO operators in GreenFlux platform to define exceptional pricing for a given set of location and tokens. The way the feature works, users must always define both 1 and 2:
- one or more locations and
- either:
- one or more (eMSP) customers (set of drivers, which contains a set of tokens) and/or
- one or more (eMSP) tokens
The fundamental design principle is that when setting these LBPE rules, we must clearly set the scope for a combination of location(s) and token(s).
Main feature gaps
While LBPE supports specific pricing exceptions, it was not designed for large-scale or frequently changing configurations. As a result, customers should be aware of the following limitations:
- Lack of scalability:
- Updating LBPE rules requires expiring and recreating existing rules, which increases operational effort and the risk of configuration errors.
- The user interface offers limited filtering and visibility, making it challenging to manage a high number of rules efficiently.
- LBPE rules are tied to tariff codes, meaning any tariff change in chargers requires recreating all related LBPE rules.
- Lack of reliability:
- Validation of overlapping or conflicting billing rules is limited, which may lead to ambiguous pricing outcomes and flagged charge detail records (CDRs).
- For external tokens, pricing cannot be guaranteed: tariffs (e.g. 0.40 €/kwh) shared via the tariffs module do not reflect LBPE exceptions, and OCPI does not support this concept. This has led to cases where drivers were charged differently than intended. Current roaming protocols do not foresee to exchange tariffs with such granularity with eMSPs, thus it is out of scope to pursue this capability in the foreseeable future.
- Usability barriers:
- This feature is difficult to understand and use effectively.
- Impact on future improvements
- Keeping this feature active increases complexity for future tariff management improvements. Freezing it limits further adoption and reduces future migration effort.
Mapping of external tokens:
Utilization of this capability while mapping external tokens (tokens from external roaming partners) remains possible for some customers, but it’s provided at the customer’s own risk when it does not work properly. This utilization is subject to access restrictions mentioned at the bottom.
Feature availability
Setting up LBPE tariff rules is only available in some tenants.
(Limited to GreenFlux staff only)
Check this feature’s availability here: link