PPS ORIAN API
Delegated Authorisation
The ORIAN Delegated Authorisation feature allows an ORIAN endpoint to make authorisation decisions in real-time using the ORIAN Transaction API. Delegated Authorisation may be combined with ORIAN Transaction Notifications to maintain full up-to-date transaction control and monitoring.
Endpoint Responsibilities
Implementers must be prepared to receive ORIAN transactions with the 'Authorisation Requested' lifecycle status. Receipt of a transaction in this state represents a transaction that has not yet been processed and so has not been assigned an authorisation decision. It is the responsibility of the endpoint provider to make the authorisation decision and to add the decision to the response using the txn_result property.

Note that a transaction will only be published in the 'Authorisation Requested' state if PPS are allowed to decline according to the rules of the acquiring payment network. Where a decline is not allowed the transaction will directly transition to a later state (which would only be visible to endpoints subscribed to ORIAN Transaction Notifications).
A typical decline decision might add:
"txn_result": {
"result": "DECLINED",
"result_detail": "INSUFFICIENT_FUNDS",
"result_message": "an optional textual description"
}or for an approve decision:
"txn_result": {
"result": "APPROVED",
"result_detail": "SUCCESSFUL"
}See the "Example Messages" section for full example requests and responses.
Other Considerations
Balance Management
Delegated Authorisation may be configured with or without PPS financial balance management.
Where PPS do not hold a balance the endpoint must take full responsibility for the financial impact of the transaction.
Where PPS do hold a balance it will always be checked before a Delegated Authorisation request is initiated. Where the balance has insufficient funds the transaction will be declined and no Delegated Authorisation request will be generated.
PPS can also manage a balance but never decline due to insufficient funds (so called "update only" balance management). This may be useful when the external endpoint will allow negative balances. Note the balance may be checked when the external endpoint cannot be reached (see Stand In section below).
Where PPS hold a balance it will be published with the account details in the Delegated Authorisation transaction request. Note that for a transaction in the 'Authorisation Requested' state the balance is that before the application of the transaction. This is in contrast to all other lifecycle states (notifications) that describe the balances after the described event.
Expected Response Times
PPS expect a response to a delegated authorisation request within 0.5 seconds or less i.e. the average maximum response time should 0.5 seconds or less.
The maximum permitted response time is 2 seconds.
After the maximum response time is reached PPS time out and use the stand in behaviour (see below) setup for the product.
Note: The maximum response time can be changed by PPS to protect platform stability.
Stand In Behaviour
In the case that the External Transaction Endpoint is not available a stand-in authorisation decision is required such that PPS can complete authorisation within the required time window.
The supported Stand-In options are:-
- Always Approve - A failure to reach the External Transaction Endpoint will always result in a successful authorisation (assuming all PPS validations are successful).
- Always Decline - A failure to reach the External Transaction Endpoint will always result in a declined authorisation.
- Check Financial Balance - This is used in conjunction with "update only" balance management. PPS will check the balance and approve if balance is available and decline if not.