eFAWATEERcom Bank Prc
home
eFAWATEERcom Bank Process API
Base URLS:
Description:
eFAWATEERcom bank Mule Process API helps in integrating the customers and channels with the eFAWATEERcom system to send and receive financial requests through the eFAWATEERcom network which takes care of all the billing, payment and settlement related functionalities with the help of other billers.. Mulesoft exposes the REST endpoints for the following operations :
- Billers
- Account Upload
- Account Inquiry
- Add Customer Billing
- Remove Customer Billing
- Postpaid Bill Inquiry
- Postpaid Payment Account
- Postpaid Payment Credit Card
- Prepaid Validation
- Payment Inquiry(Not Implemented yet)
- Edit Customer Billing(Not Implemented yet)
Flow Diagram:
Sequence Diagram for eFAWATEERcom Bank
Technical Specifications
Headers
Below are the mandatory/optional headers that are set with every HTTP Request from Mule EAPI towards eFAWATEERcom.
HeaderName | Sample Value | Optional? |
---|---|---|
client_id | 123124235436 | Mandatory |
client_secret | 123124235436 | Mandatory |
Authorization | Bearer afdca88b-9ed0-344b-8af0-b2195e382574 | Optional |
x-user-id | Optional (for BPM) internal user | |
x-channel-id | DEVEFAWATEERCHL | Mandatory |
x-sub-channel-id | Optional | |
x-correlation-id | 13243564564 | Mandatory, Unique - use for idempotency filter. Max 50 chars. This field will used to hold GUID of eFAWATEERcom |
x-bank-id | CBOJ | Mandatory |
x-debug-flag | 0 | Optional (enum - 0 or 1) |
x-customer-id | 2100122 | Optional (mandatory for customer facing channels)7 digit number |
API Policies
Client ID Enforcement
The Client ID Enforcement policy restricts access to a protected resource by allowing requests only from registered client applications. The policy ensures that the client credentials sent on each request have been approved to consume the API. All the layers present will be applied with client id enforcement.
Example:
client_id: dkjhfkshd8234823746djhfdfsdf
client_secret: roieutoiurenbmnzb2648732dnbf
Rate limiting:
The Rate Limiting policy enables us to control the incoming traffic to our APIs by limiting the number of requests that the API can receive within a given period of time. After the limit is reached, the policy rejects all requests, thereby avoiding any additional load on the backend API.
Rate Limiting policy will be applied to all API layers as it is vital to control the resource utilization and limit the overall load of our APIs.
Limitation set : 1000 Request per minute
IP Allow list
The IP Allowlist policy allows a list or a range of specified IP addresses access to a protected resource when a match is found between a source IP (specified when configuring the policy) and a list of individual IPs or range of IPs. This policy is only applied on the experience layer.
List of IPs allowed: 10.0.250.12
Sensitive data Encryption
As per RFT guidelines all passwords and sensitive information will be encrypted using RTFCTL utility secrets manager. <>
Authentication with eFAWATEERcom APIs
Authorization/Authentication API - eFAWATEERcom
For integration with eFAWATEERcom switch and to perform any operation over the
eFAWATEERcom solution, the cboj-efawateercom-sys-api should be authorized by performing a
regular handshaking operation as the following:
- Request for authentication
- Receive the authentication Token
- Use it for any future operation
Token will be cached and used for each customer id along with token’s expiry date. In case the token is expired new token will be fetched from the authenticate service.
The following diagram shows the steps for Authenticating with eFAWATEERcom
Error handling
Backend Error Handling
Each System API (application) stores its respective backend errors in a configuration file called “error-config.yaml” . error-config.yaml
stores Backend error code, Error code, Eng Msg, Arabic Msg, Mule error code for each error thrown from the backend w.r.t to that End
system.
The system API then fetches the Respective Error code, Eng Msg, Arabic msg, Mule error code from config.yaml for each backend error
and sends to process API. Process API then propagates the error to experience API and then to channel. Channel specific errors are
translated in Experience API.
HTTP Status
The HTTP error codes that are specified are as follows:
400 - Bad Request: An error in the client request (Mostly due to validations)
404 - Not Found: The resource defined in the URL doesn't exist
405 - Target method is not supported
415 - Media type of payload is not supported
500- Internal Server Error: The server encountered an unexpected condition
Error Response
A REST API reply with an error code and a message to be shown to the consumer
example-
{
"success": false,
"code": "400",
"reasonCode": "BadRequest",
"arabicMessage": "",
"englishMessage": "Invalid json value was provided"
}