Explanations use OCPI 2.2.1. Physical and billing-system events are authored examples.
Dutch CPO asks the German eMSP to authorize
Technical
5 min
Dutch CPO asks the German eMSP to authorizeExplore the tokens module →
The token's whitelist value is NEVER, so the Dutch CPO asks the token's owner, the German eMSP, to authorize it in real time, naming the location. The eMSP answers that the driver may charge here.
No sandbox run sends this exchange, so there is nothing to run here.
CPO
EMSP
"When the token is known by the Sender, the response SHALL contain a AuthorizationInfo object. If the token is not known, the response SHALL contain the status code: `2004: Unknown Token`, and no `data` field."OCPI 2.2.1 Tokens module · #mod_tokens_post_response_data"|ALWAYS |Token always has to be whitelisted, realtime authorization is not possible/allowed. CPO shall always allow any use of this Token. |ALLOWED |It is allowed to whitelist the token, realtime authorization is also allowed. The CPO may choose which version of authorization to use. |ALLOWED_OFFLINE |In normal situations realtime authorization shall be used. But when the CPO cannot get a response from the eMSP (communication between CPO and eMSP is offline), the CPO shall allow this Token to be used. |NEVER |Whitelisting is forbidden, only realtime authorization is allowed. CPO shall always send a realtime authorization for any use of this Token to the eMSP."OCPI 2.2.1 Tokens module · #mod_tokens_whitelisttype_enum
Message FlowStep 2 of 4