The purpose of this site is to outline the design principles, objects, behaviours and handling of error for WizDom Pay API. The goal of the API is to enable banks to implement WizDom Pay APIs easily into their systems. We hope to achieve this by the implementing the following principles:

• The use of REST architectural principles.
• Providing a set of well-defined objects that are abstracted from the underlying object representations held in the various banking systems. This allows an API client to construct an API message without requiring specific knowledge of the target server implementation.
• Use of ISO international standards for enumerators of currencies
• Use of a flexible construct to enable the target account(s) and transaction parties to be identified.

This API is a JSON REST API that Will be used by Banks to access services in our school ERP System. This document gives an overview of the structure of the API.

API FLOW:

• Account creation
• Use account to generate token
• Use token to fetch/Post data

Contact Support (support@wiuc-ghana.edu.gh) for validation and Account creation.

Required headers for the API's:

• Content-Type application/json

Below is the list of error codes available.

Common Error Codes

• 400 - Bad Request The request was unacceptable, often due to missing a required parameter.
• 401 - Unauthorized No valid API key provided.
• 402 - Request Failed The parameters were valid but the request failed.
• 403 - Forbidden The API key doesn't have permissions to perform the request.
• 404 - Not Found The requested resource doesn't exist.
• 500, 502, 503, 504 - Server Errors Something went wrong on our end

Error Responses

• Campus unavailable, unavailable - Student data not in database
• Field cannot be null - Needs input data
• Not Found - Requested resource was not found

The Open API uses Oauth 2.0 token for authentication of request. User will request an access token using Client Credential Grant according to RFC 6749. The token received is according to RFC 6750 Bearer Token.

The email and password are used in the basic authentication header when requesting the access token.

The email and password are given upon request from parties.

Important: The token must be treated as a credential and kept secret.

"Authorization: Bearer xxx"

POST: base_url/auth/login

Request Limit: No Limit

Request Limit: No Limit

GET: base_url/student_info/student_info/?search=index_no_value

Request a get value with search as Key.

The response data should be populated into POST: base_url/voucher/deposit fields.

NB: Selected Fields to populate.

=> "index_number"

=> "first_name"

=> "middle_name"

=> "last_name"

=> "email"

=> "phone"

POST: base_url/voucher/deposit

NB: Populate the below fields from GET: base_url/student_info/student_info.

=> "index_number"

=> "first_name"

=> "middle_name"

=> "last_name"

=> "email"

=> "phone"

IMPORTANT THINGS TO NOTE IN INPUTING THE REMAINING FIELDS

=> "ref" this means reference. All banking reference type can be used. eg. Pay-in-slip, Transfers, MOMO, Swift Transfer, Card Payment etc.

=>"currency" this is the approved currencies. GHS and $

=>"particulars" List of particulars are as follows: School Fee, Graduation Fee, Hostel Fee, Prospectus, Project Work, Licensing, Resit, Transcript, Document.

=>"cr" Amount to be credited.

=>"comment" This can be the person who did the deposit's details. eg. Name and Phone number.

GET: base_url/voucher/banktransactions

Pulls list of transactions by the said bank

{
   
   "records": [
        {
            // Records...
        },
        {
            // Records...
        }
   ],
  "totalRecords": ,
    "recordCount": ,
    "totalPages": 
  }

This API has been made possible by the ICT Directorate of Wisconsin International University College, Ghana