Skip to main content
Token PUSH, token whitelist type, real-time authorization, contract ID limitations, tokenType limitations and token issuer behavior in Roam OCPI.

​
Tokens module adjustments

​
Token whitelist type

Whitelist types per token can be shared as per OCPI specifications. Whitelist types NEVER and ALLOWED_OFFLINE will be forwarded to the CPOs, while whitelist types ALWAYS and ALLOWED will be overwritten with ALLOWED_OFFLINE when they are shared with the CPOs. The reason for this is to avoid the risk of tokens being whitelisted at CPOs in case of later migrations or miscommunication. The token whitelist types define the behaviour of real-time authorization and session allowance between Plugsurfing and the CPO, while the real-time authorization flow between Plugsurfing and you is managed through an organization setting in Plugsurfing Power Portal.

​
Real-time authorisation

Real-time authorisation can be configured for your organization in Plugsurfing Power Portal. When enabling real-time authorization, you can also decide on the timeout and the behaviour in case of timeout or malformed response (accept/deny).
  • Real-time authorization (Enabled / Disabled)
  • Timeout (1-10 seconds)
  • Allow session on communication failure or timeout? (Yes / No)
The real-time authorization is decoupled from the whitelist type of the tokens. The configuration is done for the organization, and is not based on a token setting. To enforce the behaviour of OCPI whitelist NEVER on all your tokens you should set up the config so that real-time auth is enabled and sessions are denied on communication failure or timeout. If you want the behavior as per OCPI whitelist ALLOWED_OFFLINE, the configuration should be to allow sessions on failure/timeout. In case you don’t want real-time authorization from Plugsurfing to you, the setting can be disabled. If real-time authorisation is enabled, Plugsurfing sends through each authorisation request received from the CPOs after conducting some primary checks.
  • Step 1: Internal Validation - perform standard checks:
    • Location within supported countries (based on existing location reference)
    • Key enabled/disabled
  • Step 2: Forwarding to EMP - If the internal checks pass, Plugsurfing forwards the request to you for real-time authorization.
Please note that not all CPOs perform real-time authorization and that not all CPOs who do real-time authorization do it for all their sessions. Whitelist type NEVER will enforce real-time authorization at all times between the CPO and Plugsurfing. Further, not all real-time authorizations include a location reference.

​
Multiple keys per contract_id

Your organization can be set up to either support just one key per contract_id or multiple keys per contract_id. The default value is one key per contract_id, and if you support multiple keys per contract_id and want the setting enabled, you should know that there are a few limitations to the solution:
  • Restriction of maximum 25 tokens per contract ID. The reason for the limit is because of a limit/risk with OCPI 2.1.1 connections with CPO partners. If such partner just sends us just a CDR (for a local start), we will not be able to identify exactly which charging key performed the charge. In such case we will pick the first key matching the contract ID in the CDR.
  • To clarify that the session was conducted where there is uncertainty of whether we share the correct charging key or not, a header X-Original-Protocol is available for outgoing requests over the Session and CDR module. It contains <protocol>-<version>, where protocol can be OCPI or OICP. The current versions are listed below, but can be extended if we upgrade CPO integrations to higher versions.
    • OCPI-2.1.1
    • OCPI-2.2
    • OCPI-2.2.1
    • OICP-2.3 (hubject)

​
TokenType

Even though our Roam OCPI integration is on 2.2.1, we still integrate with quite a few CPOs over OCPI 2.1.1. In OCPI 2.1.1 there is no token type APP_USER or AD_HOC_USER, and for most CPOs on 2.1.1 we would have to push all the charging keys up front. Therefore, our platform requires a charging key to exist before a remote start can be performed, and you must always ensure to push the tokens to us before they are used to initiate any charging session.

​
Token issuer

By default we share all tokens with CPOs with token issuer DE*8PS. Combining EMPs under DE*8PS brings us an advantage in our discussions with the CPOs, as we aggregate the demand from several players and thereby can negotiate better pricing, which all EMPs get advantage from.