eFAWATEERcom Bank Prc icon

eFAWATEERcom Bank Prc

(0 reviews)

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 :

  1. Billers
  2. Account Upload
  3. Account Inquiry
  4. Add Customer Billing
  5. Remove Customer Billing
  6. Postpaid Bill Inquiry
  7. Postpaid Payment Account
  8. Postpaid Payment Credit Card
  9. Prepaid Validation
  10. Payment Inquiry(Not Implemented yet)
  11. Edit Customer Billing(Not Implemented yet)

Flow Diagram:

resources/eFAWATEERcom-exchange%20Flow%20Chart%20%282%29-3146ebbf-931f-4166-bd20-9868086bc4ed-eadc65ff-ddb0-482f-bddc-5c38e789f367-9ff1e719-43f4-484e-b2a0-869b70efd036.png

Sequence Diagram for eFAWATEERcom Bank

resources/seq%20dia-94736eef-f653-4f4b-905d-846ec7343b5b-27e01c7d-7c78-4d3f-892b-86e35a55fc01.png

Technical Specifications

Headers

Below are the mandatory/optional headers that are set with every HTTP Request from Mule EAPI towards eFAWATEERcom.

HeaderNameSample ValueOptional?
client_id123124235436Mandatory
client_secret123124235436Mandatory
AuthorizationBearer afdca88b-9ed0-344b-8af0-b2195e382574Optional
x-user-idOptional (for BPM) internal user
x-channel-idDEVEFAWATEERCHLMandatory
x-sub-channel-idOptional
x-correlation-id13243564564Mandatory, Unique - use for idempotency filter. Max 50 chars. This field will used to hold GUID of eFAWATEERcom
x-bank-idCBOJMandatory
x-debug-flag0Optional (enum - 0 or 1)
x-customer-id2100122Optional (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

resources/auth-41d19dc9-12cd-40f4-a1cf-0ed40625e773-b6cb693e-bcb3-4da6-b9d7-5c3187dd4e80.png

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.

resources/error%20handling-b1225260-c681-4aee-8b55-0d60aad42fd3-3c889f9f-e000-4e83-a5cd-4a5d954fb41c.png

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"
}

Reviews